|
|
|
|
Our class is up to the VM part of Tecs right now, so I want to give some comments on what could be improved in Chapters 7 & 8.
There's a fair amount of talk about the stack operation, but not enough about segments: what they are, where they exist, how they get manipulated.
There needs to be a well-defined definition for each VM operation, like you see for instructions in CPU handbooks (I wish I could remember the term), e.g. for add:
temp1 <- pop();
temp2 <- pop();
result= temp1 + temp2;
push(result);
The VM is designed to support OO-style languages, but there needs to be more rationale about the design. Figure 7.6, for example, mentions the this, that and pointer segments, but comments like "Serve various programming needs" are not detailed enough. There needs to be more detail about what this and that are used for, and the relationship between this, that and pointer (and the exact purpose of pointer: not what it does, but why it is needed).
One of the big concepts with flow of control is the stack frame, which holds arguments, local variables and the state needed to restore the calling function/method. Figure 8.4 appears to be a stack frame, but exactly what the VM stack frame looks like, and why it looks like that, is needed.
So, it's a bit confusing in places! Overall the book is fantastic, but I feel that this area needs a bit more work.
|
|
|
I almost feel like after chapter 6, we should first stand at the other end of the abstraction stack and start looking down. For example, first create a program in a high-level language and then get that program to 'talk' to your machine via the lower abstractions (between high level and assembly).
I wonder if the authors considered this while crafting the book?
Anyway, I agree, the virtual memory segments and their purpose / meaning are left rather abstract during chapters 7 and 8. It leaves the students wondering, ok, why am I bothering with this whole VM translation again? The task that would gain some additional understanding in having crafted a high-level program first.
Your example of the traditional operation definitions (temp1 <- pop() and the like) brings up a question I have. At the assembly level, does it matter to actually perform all of the higher-order operations, and if so, why? For example, contrast the assembly instructions for those operations you listed with this:
d <- pop();
m=d+m
In other words, the assembly instructions can perform the operation without actually popping the top two members of the stack into temp registers and pushing a temp register back onto the stack. My question is, does this cause problems in the real world, and if so why? Isn't the final state of the operations more important than the specific instructions of the implementation?
This question also isn't brought up in those chapters (I think).
|
|
|
ybakos wrote
I almost feel like after chapter 6, we should first stand at the other end of the abstraction stack and start looking down. For example, first create a program in a high-level language and then get that program to 'talk' to your machine via the lower abstractions (between high level and assembly). ... The task that would gain some additional understanding in having crafted a high-level program first.
Yes, I think that a quick excursion up to Jack (i.e. Chapter 9) should precede Chapter 7/8, with some small amount of bridge material to link the HLL material and the VM material together.
ybakos wrote
Your example of the traditional operation definitions (temp1 <- pop() and the like) brings up a question I have. At the assembly level, does it matter to actually perform all of the higher-order operations, and if so, why? My question is, does this cause problems in the real world, and if so why? Isn't the final state of the operations more important than the specific instructions of the implementation?
This question also isn't brought up in those chapters (I think).
I would say that the final state is much more important than the intermediate stages, on the assumption that the stages can be performed atomically. If the whole action is not atomic, then the intermediate state becomes visible which would lead to bad side-effects.
|
|
|
Warren Toomey wrote
I would say that the final state is much more important than the intermediate stages, on the assumption that the stages can be performed atomically. If the whole action is not atomic, then the intermediate state becomes visible which would lead to bad side-effects.
Right, ok. It's the atomicity of the suite of lower level operations. Thanks for the insight.
|
|
Locked
