Well, those were the days! Back then we made good use of our tools, apparently.
Anybody who’s ever done hand-assembly on paper will find nothing new in this article (beyond the suggestion above), but if you’ve not done it before you may find it interesting (and potentially useful) reading.
Of course, those of us here who have cassette tape recorders have already reached the golden age:
Though, given that even today wire-wrap is a great technique, I guess you shouldn’t pack up your electric eraser quite yet!
Great stuff. (You could always try cat or copy if you like single-pass write-only programming…)
My programming life started with programmable calculators: it was relatively natural, as I recall, to progress to assembly language, via Basic and Fortran, with paper and pencil as the tool of choice. I could certainly write a 10-line program that way, and possibly a 100 line program. Beyond that, I’d struggle!
Oh now I remember: I read an article about the newly introduced 8086. Among the wisdom dispensed was that it’s probably complicated enough that you’ll need an assembler. Wisdom indeed.
I could and did do hand assembly for Z-80 back in the day but didn’t like it one bit. The editor/assembler (EDTASM) on cassette was much better but still rather tedious. One thing I wasn’t clever enough to realize is that you’re better off to leave space between routines so you could patch them up rather than re-assembling the whole thing. And if you run out of space then simply jump from the old subroutine location to the new one.
Can’t help but be reminded of this story about Steve Wozniak typing in 6502 code in hex:
Some machines DO need a ASSMBLER. Any thing that uses
branches are a pain to hand assemble. The Apple was a case of
needing to be bootstrapped by hand, as most assemblers at the
time often cross assembled as Fortran program on a large machine.
It took a few years later, for micro computer software, like microsoft
to have assemblers and linkers for a 8 bit micro. Later still did you get
the cassette tape versions for the COCO or Dragon computers.
While relative branches do require a bit of counting or arithmetic, I got used to this pretty quickly, at least for typical short branches. I don’t feel that calculating a branch is any worse than having to look up an opcode.
A serious complication is when a processor has more than one size of branch instructions. The Transputer with its prefix instructions is an extreme case. If you find out that in the fragment you jumps over there is a branch that has to be bigger, the jump over it might also become bigger in a cascade that makes you recalculate everything.
Jump sizes were an issue in the popular microprocessors, too; the 8080 Z80, 6800 and 6502 all had short (+127/-128) relative branches. The article points out that there may be cases where the branch is not sufficient to get you where you want to go and you need instead to branch to an intermediate point, which often forces you to modify the program and recalculate at least some of it.
I did a lot of hand assembly when I started out on my computing journey - lots of graph paper and even twigged on pretty quickly to leave space in between subroutines in case they needed expanding later. At some point I did write a “relative” jump subroutine for the 8080, using an unused RST instruction and the following byte as a displacement for the pushed PC (I’m not sure why though - thinking back, it was probably for the technical challenge).
