on-calc asm compiler

[King Harold]

I'm ~trying~ to make an on-calc assembly compiler, I started a while ago but I didn't want to announce it untill it looked atleast semi working.
I'm trying to make it a GOOD one, unlike Chasm and tasm-on-calc (sorry guys.. they just have too many bugs..)
So some of the features (of the last version ever to be released) will be: support of all instructions, hexadecimal and decimal immediate values, no label bugs, hopefully support of labels of any length, relative branch exceeded warning, duplicate destination program warning, SMART compiling (ld instructions (and some others) should not be compiled through a LUT but by bit-fields), index offsets, defines, comments, includes, pre-defined values (OP1, SavesScreen etc), (thinking of more stuff..)

don't expect anything even near that yet, the first version will only support labels with 1 token, some commands, hexadecimal imm values only, old-fashion instuction LUT, maybe a little more but it's atleast something that might be handy for math classes..

maybe someone will have to remind me to work on it every now and then because im also working on this "little" C# project with a friend.. I have loads of spare time (I dont work ) so it shouldn't be a problem, but I might forget about this or get bored when I can't get rid of a bug or something..

[threefingeredguy]

Don't forget the program whose name we do not utter.

[Mike K]

This project really has two parts. One is the compiler, the other is a really good text-entering interface. If at all possile I would attempt to keep the "notepad" interface the same at the TI keyboard. Most people are acustomed to typing in that format, no need to re-learn it.

-Mike

[King Harold]

Actually im not going to fall for that mistake. It would take forever to make, be enormously huge, and have loads of bugs anyway. So, just like the old tasm-on-calc, if should compile a basic "program" which is written in normal (lowercase) tokens.

the TI program editor is good enough

[benryves]

Why lowercase tokens? They're twice as large and harder to parse than the uppercase variants.

[KermMartian]

Why lowercase tokens? They're twice as large and harder to parse than the uppercase variants.

Exactly. Just use uppercase tokens whenever possible.

[King Harold]

because of the hex codes which use uppercase (duhh), so if the commands would be uppercase aswell the compiler will be confused and find a part of a command and part of its hex code and think it was the command it was searching for, and then paste crap into the hex source.
this problem only occurs in the basic/asm version, not in the pure asm version if there will be one.
furthermore, you wont want to have a source code long enough for the size to matter, it wil take forever to compile.

[benryves]

A simpler solution would be to insist that all hexadecimal constants began with a zero and ended in an H. This is fairly common practice.

I assuming you're referring to this problem?

Code: Select all

:LD A,B   ; is that LD A,$B or LD A,B?
:LD A,0BH ; Much easier.

[King Harold]

Well that's also a little problem, but actually i was referring to something much worse, the format of the opcode LUT works like [num bytes][name][opcode] and i'll have to stick with it or type out my own, which takes a while. So if a name is like LDA it will also find somthing ending on LD with an opcode starting with A, this does infact happen with some of the romcalls and a few commands and loads of variables.
This will either generate an error (it wrongly parses a letter to a zero, and then have a byte length of zero) or make the program paste tokens other then 0123456789ABCDEF into to compiled program.

[King Harold]

the ti basic version is done, but its slower then the german tasm-on-calc because.. well.. no idea.. it just is.. but atleast you can use ld (op1),a (not yet ld (op1+ [imm8] ),a yet though)

edit: In case anyone is wondering why it isn't being released: no bit instuctions, no ZIX instructions, and worst of all it still takes ages and ages to compile. If anyone want a bad and slow compiler just PM me, if loads of people want slow compilers I'll release it anyway.

[King Harold]

Just so you know: I made an assembler which uses bitfields. But then I realized the data format was SO wastefull it would require a 2 page app. Now we don't want that for just a compiler do we. So that was a nice idea, but not practical, so im back to normal table assembling. (I used a HUGE table for the bitfields because I had to store each byte as 8 bytes so I could store the PLACE of the bitfield, if anyone knows a better way...)
Before ppl start calculating: no the table alone isn't 2 pages, nor 1, but the assembler itself had to be a little bigger to handle the bitfields and it got just over 1 page.

[chickendude]

Wow, I'm really impressed with the progress you've made!

[King Harold]

thanx, me too actually, but I didn't make enough progress (or I wouldnt ever have thought bitfields to be practical, they arent, really, they're a pain)
But I guess I could just do it the old way..
I need some help on my selection menu though, I can make a 7 item menu just fine but when it gets longer I get all confused. I tried to figure out how the GroupTool selection menu works but I can't really read that source, way chaotic.. (sorry Brandon W)

[chickendude]

What do you want? A menu that can scroll up/down? If you let me know what you're looking for I can help out with that one

[Loki]

wow, good to see this...might take up asm again