Return to Answer

2. You will be losing any comments and special code formattings like indentation and extra spacing if not stored in a separate place (without any memory saving). These are highly valuable in assembly code

3. The fact that code that has been generated from macros will not be visible. You will be losing that information if not stored elsewhere (again, no saving of memory)

4. You'd be losing all information on assembly pseudo-instructions (ORG, OFFSET, DC.B, the like).

5. You'd also be losing track of what's code and what's data.

6. It's a huge difference whether a table was originally created as bytes, words or longwords, and then whether it was created as absolute or relative values (*-label or label). All of that is lost in a disassembly.

2. You will be losing any comments and special code formattings like indentation and extra spacing if not stored in a separate place (without any memory saving). These are highly valuable in assembly code

3. The fact that code that has been generated from macros will not be visible. You will be losing that information if not stored elsewhere (again, no saving of memory)

4. You'd be losing all information on assembly pseudo-instructions (ORG, OFFSET, DC.B, the like).

5. You'd also be losing track of what's code and what's data, which is a significant problem when your disassembler would need to figure out whether 0C9H should be RET or DC.B 201 (a Z80 example). Modern disassemblers try to follow code streams to decide whether areas are code or data, but that's way beyond the capabilities of an 8-bit micro (and still not 100% accurate when jump tables are involved).

6. It's a huge difference whether a table was originally created as bytes, words or longwords, and then whether it was created as absolute or relative values (*-label or label). All of that is lost in a disassembly.

The value 100 has (at least) 5 different meanings in your symbol table (addresses, immediates, offsets, relative or absolute, characters, bytes, words, longs), and in some examples (*-start) it doesn't even shop up as a literal in the binary - when translating back and forth, you have the same problem a disassembler has when trying to make sense of symbols (when encountering "100" in the disassembly, you simply don't know which of the meanings/symbols to use), or you lose valuable information your original source code had. (Or you store that information someplace else and lose large parts of your memory savings)

The value 100 has (at least) 5 different meanings in your symbol table (addresses, immediates, offsets, relative or absolute, characters, bytes, words, longs), and in some examples (*-start) it doesn't even show up as a literal in the binary - when translating back and forth, you have the same problem a disassembler has when trying to make sense of symbols (when encountering "100" in the disassembly, you simply don't know which of the meanings/symbols to use), or you lose valuable information your original source code had. (Or you store that information someplace else and lose large parts of your memory savings)

I think it's technically possible what you propose, but hampering productivity (a lot).

You can amend lots of these shortcomings by storing the assembly program in a sort of tokenized form, but then it's no longer your proposal.

I think it's technically possible what you propose, but would be hampering productivity (a lot), or, if amended with extra information, will not produce the memory savings you seem to assume.

You could possibly amend lots of these shortcomings by storing the assembly program in a sort of tokenized form, but then it's no longer your proposal.