PDA

View Full Version : Exporting DAT symbols. How?



Phil Pilgrim (PhiPi)
01-16-2008, 04:14 PM
I need the addresses of DAT symbols in another object. I've tried obj#symbol, and that didn't work. So I defined a stand-in for the symbol as a CONstant in the object containing the DAT:




CON

exported_constant = (@symbol - @asm_start) >> 2

...

DAT

org 0
asm_start ...
...
symbol ...




The compiler flagged symbol in the CON, saying that it was undefined. So, thinking it may have been a first-pass issue, I moved the CON section after the DAT section. 'Same problem.

I'm stumped. There has to be a way to do this. If not, there needs to be.

-Phil

CardboardGuru
01-16-2008, 04:21 PM
Hi Phil,

You do it with a method.




PUB SymbolAdress
return @symbol


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com (http://propeller.wikispaces.com)
Play Defender - Propeller version of the classic game (http://forums.parallax.com/showthread.php?p=685888)
Prop Room Robotics - my web store for Roomba spare parts (http://www.proproomrobotics.co.uk) in the UK

Post Edited (CardboardGuru) : 1/16/2008 8:29:01 AM GMT

stevenmess2004
01-16-2008, 04:24 PM
Can you use the '@@' operator ?

Steven

CardboardGuru
01-16-2008, 04:34 PM
stevenmess2004 said...
Can you use the '@@' operator ?


Not for a constant. That's run time only. Basically the issue is that PropTool compiles each object seperately, with all constant addresses relative to the position of the object. At run time the compiler can use @@ to add in the object start address to make absolute addresses, but at compile time, PropTool doesn't know what address the object will be loaded at.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com (http://propeller.wikispaces.com)
Play Defender - Propeller version of the classic game (http://forums.parallax.com/showthread.php?p=685888)
Prop Room Robotics - my web store for Roomba spare parts (http://www.proproomrobotics.co.uk) in the UK

Phil Pilgrim (PhiPi)
01-16-2008, 04:45 PM
A method call will be too late. I need the symbol definitions (addresses) at compile time to insert into an LMM assembly program. The LMM program is defined in one object, but run by a different, virtual machine object. There are addresses in the virtual machine that the LMM program must have access to.

-Phil

deSilva
01-16-2008, 04:50 PM
No Phil, this does not work, and will of not work. I have written lots of posts abut this matter ("the constant context", the different constant contexts, etc.... I try to find the links... thought is was all obvious and well know...
@ can be used only in the DAT-constant context. And it does not provide the address, but a relative byte number wrt the object...

Edit: eg at the end of this: http://forums.parallax.com/showthread.php?p=670831

Post Edited (deSilva) : 1/16/2008 8:59:32 AM GMT

Phil Pilgrim (PhiPi)
01-16-2008, 04:56 PM
deSilva,

I don't need the absolute runtime address and well understand why I can't have it at compile time if I did need it. An object-relative address will do, as will the assembly address relative to the org, both of which are known at compile time.

-Phil

deSilva
01-16-2008, 05:08 PM
A @dat is known when ready for codegeneration, there seem to be different compiler phases, and also useful locks, i.e. the compiler understands complex situations as:


DAT
x long 0
z long 0[@y-@x]
y long 0



I THINK the sequence is:
- evaluate SIMPLE constant expressions
- evaluate constant expressions with @dat, to allow computing storage space using evaluated constants..

The basis problem however is, that you will never succeed in statically exporting those second kind of constants

Phil Pilgrim (PhiPi)
01-16-2008, 05:27 PM
The alternative is both unpalatible and rife with potential errors: i.e. create a list of constants by hand that would have to be updated each time the VM code is modified. Ugh!

-Phil

CardboardGuru
01-16-2008, 08:52 PM
Phil,

Why use PropTool at all? There are several alternative assemblers out there, and if they don't do what you need, you could modify one.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com (http://propeller.wikispaces.com)
Play Defender - Propeller version of the classic game (http://forums.parallax.com/showthread.php?p=685888)
Prop Room Robotics - my web store for Roomba spare parts (http://www.proproomrobotics.co.uk) in the UK

hippy
01-16-2008, 09:16 PM
Oddly enough I have a similar issue in a parallel but slightly different project.

If this is to be able to create instructions for calls into the LMM kernel, the solution proposed for traditional LMM was a well-defined jump vector at the start of cog. The problem there is that every LMM call becomes a jump-to-a-jump and unnecessary execution time and cog space is used up.

One improvement would be to scan the LMM Code and look for calls into the LMM kernel ( avoiding any constants which look like calls ) and fixup those using the jump data in the table but that is a lot of extra work and there are a number of issues with that to overcome. It's a lot of complexity for what should be a simple problem.

My conclusion is that the ideal way of doing this is to have the LMM Compiler also generate the LMM kernel, then it knows what cog addresses are used, or it is that 'prone to error' data tabe which has to be manually updated whenever the LMM kernel changes - "Ugh" indeed, although it would be much easier if the PropTool generated some listing file.

Phil Pilgrim (PhiPi)
01-17-2008, 12:06 AM
hippy said...
"Ugh" indeed, although it would be much easier if the PropTool generated some listing file.

My sentiments exactly. Just a symbol table listing would help. This is the first assembler I've ever used that provides neither.

Oh, well. I'm determined to put the kernel code in its own object, if I have to count the lines to each label by hand!

-Phil

Addendum: The light just went off, after I reread "jump vector" in your post. That's it! If you make indirect jumps via the jump vector, it doesn't cost anything, timewise. I've been thinking direct jumps all this time. (I'd still like a listing file, though, and the ability to export DAT symbols.)

hippy
01-17-2008, 01:16 AM
Bingo - "jmp vectorAdr" not "jmp #vectorAdr" !

Zero time cost. Well done again.

Phil Pilgrim (PhiPi)
01-17-2008, 03:05 AM
The jump vector has had an additional side-benefit. Since it's possible to get the same result with a direct jump as with an indirect jump (albeit one instruction slower), one can encode an additional bit of info in the "immediate" field of the kernel call. I may use this to indicate which half of my internal jump table long contains the word address of the jmp (i.e. the lesser-than-least-significant bit of the table address). This will eliminate separate routines for "jmp_lo" and "jmp_hi".

-Phil

Phil Pilgrim (PhiPi)
01-17-2008, 03:36 AM
An additional note: The public registers (e.g. _pc) have to go in the "jump" vector as well, just so they have a known address. I was using res; now I have to use long. It would still be better to be able to export DAT symbols directly, so as to avoid this rigamarole.

-Phil