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.
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.
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.
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...
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.
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.
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.
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.
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.
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?
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.
Comments
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.
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.
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 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.
ZEROFILL $400
PADZERO $400
PAD $400, 0
I kind of like PAD the best. With the optional value.
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 $400But I would expect an error if hub is >$400.Likewise you can do... This errors if hub is >$400.
What has been suggested is...
$ 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 >=$400That looks good to me.
Maybe Eric should tell us whats easier
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.
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?
EDIT: There's already ORG and ORGF for cog handling. I can't see what else is needed there.
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.
Mike
I'm OK with ORGHF or ORGFH, makes sense...
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.