11

I seem to remember using an assembler with the following interesting workflow: You'd write an assembly language file and assemble it. The output overwrote your source code by placing the executable code after the source code. You could run it as any other program. Then you'd load your program into an editor - you'd see your source code at the top and following your END statement there'd be arbitrary binary gibberish. You edit your assembly source, reassemble, and again: your single file would be replaced with a new file that had your assembly source at the front and the assembled binary at the end.

(Obviously there must have been a few bytes of binary gibberish at the front of the file too, after assembly, but I can't say I remember that.)

Can't remember if it was CP/M or DOS. Or 8080 or what. (I put both cp-m and dos tags on this Q.)

Ring a bell?

20
  • 2
    Interesting. Sure it could be started from regular command line without any helper? And sure it was an otherwise normal ASCII file, except for the added code? While it seems possible to hide additional code behind a closing CTRL-Z, I wouldn't know how the defautlt OS-loader could be made to ignore it. Under CP/M and DOS (COM) one would expect at least a jump around the source text (which in turn must be considerable smaller than 64 KiB), while DOS EXE-files require a binary header to do so. Either would rather collide with the source being unchanged at the start of the file.
    – Raffzahn
    Mar 12, 2021 at 1:35
  • 6
    The question I have is, why?. I'd run a mile from a language processor that thought it was ok to modify the source file while compiling/assembling it. Mar 12, 2021 at 4:41
  • 3
    @another-dave - I don't actually remember but I think the author probably considered it an advantage in the floppy disk era. The really low capacity floppy disk era. Or maybe it had to do with copying files about - you only needed one. It was certainly an outlier - I'm pretty sure the idea hasn't been picked up anywhere else!
    – davidbak
    Mar 12, 2021 at 5:24
  • 2
    "You'd write an assembly language file and assemble it" - What editor did you use to write the source code, and how did you assemble it? Can you remember any of the commands or procedures involved? Mar 12, 2021 at 17:08
  • 2
    @another-dave that said, people leaving trailing whitespace everywhere is another one of my pet peeves, and my IDE is configured to trim it.
    – moonwalker
    Mar 19, 2021 at 0:34

1 Answer 1

6

The only thing I've ever encountered that did something like this was the A86 assembler from Eric Isaacson.

However, the feature there is that errors from assembling your code would be injected directly into your source file so that you could see them in the place where you needed to fix them ("normal" practice at the time being to write a separate listing file with hex data, source lines, and errors).

Re-assembling the file would automatically remove these errors before (possibly) adding new errors (or the same error if you forgot to fix something).

What you're discussing still happens nowadays, with (for example) a single file running as a cmd script which then runs Python using that exact same script as the source. The trick is to make the Python bits invisible to cmd and the cmd bits invisible to Python, something like:

rem = """
rem cmd stuff goes here, runs python with this file.
rem Python sees this as setting var rem to a multi-line string.
goto :eof
rem """

# Python stuff goes here, cmd will have already left.

Or, in your case, "hiding" the executable code from the editor and assembler while still allowing it to run.

A COM file that placed the executable code after the source (in your actual source file) presents a couple of problems, as per below.


First, since COM files get loaded at a specific location and run from there (0x0100), there would have to be at a minimum some binary jump instruction before the source to go the the executable portion of your code.

A general purpose text editor is likely to complain bitterly about this. I suppose you could have a purpose-built editor which only allowed you to edit the source section (between jump and executable code) but it seems strange to need a special editor for what is really a dubious feature.

Alternatively, you may find a way to encode binary data in such a way that it looks like something good to the editor but acts as code when loaded to execute.

If the ; were used as a comment marker, you could place that at the very start of your file, followed by some executable code and a new-line marker.

For example, ASCII ; is code point 0x3b which, on the 8080, was the DCX SP instruction for decrementing the starck pointer. Yo could follow that immediately by an equivalent INX SP then a jump to your code, something like:

0100  3b         DCX  SP     ; First byte of file, but loaded at 0x0100.
0101  33         INX  SP
0102  c3 xx xx   JMP  xxxx
0105  0d 0a      DB   0d, 0a

That would show up in your source as ;3<c3><xx><xx><cr><lf> and your actual source code would follow after that.

On the chance that editors would not be keen on characters above code point 0x7f (such as the JMP) or even the non-printable characters under 0x80, I have no doubt that some smart person could construct a byte sequence that did the same job using only printable values (for both opcodes and data).

For example you could load printable-char values into registers and not them to get non-printable-char values, or push things on the stack and return rather than jump (unfortunately RET is also above 0x7f but you get the idea).


Second, and this is probably more important given the 64K-ish limit to COM files, it's probably not a good idea to waste in-memory space on storing the source during runtime. It unnecessarily limits the size of your program.

If you have 30K of source, that's 30K less space that you have available for your executable code.

Again, you could have a special loader which only pulled out the executable code from the file but then it's not really a COM file at that point.

2
  • 2
    you know, I think you've got it! I bet my memory got totally garbled up and that "error messages embedded in the source and then automatically are stripped out the next time" is what I was really thinking of in the warped recesses of my brain! and the name (A86) sounds familiar too ...
    – davidbak
    Mar 2 at 4:03
  • @thebusybee: 11000011 from the 8080 docs. Guess who's apparently forgotten how to read binary. Clue, it's not you :-) I'll fix that.
    – paxdiablo
    Mar 3 at 8:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.