Shop OBEX P1 Docs P2 Docs Learn Events
Finding spin object size — Parallax Forums

Finding spin object size

sbk58sbk58 Posts: 12
edited 2010-02-21 18:13 in Propeller 1
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.

Comments

  • AleAle Posts: 2,363
    edited 2010-02-20 18:46
    If you use BST (Brad Spin Tool) or homespun you can get a list of your compiled program. One of the variables points to the end of all programs... VBASE and it is used as global pointer afaik.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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
  • sbk58sbk58 Posts: 12
    edited 2010-02-20 19:10
    Hi Ale...

    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.
  • Dave HeinDave Hein Posts: 6,347
    edited 2010-02-20 19:25
    The stack starts after the end of the program, so you could use the address of a stack variable to indicate where the code ends.· I did an F8 on one of my programs, and it shows the image as 296 longs, or 1,184 bytes.· The address of the first stack variable is $4BC, or 1,212 decimal.
  • sbk58sbk58 Posts: 12
    edited 2010-02-20 19:43
    Hi Dave...

    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.
  • sbk58sbk58 Posts: 12
    edited 2010-02-20 20:15
    Spoke to soon...

    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.
  • BradCBradC Posts: 2,601
    edited 2010-02-21 00:59
    After reading your posts again I'm now quite confused about what you actually want.

    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.
  • BradCBradC Posts: 2,601
    edited 2010-02-21 01:58
    It has been pointed out to me that String(0) does not work under the Propeller tool. I guess I can see why that makes sense.

    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.
  • sbk58sbk58 Posts: 12
    edited 2010-02-21 03:40
    This looks like it could work I will give it a try. Thanks

    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.
  • BradCBradC Posts: 2,601
    edited 2010-02-21 03:46
    Gotcha.. then yes, this should do what you want.

    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.
  • sbk58sbk58 Posts: 12
    edited 2010-02-21 16:50
    Hi Brad

    Tried your idea out and seams to work.

    Thanks again...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Programing is a team sport.
  • AribaAriba Posts: 2,690
    edited 2010-02-21 18:13
    My understanding of the structure of an object is this (if you have 2 DAT sections):
    .--------------. <-- 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
Sign In or Register to comment.