Exporting symbol table

The Wangster

I need to know the addresses of certain labels in my propeller asm code. I currently am doing this manually, which is very time consuming. Are there more efficient ways to do this?

Thank you.

Kaio

Did you need to know this at runtime or need you the addresses in binary file?

Anyway the Prop tool does not support the export of label addresses.

The Wangster

I need the addresses of the labels starting from Cog RAM (this is known at compile time).

Paul Baker

Use the label itself and the compiler will automatically resolve it based on it's context, if used in Spin it will use the hub address, if used in assembly it will use the cog·address.

<edit> Thanks CJ for pointing out my typo </edit>

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Post Edited (Paul Baker (Parallax)) : 4/28/2007 6:15:05 PM GMT

CJ

if used in assembly it will use the cog ram address, please note that this will be according to the latest ORG before the label itself

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Parallax Forums - If you're ready to learn, we're ready to help.

The Wangster

No, I need to extract the addresses into a separate file.

Paul Baker

Theres no utility to perform this other than your hand caclulation, you still haven't really said why you are doing this.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

The Wangster

I'm developing my toy Forth interpreter, and to make the interpreter simple, the bytecode for primitives addresses cog RAM directly.

On a side note, can you modify propasm to do this?

Paul Baker

Modifications to the compiler would take months, and any time spent in modifying it would nessesarily delay development of the next Propeller chip by approximately 120% of the time spent on the compiler changes.

That said, there is always more than one way to skin a cat (this is why I asked what exactly you are trying to do). You can create a monitor program which uses·offsets within hub memory to calculate the addresses.

So lets say your assembly code label structure looks something like:

       org
istart
 
proc1
 
proc2
 
proc3

·So while this assembly code is sitting out in hub memory, those addresses resolve to thier physical location in hub memory, and any program written in Spin simply needs to compute (proc1 - istart) to calculate what the equivalent address of the label is when it's loaded into a cog. Spit the entire series of label resolutions back to the PC via FullDuplexSerial and you can cut and copy the values back into your bytecode compiler.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Post Edited (Paul Baker (Parallax)) : 4/28/2007 10:31:22 PM GMT

CJ

wangster,

how much spin are you using to do this? if it is REALLY minimal, I may have a way to get the hub absolutes with little effort.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Parallax Forums - If you're ready to learn, we're ready to help.

The Wangster

[noparse][[/noparse]quote]On a side note, can you modify propasm to do this?

I wasn't asking Paul to do it, I was asking if it can be done. And how long would it take?

I wrote the whole thing in ASM for speed. SPIN is only used to launch the program.

CJ

the Top object file has a program offset for the absolutes of $10, so you can, with the compile time use of "@"
get the compiler to list quite neatly the hub absolute address, or the cog register that will contain the instruction pointed to by the label

in a DAT section of the top object file

long @label + $10

this will produce the absolute hub address of the labeled location. note: this does not work to locate VARs

long label

this will produce the cog register associated with the label

you can use these to produce an easily readable list in the compiler output, or you can use them directly in your ASM program

DAT
long byte"HUBr"
long @asm + $10, @asm2 + $10, @asm3 + $10

this will produce a list in the compiler output window with "HUBr" as the locator word, the 3 longs following it are the addresses.
the data is in little endian, so each long starts with the low byte then moves up towards the high byte

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Parallax Forums - If you're ready to learn, we're ready to help.

Paul Baker

CJ, that works for the first assembly block, however any additional blocks your technique couldn't handle. My suggestion for the monitor program is a diagnostic tool to be used during the development of the interpretor. Once you have finished making changes to the interpretor, and you have all the offsets you need, you remove the monitor and you are back to your slimmed down version but your values for your labels will work within the cog regardless of the assembly's location.

Wangster, have you looked at Cliff Biffle's Forth for the Propeller?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

CJ

the cog addresses come out ok across DATs and ORGs, the only part that I have yet to check is when there is more than one spin file containing the assembly code, I would expect that it would require locating the proper offset, but that would probably change as you make changes to the spin files

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Parallax Forums - If you're ready to learn, we're ready to help.