How are blocks laid out in memory?
ags
Posts: 386
Experimenting with the object viewer leads me to this conclusion:
1) CON blocks don't exisit in memory, all references to constant values are resolved at compile time
2) DAT blocks are next; multiple DAT blocks in the same object are all appended together, in the order they occur in the object. There is exactly one ocurrance of a DAT block in a program, that is, if multiple objects of the same type are included in a program, there is only one copy of the object (type) DAT block; there is some magic value in the first bytes of the consolidated DAT block that appears to include, among other things, the length of the DAT block (this is just a guess based on my test cases)
3) PUB/PRI blocks next; same "only one copy" situation as DAT blocks
4) VAR blocks next; each copy of an object gets its own VAR block in memory
5) OBJ blocks are like #include in C; they are resolved at compile time and don't exist (directly) in memory.
Is this correct? Once I have this figured out (confirmed by the experts here) I'll move onto some of the implications for PASM code, the org directive, how/where contents of cog RAM are copied from hub RAM, etc. That's what brought me back to this topic.
BTW, I have RTFM (Properller Manual v1.1) - but there isn't a lot of detail there. Is there another source of documentation that I could use to learn this? I'm sure for the experts here these are pretty basic questions that really could/should be answered (or discoverable) by reading some good documentation.
Thanks.
1) CON blocks don't exisit in memory, all references to constant values are resolved at compile time
2) DAT blocks are next; multiple DAT blocks in the same object are all appended together, in the order they occur in the object. There is exactly one ocurrance of a DAT block in a program, that is, if multiple objects of the same type are included in a program, there is only one copy of the object (type) DAT block; there is some magic value in the first bytes of the consolidated DAT block that appears to include, among other things, the length of the DAT block (this is just a guess based on my test cases)
3) PUB/PRI blocks next; same "only one copy" situation as DAT blocks
4) VAR blocks next; each copy of an object gets its own VAR block in memory
5) OBJ blocks are like #include in C; they are resolved at compile time and don't exist (directly) in memory.
Is this correct? Once I have this figured out (confirmed by the experts here) I'll move onto some of the implications for PASM code, the org directive, how/where contents of cog RAM are copied from hub RAM, etc. That's what brought me back to this topic.
BTW, I have RTFM (Properller Manual v1.1) - but there isn't a lot of detail there. Is there another source of documentation that I could use to learn this? I'm sure for the experts here these are pretty basic questions that really could/should be answered (or discoverable) by reading some good documentation.
Thanks.
Comments
There are "magic control blocks" in memory for each object instance. These object tables have pointers to the DAT and VAR areas for the object and pointers to each PUB/PRI block in the object. Each such table also has pointers to any subsidiary objects referenced. These tables allow PUB/PRI method calls to use the local method # rather than an address in the generated code. It also allows the code to reference variables without knowing which instance (of the VARs) is being referenced.
Cog RAM is always either the Spin interpreter copied from ROM or the 496 longs starting at the address given in the COGNEW/COGINIT statement. If the assembly code is shorter than 496 longs, there's still 496 longs of data copied to the cog RAM. The cog RAM following the compiled code will contain whatever happened to be in memory beyond the compiled code.
A DAT section uses two different memory pointers. One such pointer has the address where the next data item will be placed. This is a byte address. The second pointer is initialized to zero at the start of the first DAT section in an object and it can be changed by the ORG statement. When an assembly label is declared, both pointers are stored with the label. The second definition is what is used for any operands in assembly code and is a long word address.
There is a description of the object table format and the general layout of a Spin program in memory. Look here under Spin Bytecode.
http://forums.parallax.com/showthread.php?104847-Spin-Object-Binary-Structure
http://forums.parallax.com/showthread.php?96211
Andy