Re: Problems understanding Hardware/Software interface

Posted by WBahn on
URL: http://nand2tetris-questions-and-answers-forum.52.s1.nabble.com/Problems-understanding-Hardware-Software-interface-tp4032625p4032813.html

I think part of your problem is that you are trying to understand the entire forest when all you have seen so far is some of the trees. To use some other analogies, it would be like taking a machine shop course in which you will build an entire engine from scratch and then, after the first couple lessons where you build the pistons, connecting rods and valves getting ahead of yourself and being confused by how the valves know when to open. You haven't built enough of the machine yet to answer those questions. Continuing with that analogy, you are also essentially asking how the fuel needed to run an engine can possibly be delivered by a truck that has an engine in it when we haven't finished building an engine yet.

So perhaps this might help with some of the big picture difficulties you are having, at least long enough for you to get to the point where you have built enough of the machine and software to understand it far better.

Just like we can use a truck that has an engine to deliver the fuel and other things we need to make THIS engine, so too can we use other computers to write and compile the assembler that we will use to assemble programs for THIS computer. We don't have to do absolutely everything to make THIS computer using only what we have available with THIS computer at any given moment. That would be akin to walking into that machining class on day one and being told that before you can make a piston you have to make a lathe and before you can do that you have to make a steel foundry and before that you have to mine the ore and before that you need to make some tools out of stones you find lying around, so let's get started.

Now, it is completely reasonable to ask how the first assembler was ever written if all assemblers today are written on computers using a high-level language and compiler and so forth. Fair question -- and one whose true answer is almost certainly very complicated and largely lost to history because, like so many things, computer technology has been a highly diversified, decentralized, and incremental evolutionary process. But here's what I hope you find to be at least a conceptually plausible route. At one point we had computers that were not stored-program computers. Instead, the "programs" on these computers were actually circuit boards that were hardwired to do a certain task and we changed programs by physically swapping out boards. So when people started exploring stored-program computers, they had these other computers available that they could wire up a suitable board for and have it do some of the processing that the new computer wasn't ready for yet. Also, even if they didn't have that, writing the first version of an assembler directly in machine code is far from a herculean task because the first one doesn't have to be a full-up assembler. It only has to be capable enough to be used to make a better second-version of the assembler. It doesn't take long at all before you do have all the software tools you need write and assemble programs using an evolutionary chain of software that never used anything but that hardware. Not the way you would like to do it and not the way anyone ever had to do it, but it CAN be done.

It's sorta like the lathe in that machine shop. That lathe was built using a lathe, but if you walked the history back you see the common theme that a lathe with a given level of capability was first built using lathes of lesser capability and, at some point, were built with lathes that no one today would even recognize as such.

As for why explore the machine language before building the CPU. Well, they had to choose which one to present first and that's what they chose. They could have chosen the other way and, if they had, people such as yourself would be asking similar questions going the other way -- how do we know we need to have this Mux at that point and why to we route that signal to there? The answer would be because that's what's needed to carryout the instructions in the machine language that you haven't seen yet. In our case, the answer to many of the questions about why the machine language is the way it is is because that's what the hardware that we haven't seen yet can do. In actuality, the machine language and the hardware design would have occurred at the same time in a very iterative process that eventually settled on what the authors chose. But presenting it that way, while interesting and instructive and suitable for courses focused more on the engineering process, would be a huge distraction given the educational goals that the authors are trying to achieve here, so they present them separately in such a way that how one influenced the other is largely ignored.