cjs
Experienced Member
I don't know what you mean by that, but that's probably not what I'm suggesting.Do you mean "Drop the link pointer" as in "using something like the counter to denote the list and scan for it?"
You currently have entries in the form
nnls...vv
, where nn is the link pointer, l is the length of the symbol, s... is l bytes of symbol name, and vv is the value of the symbol. You currently save nn so you can move your pointer into the symbol table forward to that location if the current symbol doesn't match. But you don't need this: you can find the start of the next symbol simply by finishing a complete parse of the current entry. I.e., when you are c bytes into the symbol name and find it doesn't match, just add l-c+2 to your current location and you're at the start of the next symbol.This is entirely orthogonal to having additional data types in the list. That, by the way, can be very compactly done by restricting the symbol length to, say, 64, which requires only 6 bits to represent, leaving the top two bits of the length byte free for other purposes. (It would even be reasonable IMHO to restrict max symbol length to 32, thus giving you three bits for type, covering eight different types.)
The overhead is not small: as I pointed out it's over a kilobyte for your assembler itself. That is, for example, close to 20 times as much space as you'll save from removing the length bytes from the opcode list and using bit 7 termination.A linked list may not be the best option, but it does allow future requirements that I am adding in presently and has a small overhead while allowing for this.
In any event, there are far worse uses of space in the current code that I will need to address later such as the wasted space in the code to store the opcodes and scan them. This would be better as Bit7 start/terminate list...
That is a pretty radical change from the original spec you were talking about when you wanted this to run on a 20 KB system. If it really is intended to run on a 1 MB system, why do you keep worrying about code and data size?I have an objective for the assembler to work under CP/M, but the target system will have 1Mb of memory...
Right, so in this case of EQU, you add a label, set the value to PC, discover that the "instruction" is an EQU, read and parse the operand, and reset the label value to that result. I'm not seeing the issue here.LABEL EQU VALUE and LABEL CALL FOO are fine as high level concepts, but the : is the exception delimeter there, and if you examine the parser, it allows an operator to change the context of the line. The parser is very simple and simply breaks up the next incoming instruction, and as you note, *everything* is an instruction. A ':' operator is an instuction to add a label and set the value to PC.
Nope, not at all unique. ASL and many other assemblers allow this.- ' and " are both valid quotes. I think this may be unique to my assembler since quotes can be quoted - eg, "'" and '"' are valid, so can be used directly.