How is a first assembler assembled? (without cross-compiling)

Question

I know there are a lot of threads regarding this topic, but I can't find the answer for this precise topic:

First of all, with the "first assembler" I mean the program that translates, let's say, the instruction "mov" to the specific machine code the ALU understands, 1100111 or whatever other binary number. There's some gap between those two steps that I can't find answers for.

I understand the process is something like: you have a cpu chip built with an specific micro architecture that implements N instructions. Each instruction is accessed internally in the ALU with a binary number or opcode (000 mov, 001 add, etc) At some point of history, instructions were loaded into the CPU using punched cards, tapes, etc.

But then, you want to raise the level of abstraction and needs an assembler to program in a higher language instead of opcodes, and this is exactly where I'm missing something.

At this point, I guess some bootstrapping is used to go from opcodes to assembler, but how? How do you write the assembler v0.00 for a given brand new cpu? Is there any chip hardcoding those instructions, maybe the first assembler is hardware based?

In "Assembler and Loaders", it seems the first assembler was created using a ROM, hardlinking telephone selectors to memory addresses.

"One of the first stored program computers was the EDSAC (Electronic Delay Storage Automatic Calculator) developed at Cambridge University in 1949 by Maurice Wilkes and W. Renwick. From its very first days the EDSAC had an assembler, called Initial Orders. It was implemented in a read-only memory formed from a set of rotary telephone selectors, and it accepted symbolic instructions. Each instruction consisted of a one letter mnemonic, a decimal address, and a third field that was a letter. The third field caused one of 12 constants preset by the programmer to be added to the address at assembly time."

Answer 1

You write the assembler-program in machine code, that is, as a series of numbers. Maybe you write the code in assembler on a piece of paper, then by hand translate each instruction into the corresponding machine code number.

Answer 2

The question reminds me of an anecdote told about John von Neumann:

Donald Gilles, one of von Neumann's students at Princeton, and later a faculty member at the University of Illinois, recalled that the graduate students were being "used" to hand-assemble programs into binary for their early machine (probably the IAS machine). He took time out to build an assembler, but when von Neumann found out about it he was very angry, saying (paraphrased), "It is a waste of a valuable scientific computing instrument to use it to do clerical work."

So in the early days of computing, translating into machine code by hand was such a routine practice that it was disputed that tools were even needed.

Similarly, in the early days of microcomputers, it was not uncommon for programmers to have memorized the hex values for most instructions (even in cases where they had assemblers, the debuggers available did not always have disassemblers).

Nowadays, there's generally no reason not to bootstrap with a cross assembler.

Answer 3

A primitive assembler just isn't that hard to write.  I've written a simple assembler/disassembler in Excel, for example — just a series of lookups really.

All you need is a very simple parser for the each line, a simple dictionary for labels, and a list of forward references that require later fixups.

There are also many possibilities for short cuts, i.e. requiring the opcode name to uniquely identify the expected arguments, minimal or no pseudo instructions, no arithmetic expressions, etc..

Making it easier is that early machines had fewer instructions and simpler addressing modes. The case you're citing even uses one letter opcodes, with what looks like a fixed argument set.

The initial assembler's code doesn't even have to be efficient, or robust to size of input, so can use fixed sized arrays (that would run out of space with input too large), and linear searches (instead of hash tables or linked lists even), for example.  Error handling and messages don't have to be good, either.  Once you've got the basic mnemonics you have basically bootstrapped the assembler.

---

How do you write the assembler v0.00 for a given brand new cpu?

This is relatively easy, you just use an older machine that already has a programming language.

Answer 4

Writing an assembler at any point in time is the same as writing any other program. If you were dealing with a new chip with a completely novel architecture that wasn't binary compatible with any other chip, then you would use that chip's specification to create a mapping from the lines of the high-level language to the lines of machine code. Otherwise, you would base your program on the assembler for some similar chip.

This mapping program could be implemented in any language on any computer. People have done it in Excel, and I've done it in Python using regular expressions. In the past, they would've written it in the tools of their time punch cards, switches, hammer and chisel, or whatever else.

The chip's architecture manual describes the processor's registers, supported operations, opcodes, etc... The tasks of writing an assembler is the task of translating a high-level description of an algorithm into a description that is compatible with what is described in the manual.

I don't envy this task at all, lol. And if you look at the size of that manual, you will get a sense of why completely new architectures don't come out very often.

Answer 5

Slightly off topic but the software used in the Apollo moon missions was "knitted" by hand.

Hundreds of tiny magnetised ferrous rings were threaded together the presence of a ring at a particular location interpreted as 1 the absence as zero.

https://en.wikipedia.org/wiki/Core_rope_memory