How to get memory base adresses

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

How to get memory base adresses

Scatman_John
Hello,

I'm wondering on how we are supposed to acquire the base adresses for the different memory segments.
Are our programs supposed to read them from the .tst files? When I have the adresses I was thinking of handling the segments with a seperate class(java) and an arraylist.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to get memory base adresses

ybakos
Just to check, do you know where static, the stack, and the heap all start? Those do not change. Neither do temp or pointer, really.

The base address of the other segments are stored in LCL, ARG, THIS and THAT.

The test scripts bootstrap the ram and explicitly set addresses in LCL, ARG, THIS and THAT.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to get memory base adresses

Scatman_John
Yes I know the places for static, stack etc. But the other LCL, ARG, THIS and THAT confuse me cause they have no standard address. How is my program supposed to access those addresses? The way i'm thinking of doing it now is to read the .vm file and then translate it into assembly code. However there are no base addresses for LCL, ARG, THIS and THAT in the .vm file.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to get memory base adresses

cadet1620
Administrator
Scatman_John wrote
Yes I know the places for static, stack etc. But the other LCL, ARG, THIS and THAT confuse me cause they have no standard address. How is my program supposed to access those addresses? The way i'm thinking of doing it now is to read the .vm file and then translate it into assembly code. However there are no base addresses for LCL, ARG, THIS and THAT in the .vm file.
The base base address for the "local" segment is the contents of the LCL variable which is at a fixed memory address. LCL is one of the predefined labels in the assembler.

The LCL and ARG variables will be set by the code that your VM translator writes for the "call" command in project 8. The THIS and THAT variables will be set by "pop pointer 0" and "pop pointer 1" commands written by your Jack Compiler.

Since the test scripts don't run complete programs, they need to initialize SP, LCL, ARG, THIS and THAT to simulate the environment that would exist if a real program was running.

--Mark

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to get memory base adresses

Scatman_John
cadet1620 wrote
The base base address for the "local" segment is the contents of the LCL variable which is at a fixed memory address. LCL is one of the predefined labels in the assembler.
Yes I see that LCL is stored at RAM[1], but how do I get its' contents(local)? Where is the local segment supposed to start? In the .BasicTestVME.tst for example they set it up like this:

set sp 256,
set local 300,
set argument 400,
set this 3000,
set that 3010,

But the .vm files we are supposed to import to our programs don't specify anything like this, so I don't know where to put the local arguments in my "stack".   Thanks for your answers but this is a very confusing chapter for me. :)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to get memory base adresses

ybakos
Scatman_John wrote
But the .vm files we are supposed to import to our programs don't specify anything like this, so I don't know where to put the local arguments in my "stack".
It's always relative to the address stored in LCL. You can assume that LCL will always have an address, and that address represents the base address of the local segment. Same for ARG and argument. Consider how the stack works. Your vm program never needs to "know" where the stack is - it always relies on whatever value is stored in SP.

Consider BasicTest.vm. The first two vm instructions are:

push constant 10
pop local 0

Since LCL contains the value 300, the local segment starts at 300. So after the above two commands execute, where is 10? It should reside in address 300, the "0th" address of the local segment. How do we know this? Because LCL contains 300, and pop local 0 means take the value on the top of the stack and store it the address that is 0 plus the base address of local.

If the commands were:

push constant 10
pop local 2

Then 10 would be stored in address 302. Why?

Your goal for Project 7 is to create the ASM code that would result in these behaviors. You should have already translated push constant. For example, push constant 10 translates to "use the stack pointer to determine the address of the top of the stack, store the value 10 there, and increment the stack pointer."

What does the command pop local 2 translate to?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: How to get memory base adresses

rgravina
I was quite confused by this also, but I think this post here clears it up http://nand2tetris-questions-and-answers-forum.32033.n3.nabble.com/Where-to-map-lcl-arg-this-that-tp4027869p4027870.html

In Chapter 8 these different memory segments will be put in certain locations in order to implement function calling. However, in Chapter 7 all we know is that these segments exist, and just need to be able to push to and pop from these segments. That's why the VM test setup code arbitrarily chooses some locations - for now all we need to implement is push/pop at the addresses starting at the values put in @SP, @LCL, @ARG, @THIS and @THAT at startup.

This was explained in the section "Tips - Initialization" in the text, but I didn't quite understand it the first read through. Re-reading it now it does make more sense, but it would be nice if somewhere in the text it was made very clear that memory segment address will be chosen arbitrarily by the test script and running a program without using the test script won't work - unless you include similar instructions at the top of your program. And, that for the purposes of implementing what's needed for now, arbitrarily chosen RAM locations are OK.
Loading...