Shop OBEX P1 Docs P2 Docs Learn Events
Exporting DAT symbols. How? — Parallax Forums

Exporting DAT symbols. How?

Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
edited 2008-01-16 19:36 in Propeller 1
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

Comments

  • CardboardGuruCardboardGuru Posts: 443
    edited 2008-01-16 08:21
    Hi Phil,

    You do it with a method.

    PUB SymbolAdress
     return @symbol

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Help to build the Propeller wiki - propeller.wikispaces.com
    Play Defender - Propeller version of the classic game
    Prop Room Robotics - my web store for Roomba spare parts in the UK

    Post Edited (CardboardGuru) : 1/16/2008 8:29:01 AM GMT
  • stevenmess2004stevenmess2004 Posts: 1,102
    edited 2008-01-16 08:24
    Can you use the '@@' operator ?

    Steven
  • CardboardGuruCardboardGuru Posts: 443
    edited 2008-01-16 08:34
    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
    Play Defender - Propeller version of the classic game
    Prop Room Robotics - my web store for Roomba spare parts in the UK
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2008-01-16 08:45
    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
  • deSilvadeSilva Posts: 2,967
    edited 2008-01-16 08:50
    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)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2008-01-16 08:56
    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
  • deSilvadeSilva Posts: 2,967
    edited 2008-01-16 09:08
    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[noparse][[/noparse]@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)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2008-01-16 09:27
    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
  • CardboardGuruCardboardGuru Posts: 443
    edited 2008-01-16 12:52
    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
    Play Defender - Propeller version of the classic game
    Prop Room Robotics - my web store for Roomba spare parts in the UK
  • hippyhippy Posts: 1,981
    edited 2008-01-16 13:16
    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)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2008-01-16 16:06
    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.)
  • hippyhippy Posts: 1,981
    edited 2008-01-16 17:16
    Bingo - "jmp vectorAdr" not "jmp #vectorAdr" !

    Zero time cost. Well done again.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2008-01-16 19:05
    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)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2008-01-16 19:36
    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
Sign In or Register to comment.