Finding spin object size
Hi;
I have a question with regard to the compiled object size using Parallax's Propeller IDE.
I wrote a 16 bit·Forth interpreter using Propeller assembly to implement a virtual CPU and the remainder of Forth is written in Forth using the DAT sections syntax in the IDE.
The Parallax IDE compiles each DAT section relative to the start of the object not the relative to the start of global memory. To compensate for this I created a few spin routines to correct the addresses in the DAT section and to optimize the Forth code in the DAT section when the object is started. Once the COG is running and the virtual CPU is started I no longer need the spin code in the object.
I noticed in the hex display of the code image that the spin code lives directly after the end of my last DAT section in the object. I would like to reclaim this memory after the virtual CPU cog is started. I have two main questions;
1) Is there any way to find the end address of the object or its total size from within my program?
2) When spin procedures are compiled into the object image are the procedures added to the image in the order they are declared or in some other order?
Thanks in advance for any help....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programing is a team sport.
I have a question with regard to the compiled object size using Parallax's Propeller IDE.
I wrote a 16 bit·Forth interpreter using Propeller assembly to implement a virtual CPU and the remainder of Forth is written in Forth using the DAT sections syntax in the IDE.
The Parallax IDE compiles each DAT section relative to the start of the object not the relative to the start of global memory. To compensate for this I created a few spin routines to correct the addresses in the DAT section and to optimize the Forth code in the DAT section when the object is started. Once the COG is running and the virtual CPU is started I no longer need the spin code in the object.
I noticed in the hex display of the code image that the spin code lives directly after the end of my last DAT section in the object. I would like to reclaim this memory after the virtual CPU cog is started. I have two main questions;
1) Is there any way to find the end address of the object or its total size from within my program?
2) When spin procedures are compiled into the object image are the procedures added to the image in the order they are declared or in some other order?
Thanks in advance for any help....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programing is a team sport.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
pPropellerSim - A propeller simulator for ASM development sourceforge.net/projects/ppropellersim
Thought about using another tool set for the project but I would like to keep the project in Parralax's IDE if possible.
I can see the end address of my code in the hex display so I can always hard code the address into a constant. The problem with this is every time I make a change to the project I would have to change the constant.
I do not need to know the end address of the program (right now) but the end address of my object that implements forth. Do you know if BST (Brad Spin Tool) or homespun can provide the end address of my object from within my program?
I think if I had to learn another tool set for the Propeller chip I would probably learn to use PASM over another spin based tool....
Thanks...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programing is a team sport.
Saw the variable allocation in the hex display but never thought of creating a dummy variable to use as an address reference.
Good idea thanks....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programing is a team sport.
It apears that when you have multiple spin objects with variables all the variables are gathered at the end of the program not the end of each object.
If I use a variable's address as a refrence it will point past the end of all spin code and not just the spin code in my Forth object...
Seamed like a good ide.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programing is a team sport.
If you simply want to know the address of the last byte of the object place a PRI method right at the end.
PRI Get_Last_Address return String(0)+1
PRI methods are compiled last in the object and are compiled in order they are parsed in the file
String() constructs are compiled at the end of the spin method and zero terminated, so that will place $00,$00 at the end of the spin method.
The String() construct will return the address of the first byte in the string, so String(0)+1 will return the address of the end of the method, which also happens to be the end of the object.
Local Parameter DBASE:0000 - Result |===========================================================================| Addr : 0018: PBASE Constant Address of Label0002 Addr : 0018: 87 0E : Memory Op Byte PBASE + ADDRESS Address = 000E Addr : 001A: 35 : Constant 1 $00000000 Addr : 001B: EC : Math Op + Addr : 001C: 33 : Return value Addr : 001D: Data : 32 2 Addr : 001E: Label0002 Addr : 001E: Data : 00 00 ..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Substitute String(1) and it's all good.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
As to what I want to;
My forth code is made up of COG asm code followed by a DAT section that contains the forth dictionary.
The spin code in the forth object is only required at startup to adjust the adress pointers in the forth dictionary.
Once the forth object is started the spin code is just wasted memory space (@ 800 bytes).
As you compile forth words into the dictionary the dictionary grows towards high memory.
The memory ocupied by the spin code for the forth object is located after the end of the hard coded forth dictionary portion of memory.
if I know where the end of the spin code is in memory I can reuse the memory to extend the forth dictionary.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programing is a team sport.
kuroneko kindly pointed out my original String(0) was broken on the official Parallax compiler. It is allowed on bst[noparse][[/noparse]c] due to a bug, but that will be fixed in the next release.
For reference, you can find the start of the stack area (after all objects and variables) by looking at the address at word[noparse][[/noparse]$A].
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Tried your idea out and seams to work.
Thanks again...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Programing is a team sport.
.--------------. <-- object start | Jump Table | .--------------. | DAT 1 | .--------------. | DAT 2 | .--------------. <-- Addr you need | PUB+PRI | .--------------. | VAR | .--------------. <-- End of Object | Stack after | | last object |
To get the end of the forth dictionary, place a dummy long with a label at the end
....
dict_end long 0
then you get this address inside a Spin PUB with addr := @dict_end.
To get the end of the object, place a dummy byte variable at the end of the VAR section
VAR
....
byte obj_end
And you get again the address with addr := @obj_end inside Spin.
(It must be a byte variable because the compiler sorts the variables in memory about the size: longs-words-bytes).
Andy