Shop OBEX P1 Docs P2 Docs Learn Events
P2 JMP/CALL addresses to COG/LUT/HUB - Page 2 — Parallax Forums

P2 JMP/CALL addresses to COG/LUT/HUB

2

Comments

  • cgracey wrote: »
    But I often switch between ORG and ORGH sections without addresses, so that they stack up.
    Me too :)

  • Cluso99Cluso99 Posts: 18,066
    I mostly give orgh addresses because it makes debugging easier ;)
  • evanhevanh Posts: 15,126
    Yes, same, absolutely. Thing is, that really all occurs above $400 now anyway.

    Other than the initial cog0 code, there often isn't anything placed below $400 right now. Why not just make this a default mechanism.
  • cgraceycgracey Posts: 14,133
    evanh wrote: »
    Yes, same, absolutely. Thing is, that really all occurs above $400 now anyway.

    Other than the initial cog0 code, there often isn't anything placed below $400 right now. Why not just make this a default mechanism.

    I pack tables and data into that space. To just fill it with $00's is kind of wasteful.
  • evanhevanh Posts: 15,126
    edited 2019-08-09 12:55
    It doesn't have to be empty, just not auto packed is all. It's not like it's very tidy being pushed around by the cog0 init code while capped by ORGH $400.

    And if the cog0 init code is not there then you've got a clean 1 kB to use.

    EDIT: If changed, with the "ORGH" default packing starting from $400, any data placed below $400 and extending above will still naturally be packed at its end.
  • cgraceycgracey Posts: 14,133
    Maybe, as someone suggested, "ORGH >address" could be used.
  • ersmithersmith Posts: 5,900
    edited 2019-08-09 13:13
    cgracey wrote: »
    ersmith wrote: »
    One idea that occurred to me is that having a way to force ORGH to be at least some value would be useful, e.g. perhaps we could write:
        orgh   >$400
    
    to say that the current hub address must be at least $400; if it is less than that to pad with 0s until $400 is reached, otherwise to just go with the current hub address.

    This should be easy to add to fastspin, but I'm not sure if this is the best syntax. We could also create a new "orghmin" directive instead, but that seems a bit ugly.

    @cgracey, do you think adding something like this to PNut is both desirable and relatively easy to accomplish?

    The problem is that ORGH gets used for data, as well as hub-exec code. Any label should reflect the contextual address. I think the programmer just has to know that he can't jump to hub-exec code below $400. He might want to have some snippets of code below $400, though, that get moved at runtime to somewhere else for execution. So, I don't think it would be good to change the rules about ORGH.

    Sorry, I guess I didn't explain myself well. I don't want to change any of the existing ORGH rules. I just want to add a new directive that acts like the current "ORGH N" if the hub counter is less than N, but otherwise acts like plain "ORGH". In other words, it adds padding to get to address N if necessary, but if we're already past address N there's no error and it just continues on its way. (Unless I'm mistaken the current "ORGH N" gives an error if the hub address is greater than N: which in fact is good, it's what we normally want, but in this particular case we don't care about getting to exactly address $400, we just want to make sure the current hub address is at least $400).

    We could call this "ORGH_MIN N". Or, we could do it by adding some decoration to the parameter to ORGH, like putting a + or a > sign in front of the address to say that we want it to be at least this much, but more is OK.

    It's a minor point, but it is useful in this specific case.
  • Cluso99Cluso99 Posts: 18,066
    +$400 looks like $+$400 so it could be confusing
    >$400 would need to be >$3FF or >=$400
    I prefer >=$400 over >$3FF

    Of course, it’s just the extra “>=“ operation as the $400 should be any valid address.

    If it’s easy to do then it would be useful.

    BTW I’ve used something like
    long 0[$400-$]
    to fill to a specific address.
  • FILLTO $400

    ZEROFILL $400

    PADZERO $400

    PAD $400, 0

    I kind of like PAD the best. With the optional value.

  • Cluso99Cluso99 Posts: 18,066
    whicker wrote: »
    FILLTO $400

    ZEROFILL $400

    PADZERO $400

    PAD $400, 0

    I kind of like PAD the best. With the optional value.
    No.

    Pad with zeros is actually automatic now.
    If anything, its just an operator to go with the value to an orgh (and possibly useful for org too).
  • Cluso99 wrote: »
    No.

    Pad with zeros is actually automatic now.
    If anything, its just an operator to go with the value to an orgh (and possibly useful for org too).

    So is the issue of having the assembler or preprocessor not able to do a limit minimum style function?
    If the value is less than 10, set it to 10 style function?


    So $ alone is the current address.
    Is there an existing operator with syntax to then force this value to at least $400, and feed that to the ORGH?
  • How about adding the keyword HUBX to signal the assembler that the following code must be in the hubexec region? It will work just like ORGH if the current hub address is greater than $3FF, or like ORGH $400 if the current address is less than $400.
  • Cluso99Cluso99 Posts: 18,066
    edited 2019-08-09 19:38
    whicker wrote: »
    Cluso99 wrote: »
    No.

    Pad with zeros is actually automatic now.
    If anything, its just an operator to go with the value to an orgh (and possibly useful for org too).

    So is the issue of having the assembler or preprocessor not able to do a limit minimum style function?
    If the value is less than 10, set it to 10 style function?


    So $ alone is the current address.
    Is there an existing operator with syntax to then force this value to at least $400, and feed that to the ORGH?

    Currently you can do...
            orgh                    ‘  force hub
            byte    0[$400-$]               ‘ fill to hub $400
    
    But I would expect an error if hub is >$400.

    Likewise you can do...
            orgh    $400                    ‘ fill to hub $400
    
    This errors if hub is >$400.

    What has been suggested is...
            orgh    >=$400                  ‘ fill to hub $400, ok if above $400. 
    

    $ means the current address.

    And yes, what was suggested is a minimu operator.

    And, if it is going to be implemented, might as well make it generic so we could use say...
            org     >=$80
    and
            orgh    >=$400
    

  • Cluso99Cluso99 Posts: 18,066
    Dave Hein wrote: »
    How about adding the keyword HUBX to signal the assembler that the following code must be in the hubexec region? It will work just like ORGH if the current hub address is greater than $3FF, or like ORGH $400 if the current address is less than $400.
    The orgh >=$xxxx would be a more flexible approach.
  • OK, how about HUBX $xxxx. If $xxxx isn't specified it defaults to $400. That looks cleaner to me, and the assembler doesn't need to do special handling for the >= operator with the ORGH directive.
  • cgraceycgracey Posts: 14,133
    Dave Hein wrote: »
    OK, how about HUBX $xxxx. If $xxxx isn't specified it defaults to $400. That looks cleaner to me, and the assembler doesn't need to do special handling for the >= operator with the ORGH directive.

    That looks good to me.
  • evanhevanh Posts: 15,126
    I'd prefer the ORG naming, how about ORGX $xxxx

  • Cluso99Cluso99 Posts: 18,066
    edited 2019-08-10 03:32
    The reason i prefer “>=“ is that it can be used in any org or orgh and with any address. This could be more useful in some cases where yo might want an address to be >= a different value. It also caters for possible future variants of P2 where just maybe we could have a larger lut.

    Maybe Eric should tell us whats easier :)
  • I can tell you that for p2asm it would be easier to implement a unique keyword versus special handling for the >= operator. It doesn't matter much what the names of the keywords are. I like HUBX and COGX, but any other names would be fine. If you guys want CHARLIE and GEORGE that would be OK with me, but please don't make me implement ORGH >=.
  • evanhevanh Posts: 15,126
    What would a cog space version do? I'm not sure it would even have meaning since each cog section has to be copied from hubRAM to cogRAM/LUT. Packing only has meaning in hub space, afaik.

  • Cluso99Cluso99 Posts: 18,066
    evanh wrote: »
    What would a cog space version do? I'm not sure it would even have meaning since each cog section has to be copied from hubRAM to cogRAM/LUT. Packing only has meaning in hub space, afaik.
    Currently changing org (ie cog) just changes the cog address. No fill takes place.

    Changing orgh fills/pads from the current address to the new address in hub space.

    A COG implementation would just shift up the cog address if necessary, without padding.

    A HUB implementation would just shift up the hub address if necessary, and would pad with zeros. I presume cog address would not change.
  • Cluso99Cluso99 Posts: 18,066
    Dave Hein wrote: »
    I can tell you that for p2asm it would be easier to implement a unique keyword versus special handling for the >= operator. It doesn't matter much what the names of the keywords are. I like HUBX and COGX, but any other names would be fine. If you guys want CHARLIE and GEORGE that would be OK with me, but please don't make me implement ORGH >=.

    Wouldn't you just look for the address as per usual, and if ">=" was encountered you would set a flag such that when the address was obtained you would then compare the current address with the new address, and if the new is lower, ignore the address?
  • evanhevanh Posts: 15,126
    edited 2019-08-10 21:07
    There's certainly no value in a cog version that shifts to an out of bounds address.

    EDIT: There's already ORG and ORGF for cog handling. I can't see what else is needed there.

  • It sounds like a new directive is the easiest way to go in general (for fastspin it doesn't make much difference either way, but the fastspin parser uses yacc which makes changes easier than faster more custom parsers). I agree with Evan that there really wouldn't be much call for a COG version to ensure a minimum address, and maximum address is already handled with FIT.

    I like "ORGH_MIN" or "ORGH_ATLEAST" myself; it's more typing but very clear what it means. This isn't a directive that people will have to type much, it's generally at most once per program. "ORGH" or "HUBX" would be fine too.

  • ORGM

    Mike
  • Cluso99Cluso99 Posts: 18,066
    ORGH_MIN
  • RaymanRayman Posts: 13,805
    I also like ORGX
  • cgraceycgracey Posts: 14,133
    ORGHF would be a corollary to ORGF, which fills to some cog address.
  • RaymanRayman Posts: 13,805
    Guess I forgot about ORGF... This new thing is a lot like that...

    I'm OK with ORGHF or ORGFH, makes sense...
  • cgracey wrote: »
    ORGHF would be a corollary to ORGF, which fills to some cog address.

    Doesn't the existing "ORGH N" already fill to address N, giving an error if we're already past N?

    The new proposed directive fills to N only if necessary, and never gives an error.
Sign In or Register to comment.