TCL

The idea is to have everything in strings. The strings will have a sort of VAT set up before any of the strings. Where it will be set up like: Variable name (string), 0, Size (word), etc.  Following will be the strings, non-zero terminated. Math will be done so that the "numbers" (which are string representations of numbers humans read) get the decimal points aligned together and then basic addition, subtraction, multiplication, and division get done on a "per character" basis. Everything will be calculated LTR as a means of making it easier on myself. Parenthesis will be counted as function names. For functions, they will be defined as: 0, code to be used for the function. 0 is the new line token (see about DCS textbox support to make my life really easy). Possibly "compile" the code: shortens "if (" to a single byte, probably between 0 and 10h, leaving the rest to be stuff to be displayed. Concatting strings, "subbing" strings, and "indexof"/"instring" of strings will be included.  When the program encounters a new variable (started with %), it will return an error, maybe eventually make a "null" string. Things will be displayed on a "terminal" style screen, with monospaced 4x6 size font (DCS font, but monospaced). Some functions that will be needed are: createVar (hl=string location of name, 0 terminated. de=data to send), deleteVar (hl=name of variable to delete), compareString (hl=first zero-terminated string, de=second string), moveDataFwd (bc=size to move forward), moveDataRev (guess), MOAR!  I will reserve 4000 bytes for variable structure, and programs will be copied somewhere (end of variable stuff?  Read backwards?).  

The above is literally copied and pasted from a document on my iPod I made to help me get some stuff down. Souvik asked about "reading backwards", basically, it would start the data at the end (you read from the end of the 4000 byte area) and go backwards, instead of the conventional forwards method. I'm planning on making this when I get time between my projects. I titled it "TCL" because that is the thing it reminded me the most of. It will be in Assembly and for DCS. I'm mainly posting this so people can ask ideas and help me finalize details before I begin working on it, so please, ask questions Most of the details were thought up last night about 4 am because I couldn't sleep, so it may seem very stupidly put together, that's part of the reason I am wanting people to help me (I'm still sleep deprived >.>)

So is this going to be compiled or interpreted?

Interpreted, but probably slightly precompiled As in the "If (" turning into a single byte.

So it's a language? A math library? I'm somewhat confused.

A language. Mostly to work with strings and such.

Sounds great, tanner! I look forward to seeing what you come up for this project. Just be careful (as I'm sure you are) not to fall into the SirCmpwn trap and start too many dozens of projects.

How will a programmer code in this language? Is it compiled on the computer, or does it use an on-calc editor?

It sounds to me like it will probably be entirely on-calculator, but I'll leave it to tanner to give the final word. I'm assuming that he wants to make it as widely-useful as possible, which would mean making it on-calc.

I think I'll definitely start with a computer editor, and then move on to a calculator editor. Mostly because I want to get the language itself working, and then have to fool with a GUI editor.

Well, you could just use some simple DCS GUI tools for the editing. Cf. Tokenizer DE for an example of on-calc compilation/tokenization tool that's relevant to this project, although not directly applicable.

Do you have the syntax for the language planned?

An excellent question, and one that I second. Is this project still underway, or did it get put on the back burner (back burner for now)?

I am going to pick this back up. Currently just replanning it, because my previous plans were flawed at best, and difficult to actually do. I am running into a problem where I will need help trying to get a VAT set up for just my program. Basically, I will want to be able to do something similar to malloc() and get some RAM that is free. I don't get how I will be able to do that without stealing tons of RAM keeping track of: the location, and the size; each, two byte words. The way I am planning it to work, I will get some RAM to put the new string as it gets edited, and then I need to get rid of the old pointer, and somehow be able to tell that that area is now free RAM. Is there any place that I could read about this, or maybe someone could explain it a little better, or just tell me that I am completely wrong?

(Logs from IRC when I was talking about this, with irrelevant stuff removed)

So, it sounds like you need:

1) Big chunk of memory that the TI-OS won't touch
2) Said chunk of memory to be variable-sized
3) Allocation table on said chunk of memory

If you essentially just want to be able to malloc, realloc, and free chunks within that big chunk, we can easily help you design an implicit free list implementation in z80 assembly of the malloc/realloc/free() function triplet.

I would love to hear how to do that. I was planning on just stealing as much memory as I could and using that, and then tossing it when everything is done. How would I design this, from a psuedocode perspective?

I should get you the notes from the class that I TA'ed this semester, where for the last lab the students learned how to implement malloc(), realloc(), and free() using a grow-only heap. Basically, you start with 0 bytes, you allocate memory from a heap (think bcall(_InsertMem)), then put a header (and optionally a footer) on each allocated piece of memory indicating its size and that it's used. When you free memory, you mark the chunk as free but retain its size marking, so that if someone asks for another piece of memory of an equal or smaller size, you can give them that chunk again. Caveats include:

1) Matching request and target size: if you allocate 10 bytes of a previously 12-byte chunk, you are left with 2 bytes that definitely won't be useable for anything
2) Free space coalescing: It's good to combine sequential free areas into bigger free areas

Hmm, I have the basic idea of how I would do that, and it even seems fairly simple. I could implement a "garbage-collect" (for lack of a better word) so that it will take all the sections of used memory and collapse them together. That would kill all pointers, but I bet it could be done pretty easily. Should I try to do that, or is there an even better one I could do?

Edit: Oh yeah, I want to change the name soon, because I know this program won't be up to par with the normal TCL language. So, if anyone has any ideas, I am very open to them.

You usually don't want to move any used section in a malloc()-type implementation, because you don't know what's being done with pointers into that memory in the program. Better is to do compacting on free sections and only worry about moving and compacting of free areas.