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 :)

    Melbourne, Australia
  • I mostly give orgh addresses because it makes debugging easier ;)
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • 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.
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • 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: 7,522
    edited 2019-08-09 - 12:55:29
    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.
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • Maybe, as someone suggested, "ORGH >address" could be used.
  • ersmithersmith Posts: 3,240
    edited 2019-08-09 - 13:13:19
    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.
  • +$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.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • FILLTO $400

    ZEROFILL $400

    PADZERO $400

    PAD $400, 0

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

  • 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).
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • 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: 15,235
    edited 2019-08-09 - 19:38:32
    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
    

    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • 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.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • 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.
  • 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.
  • I'd prefer the ORG naming, how about ORGX $xxxx

    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • Cluso99Cluso99 Posts: 15,235
    edited 2019-08-10 - 03:32:18
    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 :)
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • 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 >=.
  • 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.

    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • 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.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • 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?
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • evanhevanh Posts: 7,522
    edited 2019-08-10 - 21:07:17
    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.

    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • 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
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • ORGH_MIN
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • I also like ORGX
    Prop Info and Apps: http://www.rayslogic.com/
  • ORGHF would be a corollary to ORGF, which fills to some cog address.
  • Guess I forgot about ORGF... This new thing is a lot like that...

    I'm OK with ORGHF or ORGFH, makes sense...
    Prop Info and Apps: http://www.rayslogic.com/
  • 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.