Shop Learn P1 Docs P2 Docs
Homespun Spin compiler 0.31: Now open source - Page 3 — Parallax Forums

Homespun Spin compiler 0.31: Now open source

1356712

Comments

  • BradCBradC Posts: 2,601
    edited 2008-09-11 14:15
    ooo just a thought..
    what about this in the top object?

    DAT
    long 0[noparse][[/noparse]obj1#_space + obj2#_space + obj3#_space]

    ??

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • jazzedjazzed Posts: 11,803
    edited 2008-09-11 14:52
    BradC said...

    Don't forget the variable sorting is also done to guarantee alignment.
    Uuugh! This behaviour takes away the concept of data structure from the VAR section but will still work to a point in the DAT section. The first time I realized this was the way it worked, I was so pissed I wanted to throw all my Propeller stuff·in the trash. Further "rationalization" of this deficiency is not necessary [noparse]:)[/noparse]· Thank·God for sedatives.



    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    --Steve
  • hippyhippy Posts: 1,981
    edited 2008-09-11 17:39
    BradC said...
    ooo just a thought..
    what about this in the top object?

    DAT
    long 0[noparse][[/noparse]obj1#_space + obj2#_space + obj3#_space]

    ??

    Yes that works but it requires the user to add it to the top object. It's not that there aren't
    workrounds it's just that they aren't convenient for an end-user.

    A particular case where this is important is with "zero footprint debugging" which requires the
    debugging object to have read-write access to a few longs < $200 in hub memory. There are
    a few ways such space can be reserved ( DAT, OBJ object[noparse][[/noparse]N], dummy PRI/PUB ) but it would
    be nice if the user didn't have to do anything other than include the debugging object and just
    use it.

    OBJ
      debug[noparse][[/noparse] 4 ] : "TheDebugger"
    
    


    I quite like that idea. The end-user simply uses debug.SetBreakpoint(...) etc as if there were
    only one debugger, they only have to define it correctly. Best yet, the debugger can check
    the object link table it was called through and check the definition is right ( there will be four
    consecutive links to same object ) and then re-use the longs which aren't actually used by
    the end-user.

    It only works if the debugger object is included in the top-most object but I can live with that.
    It doesn't have to be used there, just defined there. The link table searching can also check
    for that as all references will point to the same debugger code.

    I'm sure this could also be used for debugging multiple Cogs in parallel but I've not even gone
    anywhere near doing that so far.

    When I next have the PropTool fired-up I'll try implementing that. Thanks.
  • mparkmpark Posts: 1,258
    edited 2008-09-11 23:52
    Richard (ImageCraft) -- Thanks, that's basically what I am doing.

    Stevenmess2004 -- I think I can add a flag to disable VAR sorting.

    Hippy -- Do you know why the Spin interpreter cares that the top object is at $0010? I mean, isn't the important thing the address to start executing? Instead of a dummy PUB/PRI, what do you think of a dummy top object?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Michael Park

    PS, BTW, and FYI:
    To search the forum, use search.parallax.com (do not use the Search button).
    Check out the Propeller Wiki: propeller.wikispaces.com/
  • Cluso99Cluso99 Posts: 18,063
    edited 2008-09-12 01:12
    @Hippy: I believe multiple debugging is simple - the bigger problem is having enough cogs and seperate serial ports (fdx cogs and pins) for the debugger.
    I have 3 cogs running the Interpreter (Rom, Ram (basically Chip's) and Ram (mine = Cluso)) in cogs 5, 6, 7.
    Each of the Ram Interpreters are in seperate objects and pass their start address in an Init routine and have a Start routine which receives the start address for the Chip and Cluso.
    PUB Main( running ) 
      if not running
        running := true
        atRamInterpreter   := RamInterpreter.GetPasmAddr            'get the Pasm start address of the interpreter
        atClusoInterpreter := ClusoInterpreter.GetPasmAddr
        RamInterpreter.Init(atRamInterpreter,atClusoInterpreter)    'initialise the interpreter's addresses
        ClusoInterpreter.Init(atRamInterpreter,atClusoInterpreter)
        CogInit( 0, atRamInterpreter, $0004 )                       'restart cog 0 with the working RamInterpreter
        repeat                                                      'expect a delay while cog 0 reboots this code!!
    '&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;
    ' ALTERNATIVES:
      LaunchDebug                                           'launch the debugger
    '  LaunchCompare                                         'launch the compare & time function
      repeat                                                'never gets here
      
    '&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;
    PRI LaunchDebug                                         'launch the debugger
      StartSerial (true)                                    'display options (with commandset)
    ' StartDebugger(@PasmCode)                              'debug test code below
      InitDebugger(atClusoInterpreter)                      'debug ClusoInterpreter
      CogInit( 7, SmallTest  , @priStack7 )  '<---- The ClusoInterpreter (being tested)
      WaitCnt( CLKFREQ / 10 + CNT )                         '?mS
      StartDebugging                                        'and start debugging
      repeat                                                '<=== stop here
    '&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;&#61610;&#61609;
    
    

    PUB GetPasmAddr
      Result := @ClusoInterpreter
    PUB Init (Interpreter1_addr, Interpreter2_addr)        'pass @RamInterpreter1 and @RamInterpreter2 start addresses
      k_0000_XXX1 := Interpreter1_addr ^ $0000_F004         'setup hub address of RamInterpreter #1 before loading
      k_0000_XXX2 := Interpreter2_addr ^ $0000_F004         'setup hub address of RamInterpreter #2 before loading
      vector_base := @vector_table                          'copy hub address of vector_table before loading
      
    DAT                     
    '  &#9484;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9488;
    '  &#9474;    THIS IS THE TEST VERSION of the ClusoRamInterpreter                   &#9474;
    '  &#9492;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9472;&#9496;
                            org     0
    ClusoInterpreter
    
    


    Currently the code being debugged and the PASM/Spin debugger (the same debugger with command options because it doesn't care if it's debugging spin or pasm) which resides in the top object. At this time, the code being debugged also resides in the top object. I need to seperate these as it has caused a few bugs with PUB and PRI misdecarations.

    Don't forget, if you are running multiple versions of the same test object, the hub ram of the object (first 4 longs) needs to be replaced after the code is loaded into the cog. Otherwise all subsequent loads will be incorrect. The same applies if the debugger has a reboot option which reloads the cog under test.
  • hippyhippy Posts: 1,981
    edited 2008-09-12 02:23
    mpark said...
    Hippy -- Do you know why the Spin interpreter cares that the top object is at $0010? I mean, isn't the important thing the address to start executing? Instead of a dummy PUB/PRI, what do you think of a dummy top object?

    I'm not sure why it's that way but there's a check in the ROM bootloader code to ensure that
    word[noparse][[/noparse]$0006] is always $0010. I guess it's just an extra safety check that the Eeprom image
    is valid before executing its code. From Chip's ROM Bootloader source ...

    ' Launch program in ram
    '
    launch            rdword    address,#$0004+2    'if pbase address invalid, shutdown
                  cmp    address,#$0010    wz
        if_nz        jmp    #shutdown
    
    
    
  • mparkmpark Posts: 1,258
    edited 2008-09-12 15:39
    Minor update today. See first post.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Michael Park

    PS, BTW, and FYI:
    To search the forum, use search.parallax.com (do not use the Search button).
    Check out the Propeller Wiki: propeller.wikispaces.com/
  • mparkmpark Posts: 1,258
    edited 2008-09-16 03:44
    Another update. Version 0.15 fixes a bug and adds a warning (trying to catch when you define data after a RES directive.

    This version also has my second attempt at hippy's _SPACE request. It totals up all the CON _SPACE = xxx in all the objects and reserves that many bytes starting at $0010. Actually it builds a dummy top object there, but the effect should be the same. Give it a shot, let me know how it goes.

    If this _SPACE thing ever works out, will that obviate the need for the @@@ operator requested by Cluso99?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Michael Park

    PS, BTW, and FYI:
    To search the forum, use search.parallax.com (do not use the Search button).
    Check out the Propeller Wiki: propeller.wikispaces.com/
  • BradCBradC Posts: 2,601
    edited 2008-09-16 04:00
    I was thinking about the _SPACE thing last night.
    If several sub objects all declare _SPACE and it gets reserved for them.. how do they know not to place their stuff at the start of it and trample over the data placed there by the other objects?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • Cluso99Cluso99 Posts: 18,063
    edited 2008-09-16 06:05
    @mpark: No, the offset still applies. The @@@ or whatever is requesting the compiler to provide the actual address in hub memory, not an offset address.

    What code are you using to test the compiler - maybe you might like to share it so I can try it in debuging the Interpreter?

    @BradC: The user will have to worry about that. Hippy and I just need a way to guarantee to reserve space in hub below $200 for the debugger. I am sure there will be other usesas well.
  • BradCBradC Posts: 2,601
    edited 2008-09-16 06:56
    Cluso99 said...

    @BradC: The user will have to worry about that. Hippy and I just need a way to guarantee to reserve space in hub below $200 for the debugger. I am sure there will be other usesas well.

    If the user has to worry about it, then why is it an issue to just have ...

    DAT
    long 0[noparse][[/noparse]debugger#_SPACE]

    ... at the start of the top object?

    The user already has to declare the object and start it in any case.

    I'm just trying to figure out why we need to extend the compiler when we can already guarantee that space with a simple addition to the top object (on top of the already required object declaration and object start) - Particularly as doing it this way retains compatibility with the Parallax Compiler and all those that are likely to keep using the existing PropTool?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • Ron SutcliffeRon Sutcliffe Posts: 420
    edited 2008-09-16 07:13
    @cluso99
    Cluso99·said...
    Hippy and I just need a way to guarantee to reserve space in hub below $200 for the debugger.
    Hmm!......... not sure sure its a good idea to presume you can speak for others. Albeit = true. No offence intended.

    Regards
    Ron

    ··
  • hippyhippy Posts: 1,981
    edited 2008-09-16 08:04
    BradC said...
    I'm just trying to figure out why we need to extend the compiler when we can already guarantee that space with a simple addition to the top object (on top of the already required object declaration and object start) - Particularly as doing it this way retains compatibility with the Parallax Compiler and all those that are likely to keep using the existing PropTool?

    There's no "need", but it would make things easier. The same lack of need could be levied at any
    proposed enhancement.

    Breaking compatibility with PropTool isn't really a problem and it will get broken further still unless
    homespun ( and others ) will be artificially constrained to handling only source which the PropTool
    can also currently handle.

    Hopefully any methods of extending our own tools will be elegant enough that Parallax adopts the
    same when they have resources to devote to their own tool improvements. I see the best future
    for home-grown tools not as competition for each others but as alternatives. At the moment the
    ball's in our court for adding enhancements to the Spin language, but I hope they'll all offer the
    same capabilities eventually unless a product is designed for a specific niche.
  • hippyhippy Posts: 1,981
    edited 2008-09-16 08:09
    BradC said...
    I was thinking about the _SPACE thing last night.
    If several sub objects all declare _SPACE and it gets reserved for them.. how do they know not to place their stuff at the start of it and trample over the data placed there by the other objects?

    That's a good question and a problem I recognised when I suggested the idea. Perhaps the best
    solution is to have _SPACE and @_SPACE as compiler constants which returns the value and the
    address of where that space starts for each object ...

    CON
      _SPACE = 256
    
    PUB Main | i
      repeat i from 0 to _SPACE-1
        byte [noparse][[/noparse] @_SPACE + i ] := 0
    
    
    
  • BradCBradC Posts: 2,601
    edited 2008-09-16 08:14
    hippy said...

    There's no "need", but it would make things easier. The same lack of need could be levied at any
    proposed enhancement.

    Breaking compatibility with PropTool isn't really a problem and it will get broken further still unless
    homespun ( and others ) will be artificially constrained to handling only source which the PropTool
    can also currently handle.

    Hopefully any methods of extending our own tools will be elegant enough that Parallax adopts the
    same when they have resources to devote to their own tool improvements. I see the best future
    for home-grown tools not as competition for each others but as alternatives. At the moment the
    ball's in our court for adding enhancements to the Spin language, but I hope they'll all offer the
    same capabilities eventually unless a product is designed for a specific niche.

    All fair points.
    Question.
    A) How does the object using the reserved _SPACE know where it starts?
    (looks like our posts crossed paths)

    B) What if the top object has enough methods and objects to push the _SPACE allocated past $1FF?
    (admittedly a far reach, but possible in theory)

    @mpark - How have you implemented the _SPACE as a dummy object?
    I was thinking if it occupied method 1 in the object table (which is _always_ located in the same position) then it would be a cakewalk to determine where the allocated space actually begins.

    .. Just playing devils advocate ..

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • SapiehaSapieha Posts: 2,964
    edited 2008-09-16 08:18
    Hi All.

    In My opinion it would be more practical to have.



    ORGSPIN XXX Spin code start (After yous _Space)
    ORGTPASM XXX Transparent pasm code
    ORGVAR XXX
    ORGSTACK XXX

    That construction not conflict with PropelerTools and have more reliable Reading.
    Samt compiler can test and warn if it is conflict betwen 2 in several sub objects

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Nothing is impossible, there are only different degrees of difficulty.
    For every stuipid question there is atleast one inteligent answer
    If you dont ask you wont know

    Sapieha
  • BradCBradC Posts: 2,601
    edited 2008-09-16 08:27
    hippy said...

    That's a good question and a problem I recognised when I suggested the idea. Perhaps the best
    solution is to have _SPACE and @_SPACE as compiler constants which returns the value and the
    address of where that space starts for each object ...

    CON
      _SPACE = 256
    
    PUB Main | i
      repeat i from 0 to _SPACE-1
        byte [noparse][[/noparse] @_SPACE + i ] := 0
    
    
    


    Hrm.. I don't know how mpark does his object compilation, but I compile all my objects separately, then binary link them in a 2 pass process (write out the bytecode, then adjust the object pointers in the method tables). Both this, and the @@@ idea tend to pose problems as you don't know the value of those addresses at compile time. (A problem generally inherent in having relocatable objects I'd guess). I'd have to think pretty hard about how to include constants in the code in such a way as to be able to adjust them at link time.

    I guess I could place 5 $3C opcodes in a row into the binary (which should _never_ otherwise occur) and then replace them with a 4 byte constant at link time. Wasteful of bytecode, but only 2 bytes I guess.

    The problem is you are never going to know the addresses at compile time, and you are never going to know the size of a compiled object until you have compiled it.

    As to how you would use @@@ in a dat block..

    Am I thinking to narrowly? Is there an easy way to do it ?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • hippyhippy Posts: 1,981
    edited 2008-09-16 09:07
    I think it would be possible to determine @_SPACE at compile time. Keep track of all _SPACE gone so far as each object/sub-object is compiled. As long as the top-object is compiled as a pre-pass it will be known how big the method link table will be. At worse a duplicate object turned into one will have twice as much _SPACE allocated as it needs. I'd say an object with _SPACE shouldn't be considered a duplicate anyway.

    Handling @@@ would be a bigger problem.

    As to _SPACE going beyond $1FF, I'd not worry about that but allow it. It should be up to the object using it to check @_SPACE < $200 if required. The situation is no worse than a Cog being launched not starting. I wouldn't be adverse to it being a compile error.

    The alternative to how it's done now is to compile to an intermediate form ( such as that my bytecode disassembler produces ) at which point it's a single source in traditional 'no object' form and then assemble that. No linking involved as all labels and references will be in the single file.

    This single main file could have "#include objectFile.xxx" so each 'compiled object file' can be compared for duplicates and only included once.

    If I were writing a Spin compiler I'd do it this way. An advantage is that it's easy to add optimisation stages transparently, for individual objectfile.xxx and the 'everythning included' programfile.xxx - That's why my disassembler produces code in the form it does as one day I hope to write an optimiser and a re-compiler, as well as making it easier for people to write other language compilers producing the intermediate code and not having to worry about assembling and linking the bytecode itself.

    All the advantages of late linking / fix-up without the compiler having to worry about keeping track of things.

    Something like this wouldn't be a problem to assemble ...

    _CLKFREQ LONG 80_000_000
    _CLKMODE BYTE XTAL1_PLL16x
    
    Checksum BYTE 0
    
    Header   WORD Obj_1
             WORD Pub_1_1
             WORD Stack
             WORD Var
    
    Obj_1    LINK Obj_2
             LINK Pub_1_1
             LINK Pub_1_2
             LINK Obj_2_1
    
    _SPACE_1 LONG 0[noparse][[/noparse]10]
    _SPACE_2 LONG 0[noparse][[/noparse]100]
    
    Pub_1_1  PUSH #_SPACE_1
             RET
    
    Pub_1_2  RET
    
    Obj_2    LINK Vars
             LINK Pub_2_1
    
    Pub_2_1  PUSH #_SPACE_2
             RET
    
    Var      ...
    
    Stack    ...
    
    
    

    Post Edited (hippy) : 9/16/2008 9:18:33 AM GMT
  • BradCBradC Posts: 2,601
    edited 2008-09-16 11:01
    hippy said...

    The alternative to how it's done now is to compile to an intermediate form ( such as that my bytecode disassembler produces ) at which point it's a single source in traditional 'no object' form and then assemble that. No linking involved as all labels and references will be in the single file.

    This single main file could have "#include objectFile.xxx" so each 'compiled object file' can be compared for duplicates and only included once.

    If I were writing a Spin compiler I'd do it this way. An advantage is that it's easy to add optimisation stages transparently, for individual objectfile.xxx and the 'everythning included' programfile.xxx - That's why my disassembler produces code in the form it does as one day I hope to write an optimiser and a re-compiler, as well as making it easier for people to write other language compilers producing the intermediate code and not having to worry about assembling and linking the bytecode itself.

    All the advantages of late linking / fix-up without the compiler having to worry about keeping track of things.

    Something like this wouldn't be a problem to assemble ...

    Hrm.. novel idea.
    I sort of do this already but only on a per method basis. I compile to a sort of intermediate code represented as a chain of tokens I can loop over to optimise addresses prior to final method assembly. Logically if I chained them all together I could simply assemble the entire object in one hit rather than on a method by method basis. Object chaining will require a bit of thought.. but it's certainly doable.

    Gotta think about that some more.. it would certainly make @_SPACE and @@@ in Spin code easy. Not sure I want to think about those constants in DAT though. The Assembler is a different kettle of fish. One could very easily use some spin glue to insert them into DAT prior to use though.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • hippyhippy Posts: 1,981
    edited 2008-09-16 12:07
    Yes, there is a challenge in keeping the code compatible with what Spin does no matter how nice it would be to do it as it should be. For the "long @hubLabel" in DAT that would have to be generated as "long @hubLabel-@objectBase" to keep the offsets the same.
  • mparkmpark Posts: 1,258
    edited 2008-09-16 15:17
    Implementing _SPACE as a dummy first method is what hippy suggested, but I've been trying to avoid thinking about bumping up method numbers (although now that I do think about it a little, it doesn't seem that bad). Mostly I thought a dummy top object would make it easy to figure out where the _SPACE space starts (always $0010) and would give people a little more of that precious <$200 memory.

    Unlike my first attempt at _SPACE, this time I at least tried running a program with non-zero _SPACE (and it worked!). But I didn't actually use the memory. I leave that to you kids with your newfangled debuggers and whatnot.

    I have the same problem as Brad as far as @@@ not knowing where it is.

    Sapieha, are you familiar Spin bytecode? Not just the opcodes, but the way objects are laid out in memory? It seems to me that your ORGXXX suggestion would be very difficult to implement. But maybe I just have to think about it some more.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Michael Park

    PS, BTW, and FYI:
    To search the forum, use search.parallax.com (do not use the Search button).
    Check out the Propeller Wiki: propeller.wikispaces.com/
  • hippyhippy Posts: 1,981
    edited 2008-09-16 15:54
    Sapieha's ORGXXX could work with my idea of a flat assembly language image file. It might need the file re-ordering to get things in ascending sequence but it could be done on-the-fly. I haven't considered the exact implementation details but it should just be a case of if an ORG is less than current location, error, if higher, add some padding.
  • Cluso99Cluso99 Posts: 18,063
    edited 2008-09-17 03:58
    This works for DAT (PASM)
    DAT
    :gaps                   long    $0[noparse][[/noparse]$1E5 - $]            'fill the gaps
    
    

    Could a similar version work for hub memory (flat)? (not sure where you would place it i.e. pub/pri,etc)
    ??? (con/var/pub/pri/dat) ???
    :gaps                   long    $0[noparse][[/noparse]HUB$6000 - HUB$]         'fill the gaps
    
    

    ·Uses HUB$ as current location. Just a thought.
  • BradCBradC Posts: 2,601
    edited 2008-09-17 05:05
    Ok, I need someone to explain to me the precise purpose of @@@ and where it would be used. I'm just not getting something.

    @@ gives you the hub address of a spin or DAT symbol at runtime.. why can't you just use a bit of spin setup code to poke that into a variable in DAT somewhere?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • Cluso99Cluso99 Posts: 18,063
    edited 2008-09-17 06:15
    @BradC: Here is a piece of PASM code that needs to know the physical hub address of a variable. However, only the object offset is available and it is necessary to add another offset to it to find the exact hub location.
    CON
    ' The following is the object offset needed to be added to [url=mailto:#@xxxx]#@xxxx[/url] in a DAT block of pasm instructions (compiler restriction)
      DB            = $10                                          '<=====
    DAT
                            org     0                      
    Pasm                    rdlong  Cog_var, [url=mailto:#DB+@Hub_var]#DB+@Hub_var[/url]   'get variable from hub (lower $200)
    .....
                            wrlong  Cog_var, [url=mailto:#DB+@Hub_var]#DB+@Hub_var[/url]   'put variable into hub (lower $200)
    .....
    Cog_var                 long    0-0                     'variable in cog
    .....
    Hub_var                 long    0-0                     'accessed directly in hub (not cog!!!)
    
    

    It would be cleaner to replace "[url=mailto:DB_@Hub_var]DB_@Hub_var[/url]" with "@@@Hub_var" (or whatever @@@ is replaced with).
  • mparkmpark Posts: 1,258
    edited 2008-09-17 07:09
    So with the current state of _SPACE, would the workaround be something like this?
    CON
      _SPACE = 4
      Hub_var_addr = $0010
    
    DAT
                            org     0                      
    Pasm                    rdlong  Cog_var, #Hub_var_addr   'get variable from hub (lower $200)
    .....
                            wrlong  Cog_var, #Hub_var_addr   'put variable into hub (lower $200)
    .....
    Cog_var                 long    0-0                     'variable in cog
    .....
    PUB blah
      long[noparse][[/noparse]Hub_var_addr] := 666 'use hub variable
     
    
    

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Michael Park

    PS, BTW, and FYI:
    To search the forum, use search.parallax.com (do not use the Search button).
    Check out the Propeller Wiki: propeller.wikispaces.com/
  • Cluso99Cluso99 Posts: 18,063
    edited 2008-09-17 09:49
    @mpark: I may have led you astray. It actually does not matter if the hub ram is in the lower $200 longs. The problem is the same.

    The requirement is for the assembler code to address hub ram. There is no mechanism for the assembler code to refer to a label defining hub memory. The current workarounds are as I indicated above, or to have the spin code modify the pasm code while still in hub ram before the cog is loaded. This is why many programs just use a piece of hub ram like $7FFC without reserving it.

    So this is not possible

    Var
    stack long[noparse][[/noparse]10]

    DAT
    long @stack
  • mparkmpark Posts: 1,258
    edited 2008-09-17 14:32
    Oh. I think I'm slowly starting to get it.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Michael Park

    PS, BTW, and FYI:
    To search the forum, use search.parallax.com (do not use the Search button).
    Check out the Propeller Wiki: propeller.wikispaces.com/
  • BradCBradC Posts: 2,601
    edited 2008-09-17 14:43
    Cluso99 said...
    or to have the spin code modify the pasm code while still in hub ram before the cog is loaded.

    What is the problem with doing it this way?
    At least you retain compatibility with the existing compiler!

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • Cluso99Cluso99 Posts: 18,063
    edited 2008-09-17 14:56
    @BradC: Because there are lots of times where you require this. It is known by the compiler, just not exposed. And to actually do it correctly (I mean not hardcoding offset to $0010) requires walking the object at runtime which is neither efficient nor intuitive. In my opinion, it is a compiler deficiency - others may not agree, but that's my opinion. The only reason for keeping it the way it is, is if there were separate linkers and relocatable objects, and we are way off from that.
Sign In or Register to comment.