From ASCII to real binary values on hardware.

[Victorrct]

Hi,

I'm having some trouble understanding how the software hierarchy will work.
I understand the architecture and how the binary values in the ROM work, but I don't know how we go from a text file with machine code (.hack) to actually binary values in the ROM.
Because it's a text file, each "1" and "0" are ASCII characters.
So, how do we go from ASCII to real binary values on hardware?

Thanks.

[ybakos]

True, an assembler typically translates assembly language code into binary. In our case, the translation from assembly (.asm) to .hack doesn't result in a binary file. This is so that we can read the 1's and 0's easily with a text file. We absolutely could write the assembler such that it translates each line of assembly into 16 bits.

To simplify, it's a matter of writing one's assembler such that, instead of writing the characters 1 and 0 to a text file, you write binary values to a file. Once the binary file exists, it's a matter of copying that data to ROM. (Mark may describe that process further, since he's got a lot of experience with hardware.)

[cadet1620]

Victorrct wrote

I'm having some trouble understanding how the software hierarchy will work.
I understand the architecture and how the binary values in the ROM work, but I don't know how we go from a text file with machine code (.hack) to actually binary values in the ROM.

Think of the output of the assembler as another intermediate "language". There is another tool that reads that language and loads it into the computer where it can be executed.

In a general purpose computer like a PC, the executable files are loaded into memory by a part of the operation system called a loader. In a ROM-based computer, the ROM is written using hardware tool called a ROM programmer.  

The "Load Program" command on the Hack CPU Emulator is the simulated ROM programmer.

There is often another step in the software chain between the assembler output and the executable files. A linker combines multiple assembler object files and libraries to create the executable file. To support linking, the object files contain additional information telling what external functions they need and what functions they contain that external functions can call.

--Mark

[Victorrct]

The Assembler that we will build will not be suported by the Hack platform, right?
Because it iscompiled to a different architectrue (for exemplo, x86).

So, am I correct to assume that the Hack computer will always be dependent on another computer to load the programs into the ROM?

Thanks a lot.

[cadet1620]

The assembler that you build will write .hack files on your PC or Mac. The CPUEmlator, which runs on that same PC or Mac will be able to load these .hack files and run them.

If the Hack computer were a real piece of hardware, then your assembler running on a PC or Mac would be called a crossassembler, and another physical tool would be required to get the code into the Hack computer.

--Mark

[cadet1620]

Sorry, I think that I misunderstood your comment.

You are saying that the assembler that you write on your PC is compiled to x86 instructions, hence the assembler cannot run on a Hack computer.

That is correct.

Your Hack assembler is a crossassembler since it runs on x86 and generates Hack instructions.

If the Hack computer was expanded and supplied with peripherals like disk, and a way for it to program its own ROM, then it could run an assembler.  The current tool set: Jack compiler, VM Translator, Assembler, could be used to write that assembler.

Its an interesting process to develop the first tools for a newly designed processor.

--Mark

[Victorrct]

Thanks, that makes sense.

Just to see if I understand:

Suppose I wanted to physically build the Hack computer and a way for it to program its own ROM.

I would have to create a program that translates .hack into .exe (this program is called a linker), and a physical tool that loads the .exe file into the ROM (a ROM programmer).

First, I use the PC to create a linker that will work only on the PC.
The .exe file, produced by this linker, is compatible with the Hack architecture, but not with the PC.
But, the linker (which is a .exe file itself) will only work on the PC. ("cross linker").

So, the Hack computer would depend on this linker, therefore, it would still depend on the PC.

For the Hack to be independent, we could develop another linker that would work on the Hack platform.
We do this by programming it in some language.
But we don't compile it to a .exe that will work on the PC.
Instead, we compile it to .hack and use the previous linker to produce a .exe that will work on the Hack platform.

Finally, we use the ROM programmer to load it into Hack.
Then, the Hack would have its own linker working on its platform.

We could use the same process to build an Assembler (and all others translators) that will work on the Hack platform, instead of a cross assembler.


Is this reasoning right?

Thanks again.

[cadet1620]

Yes, that's the overall picture.

There are a lot of details that would need to be worked out to make a useable general purpose Hack computer, starting with writable code memory so that programs could be loaded from a storage peripheral (disk, etc.).

--Mark

[Victorrct]

Thanks! This was helpful.

Victor

[abryant24]

What all needs to be added hardware and software wise to make a usable general purpose computer?

I'm also curious about the process how we could write an assembler in machine code so that it could assemble itself.

I'm curious how we get  I/O processing from a keyboard and screen to write the assembler.

It would be nice if there was another section in the book explaining all theses missing parts because I think this chapter is the biggest confusion point from me at the moment about how we go from hardware to software, and how we use software to control hardware.

I saw this post and the link to the pdf here:

http://nand2tetris-questions-and-answers-forum.32033.n3.nabble.com/Thought-a-lot-about-assembler-from-the-book-but-disappointed-td4030047.html

But, it is quite a lot of reading. Any simple or brief explanation would be most appreciated.

[ivant]

abryant24 wrote

What all needs to be added hardware and software wise to make a usable general purpose computer?

To make it a more conventional computer, I'd first go for the Von Neumann architecture. This will make it possible to load different programs instead of having one program in ROM.

I'd also add some sort of storage device, so that my programs and data don't get lost. Beyond that one can expand the instruction set, extend the addressable memory, have a better graphics (including double buffering), add mouse and network support, etc.

abryant24 wrote

I'm also curious about the process how we could write an assembler in machine code so that it could assemble itself.

This comes out often. You can read this thread or search the forum for more.

abryant24 wrote

I'm curious how we get  I/O processing from a keyboard and screen to write the assembler.

It would be nice if there was another section in the book explaining all theses missing parts because I think this chapter is the biggest confusion point from me at the moment about how we go from hardware to software, and how we use software to control hardware.

Assemblers aren't really relevant here. This is a question about computer architecture instead.

Real world computers use specialized controllers to communicate with the hardware. They generate video signals from memory values, read tapes and disks in memory, handle keyboard input, etc. They also need to communicate with the CPU and often to directly access the RAM. The CPU may have specific pins and instructions for that, or it may just use the normal "memory" address and data buses.

Practically all CPUs also support interrupts. These are pins, which when set high (or low) tell the CPU that something requires its attention. The CPU would normally save its current state and just on specific address to execute code for handling this. This can be used for example by the keyboard controller to indicate that a key is pressed or released.

There is also DMA or direct memory access, which enables a controller to read or write to specific parts of the RAM without going through the CPU. This is much faster and also enables the CPU to do other things at the same time.

So suppose you're writing a OS routine to read a specific sector from the disk and store it at a given address in RAM. The program can set the sector address, the ram address and the operation (e.g. read or write) in some pre agreed places in memory, which are handled by the controller. The controller would then read the data from the disk and, using the DMA, write it directly in the specified memory location. When it's finished, it would send and interrupt to the CPU, to indicate that it's done.

Note, that this is a very high-level overview and I'm glossing over a lot of important details. Also, I'm a developer and my OS tinkering was mainly in the Apple 2 and early MS-DOS days. So, hopefully the expert will chime in and correct me if I totally misled you. :)