How the very first Assembler

[ajilraju]

Hello :),

           Now we have high-level language like python, java etc... used writing the hack assembler, we already exploit the underlay abstraction of all computer part, still i have one doubt how the programmers write very first "Assembler for the very first computer, means symbolic assembly language". Could you please explain to me how this thing is happens. that is my last black box in the part1 of this course.

Thanks,

[WBahn]

ajilraju wrote

Hello :),

           Now we have high-level language like python, java etc... used writing the hack assembler, we already exploit the underlay abstraction of all computer part, still i have one doubt how the programmers write very first "Assembler for the very first computer, means symbolic assembly language". Could you please explain to me how this thing is happens. that is my last black box in the part1 of this course.

Thanks,

Pretty simple, actually -- at least in principle. They came up with the language they wanted and then wrote a small program on paper that could assemble a carefully chosen subset of the language. They then assembled this program into machine code by hand and loaded it into the computer. That program had the ability to assemble a more capable assembler that was written using only the commands in the subset, but the new assembler had the ability to process a larger subset. After a few iterations you had an assembler that could assemble the entire instruction set, but that probably could not do anything else such as process labels. So now you write a more complex assembler that could do those things. At some point along they way you also wrote a very simple editor (usually a line editor) that would allow you to enter and alter your source code documents.

[salallegra]

Hi, I want to do the NAND to TETRIS work but I will not do it until I find out how the birth of abstractions occurred in computing systems.  Can someone REALLY please help me with the details and understanding, or point me towards a resource that can.  I've scoured the internet, looked at peoples posts in forums and there is not enough detail to satisfy my understanding. I'm sure some of my post here will be inaccurate do to my misunderstanding, but I need closure on this topic.

This is the closest thing I've found to understanding this

   https://www.eeweb.com/building-a-4-bit-computer-assembly-language-and-assembler-part-2/

The first above image is a .asm file.  The file is composed of text.  The .asm extension is text......How in the heck did we get from machine code to text?  I can't even fathom images, guis, videos,  and all the other stuff.  I realize once you have an assembler or compiler the other abstractions can be made....I'm guessing it had to start with text because that's how we write assembly programs.....

In my understanding the earlier computers where the first assembler was built had punch cards or different type of interfaces for building the first "piece/iteration" of an assembler in binary.....Let's imagine we have a computer that doesn't know what text is, an image, a file, an operating system,  nothing!  It just has a monitor and keyboard attached to it, and it has a panel where you can enter machine code with buttons or switches and you can execute the machine code that is in memory like so....



What are the detailed steps to go from a program written in machine language to get to this?...

[WBahn]

I tried to explain this in the post above yours.

One thing that might be tripping you up is the notion that the machine that they programmed with switches was the same as the one for which you are showing the assembly code listing for. The first machines had extremely simple instruction sets.

For instance, consider the Intel 4004, which is the first integrated microprocessor to be commercially introduced in 1971 (so electronic computing technology already had well over two decades of evolution at that point). It had 46 instructions, so not even twice the number that the Hack has.

The development of computers, instruction sets, and programming languages was not a nice, neat, simple linear journey. Lots of different people tried lots of different things, using some of the things done by others in lots of different ways. Slowly things coalesced into what became "the norm" that we have today (and that is still evolving).

So the answer to your question is not simple and depends very much on what exactly it is you are looking for. If you are looking for the detailed history of how this all developed, you will need to go dig up and read the papers written by a lot of people. If you are wondering how you might go from a collection of electronic parts that includes, say, an Intel 4004 but with no software of any kind to a computer that can let you create, edit, save, and run Java programs then that is a very different question.

[salallegra]

Thanks for the response WBahn.  And I know you have no obligation to explain this

I see you tried to explain by responding to the OP.

I'm trying to understand the latter....an Intel 4004 but with no software of any kind to a computer that can let you create, edit, save, and run Java programs then that is a very different question.

So maybe here's a more useful specific question...All I have is machine language, how do we get to the first step of the computer understanding that certain values in memory are text?  Perhaps there is a "text" section in memory, such as the keyboard and screen memory maps/sections?

Thanks.

[WBahn]

The computer never understands much of anything. It takes data, which are nothing more than patterns of ones and zeroes, and it applies operations, which take patterns of data and make new patterns of data according to the instruction. That's pretty much it. What those patterns mean is completely up to the person that is writing the list of instructions that constitute the program that is going to be run.

So I might design a circuit that lets me program a ROM by pressing a button to set a counter to zero and then I can set a bunch of switches to the values that I want to program into ROM[0] and when I press another button is writes the values set by the switches into ROM[0] and advances the counter by one. I don't even need to get that fancy -- I could simply have two sets of switches, one to set the address and one to set the values and a button that toggles the WRITE signal on the ROM. I've actually designed imager readout chips that used this very primitive control interface to program the configuration registers.

So, with no software at all, we can program ANY program we want into a ROM (or RAM, for that matter) that will run on the computer that we've built using our Intel 4004 and whatever other chips and parts we have available. But doing it for anything but the simplest programs will be very time consuming and error prone.

One of the first things we will want to do is be able to take a program that is already in machine language and load that into our computer and then run it. Let's say that these machine instructions are punched into a paper tape or punch cards or any other device that we can prepare without needing to run a program that we've previously had to write. We then write a machine-language program that, when run on our hardware, will do nothing but load whatever program is stored on our storage device into memory and set the program counter to the first instruction in order to start the program running. That program is very simple and very short and we could load it into memory using our switches or we could simply hard code it into a ROM and store it permanently with our computer hardware such that any time we reset the hardware, this short program runs first. We'll call this our "boot loader".

So now we have a way to load a program from a storage device, provided the program is in machine language. At some point very quickly we will get tired of writing out programs in machine language, so we will do it one final time and write a program that will read an assembly language program from one input device and write machine language instructions to an output device. This will allow us to assemble programs written in assembly language and store them such that we can later use our boot loader to load and run that program.

We could write the full up assembler for our final assembly language if we wanted to, but we will probably be better off walking up in baby steps. There's some real low hanging fruit here. First, we will have NO comments and NO spaces allowed in our programs. There will be exactly one instruction per line. We might also require all literal values to be in hexadecimal instead of decimal.

We might also put additional, temporary restrictions on our instruction format such having @-type instructions always consist of exactly four hex digits, using leading zeros if necessary.

For the C-type instructions, we can encode those using just three characters each if we wanted to, but four might make more sense.

Consider the format:
dest = operation ; jump

The 'dest' and 'jump' fields each have eight possibilities, so we could use '0' through '7' for each of them. For the operation, there are 28 of them, so we could assign all 26 letters of the alphabet plus two digits, say 0 and 1, to them, but instead we will simply use the two-digit hex value of the 7 bits that constitute the control bits. We further require that each instruction always have all three parts.

So a program snippet to load the value 42 into R9 might look something like:

@002A
2300
@0009
10C0

Not very readable for us humans, but most of it is actually pretty easy to get used to. But that's not the goal, the reason for doing this is that writing an assembler in machine code for this assembly language isn't too hard and, once we have it working, we can then write an assembler in this assembly language that relaxes the rules and gets us at least one step closer to our final assembly language, perhaps by letting use use the mnemonics for the C-type instructions and then, after that, letting the A-type instructions use decimal notation. After that, all we need to do is support white space and comments and we are done and now have a working assembler for our complete assembly language, but with no bells and whistles such as being able to use 'R5' or 'SCREEN'. Also, there's no error checking and reporting, so we might add those features next -- or we might hold off until we can write better versions of our assembler in either our VM language or in Jack.

So now let's get to the heart of what appears to be your issue -- the notion of text.

Assuming we are using ASCII to represent our programs in our storage medium, our program above would consist of 22 bytes (assuming a one-byte end-of-line character, say 0x0A).

Our machine language assembler will look at each byte and, based on its value and what state the program is in, it will do something appropriate. That 'something appropriate' will be building up a 16-bit machine instruction somewhere in memory and, when a new line character is detected, writing that 16-bit instruction out to the output-device as the next machine instruction in our assembled program.

It will do all of this by looking at the numerical value of the bytes presented as we read the input device. When it sees 0x40, it will take the next four bytes and, using just the lower nibble, will build up the 16-bit A-type instruction and write that out when it sees the 0x0A value.

[salallegra]

@WBahn, I'm going to take some time to digest this, thanks!  I'll get back to you.

This seems great, will take me a while, because I have to look things up to understand you

[salallegra]

Still trying to wrap my head around this in my busy schedule, will get back when I have time :-)

[Lozminda]

Hi, I thought I'd jump in and Not be very helpful..

In terms of development of technology, think about the evolution of the car, (the precursors would have been the horse drawn carriage and the steam engine). The first cars made in 1910 (ish), though they are similar (they have four wheels, a petrol engine, a steering wheel) are also completely different now a days (hey the petrol engine will go soon).
There have been many developments along the way, stuff has worked and stuff has failed (see the rotary engine as an example in car tech, though some folks are treying to revive it).
As computer hardware has developed so has the software developed, there was a stage where indeed how to render text to a screen was a hot topic wikipaedia , but those issues have long been solved (like say bearings in cars, prob sorted late 1800s)

Having said all that things like bootstrapping do seem like magic to me !

Good luck, sorry I'm not being very helpful, think of this as "moral support" !

Lozminda

[salallegra]

@WBahn

Thanks for the detailed explanation, I have it hazily but get the gist :-)

1.  We make a little boot loader in machine language that can load programs from disk into memory on computer startup.

2.   We make a baby assembler in machine language from our input device that can read a string of bytes encoded by the ASCII scheme that generates machine code that gets output to disk.  (Still hazy here, but that's ok.)

3.  We now load our baby assembler into memory that can read input from the input device(string of chars) and that will generate our machine code.

4,  We then keep building a better/bigger assembler by writing it with our baby assembler in assembly language (Hazy here a bit)


But that's a good enough understanding for me WBahn, I'll keep mulling over your explanation but this helps a lot.

[ivant]

Step 4 is more like "We then keep building a better/bigger assembler by writing it with our current assembler in assembly language".

That is,
1. using our current assembler, build a better assembler
2. set current = the new assembler
3. goto 1

This is not limited to assemblers. We can do that for compilers too.

[salallegra]

@ivant, sounds good