My assembler "translates" PongL fine. In order to write the primary parser for assembling Pong.asm (ie sorting out all the labels and variables etc) I thought i'd compare the two files (PongL.asm vs Pong.asm) to get a feel for what's going on as it were.
So having deleted all the comments at the beginning of each program, so that line 1 is line 1 of the code; I've noticed a couple of things, it would seem that R16 and R17 (i haven't checked for R18) are no used to store any variables as i would expect.
Isn't the start of the variable memory list at R16 ?
Also in Pong.asm the first variable is at line 141, sys.init. Surely the parser i'm going to write would assign the first variable it comes across to R16. In PongL it's memory address is 27058. Again the second variable is @memory.alloc which is assigned 8643.
Finally, a comment really at line 150 (ball.new) would appear to go against the naming convention of labels being in capitals...
Have I totally grasped the wrong end of the stick ? I did read something about operating system commands on this forum maybe, but i can't find the post.
Thanks in advance for any replies,
All the best, Loz
I'm not completely sure what you are comparing to what. Are you comparing YOUR asm output for PongL to the authors' Pong.asm?
I do know that I have seem some places where the authors did not follow the conventions that they laid out. They are, after all, conventions and not laws. When they are tweaking things manually for one reason or another it can be hard to stay strictly compliant, though it is a goal that should be striven for in material like this.
Recall that the order of translation determines the order in which variables will be encountered by the assembler and that the .vm files can be translated in any order.
Sorry for not making that clear, i am comparing the example Pong files suplied by the project. In the pong folder in folder 6 there are two files PongL.asm and Pong.asm. They are included as part of project 6, and we haven't done anything about vm yet...
Thanks for your reply
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)
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? As I've said previously Registers 16 and 17 are just used as empty spaces to store values, it looks like 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 !
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.
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.
Well, those sound an awful lot like variables, to me.
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.
|Free forum by Nabble||Edit this page|