Lozminda wrote
Firstly WBahn, it appears to be you that's answering most of the Nabble questions at the moment so thank you very much indeed (possibly in a second language, if so doubly thanks if that's the case)
That's the way it's turning out at this time. As things on discussion boards tend to go, that will change eventually. Right now it dovetails with some other irons I happen to have in the fire.
In case this is of use to anyone else, chapter 6 does say the following (in the project part)
"The Pong program was written in the Jack programming language (chapter 9) and translated into thesupplied assembly program by the Jack compiler (chapters 10-11). Although the original Jack program is
only about 300 lines of code, the executable Pong application is about 20,000 lines of binary code, most
of which being the Jack operating system (chapter 12). "
Would that indicate (as it says nothing further) that my parser Isn't going to produce the same assembly?
I can pretty much guarantee that the assembly code you generate from the Jack source code isn't going to be the same.
First, your parser is just one piece of the process. To get to assembly code you need to first tokenize the Jack source code (using the syntax analyzer), then you need to parse it using your parser. Your output and the output of the authors tools to this point should agree (though there is ambiguity in the grammar, so this is not guaranteed). But since the relevant project has you testing your parser against the output of the authors' parser, you will likely modify your parser until it does match what their's puts out most, if not all, of the time.
But then there's the code generator. There are multiple ways to convert the Jack code constructs to VM code. You will almost certainly do many of these slightly differently (or perhaps drastically differently) than the authors did. Then, you need to translate the VM code to assembly code and, again, there are multiple ways to translate each of the VM commands and you will probably only end up with the same code for a few of them.
Finally, key aspects of the assembly code that is produced depends on the order in which the VM files are translated, so even if your compiler's code generator and your VM translator's code generator were identical to the that of the authors, if your VM translator and theirs doesn't access the files in exactly the same order, you would get quite different assembly code (though there would also be a very high correlation between the two).
Beyond that, eventually you will write your own operating system libraries and, once again, how you do it will almost certainly be quite different than they wrote theirs. So even if you used a single tool chain (compiler-translator-assembler), you would get vastly different output if you use the authors' OS libraries verses the ones you write -- especially since the OS libraries constitute a huge fraction of the final program in most instances.
As I've said previously Registers 16 and 17 are just used as empty spaces to store values, it looks like to me..
Well, those sound an awful lot like variables, to me.
To be honest non of this is very important, I can write the parser to parse the labels and just get on with it,(understanding the main principles is probably the most important thing) but it's nice to know if I've understood things correctly, or in fact have I misunderstood something.
Finally, I'll (say again) I think the course is great, however as someone who has designed syllabuses and taught occasionally it would seem a sentence or two extra here and there would clarify the odd point. But I'm really nit picking at this point.
Again thanks very much for reading all this, and perhaps replying too !
Loz
Adding some extra stuff here and there is almost always valuable -- the problem is that it is very difficult to know where the proper heres and theres are. If you add them everywhere they might be useful, you end up with a book that is several times bigger, takes a lot longer to develop, and sells for a lot higher price.
I was frankly amazed at the quality and blend of succinctness versus completeness that this text exhibits, especially for a first edition and even more so at this price point. That in no way means it's perfect. Part of the improvement process is that you put out the best that you can under the constraints you have to live within and then see what works well and what doesn't. I'm expecting the second edition (assuming there ever is one) will be a lot more polished, especially since I think they did such a superb job with the fundamentals of it that they don't need to overhaul much, if anything, and can focus primarily on polishing the presentation of the material.
Locked
