Currently I think I prefer to stick with the proven @@@. I don't see any reason to have a command option to enable/disable it.
BTW Roy, do you have an option to post a warning when jmp label (rather than jmp #label) is used? Amazing how many errors I have caught with bst giving a warning - so easy to forget the #.
Another thing it wouldn't hurt to ask Chip is how he intends to handle @ in Spin II. It would be nice if the semantics for @ in Spin I and Spin II were the same.
Is the following desirable or useful? Particularly the mov line.
DAT
mov temp, @@@label
label long 0
temp res 1
BSTC compiles it, but if @@@label is more than 9 bits it gives an error. However, what it's going to do for that mov line is read the cog register that @@@label happens to index. I can't really think of any cases where you want to use @@@ as part of an operand for an instruction except maybe with the # (immediate operator) on a rdlong (and friends). Even then, that seems unsafe and fragile, because if your object gets included by some other object then your hub addresses will move up and likely be out of the first 9 bits worth of hub address space. and it'll give you a compile error.
Isn't this more what you'd want?
DAT
mov temp, label2
label long 0
label2 long @@@label
temp res 1
Also, issues with byte:
DAT
mov temp, label2
fill long 0[100]
label long 0
label2 byte @@@label
temp res 1
In this case BSTC compiles it, but the @@@label address is truncated to a byte. Thus it's not even the correct address. Even if you did happen to have it fit in a byte, how would you use it in there? It also has the same fragileness as mentioned above where your hub address moves out of range if you are not the top object, but worse because it still compiles.
Should I even allow you to use @@@ in operands? Should I allow it to be in a byte sized DATs? Seems like the only safe and useful ways to use it are in word and long DATs
label long 0
labell long @@@label
labelw word @@@label
Supporting those is pretty trivial, having to support S field, D field, and byte sized fixup locations makes things more complex for what I think is something that shouldn't really be used.
I would think that @@@label should work wherever @label works. So even though "mov temp, @@@label" might not make sense "mov temp, #@@@label" does make sense. It would also be good if @@@ works with byte variables. This would allow someone build a compact table of addresses that references DAT variables located in the first 256 bytes of memory.
mov temp,@label (sorry, 'still can't abide @@@) would mean , "Load temp from the cog address given by the hub address of label. 'Doesn't make much sense to do that, and it would rarely be used, IMO. But it's semantically sound so long as @label fits in nine bits.
Roy, don't forget, you've also got to take care of stuff like this:
addr long @label >> 8 + 6
IOW, the linking pass will have to perform the delayed expression evaluation.
Dave,
So I have to do the more complex thing of keeping track of what type of fixup it is, and then handle them all. You are okay with the BYTE variant just truncating the value (like in BSTC). so it's easy to have compiled code that is broken?
Phil,
Yikes! Supporting delayed expression evaluation is kind of a showstopper for me with the current code. I'll have to make it even possible to do late expression evaluation. This sucks.
Truncating for byte variables is fine with me, as long as a warning is printed for values greater than 255. It seems like you would have to do the more complex thing of keeping track of the fixup type if you support @@@ in the source field of an instruction. I don't think it makes sense to support @@@ for the destination field. Does BST support that?
EDIT: I tried "rdlong @@@temp1, temp2", and BST does compile it. Using @@@ in the destination field doesn't make much sense to me, but maybe there's a use for it.
In LMM code I load sometimes a pointer with an 18bit address like that:
mov ptr,#@@@Label & 511
movd ptr,#@@@Label >> 9
This is more efficient than the usual way with a helper subroutine, which loads the next long
So there are situations where #@@@ in a source field is useful.
... Supporting delayed expression evaluation is kind of a showstopper for me with the current code. ...
Perhaps you could pre-compile the expression to RPN form in the first pass, and stick a pointer to the RPN in the relocation table. During the linking pass, then, all that would have to be done is to crank out the result from the RPN.
'Same thing's gonna happen if someone types a := constant(@label + 4) in Spin, which should be legit. (OTOH, it may be impossible to know how many bytes to reserve for the Spin bytecodes ahead of time.)
Phil,
My understanding from others was that @@@ doesn't work in spin like you showed. They say it's only allowed in DAT sections. If it's allowed in spin expressions, then that's even more of a showstopper for me.
I think one problem in Spin (for @ or @@@) is that the bytecode interpreter uses variable-length fields, depending upon the magnitude of the argument which, in this case, can't be known ahead of time. I haven't studied it enough, though, to know whether you can just substitute the longest field and its operator, and let it go at that. As an alternative, one could insert a separate DAT section with long pseudo-ops to contain the results of the constant expressions, and emit a Spin bytecode to load from that location. Then you're just dealing with DAT sections for post-compile fixups.
In any event, if delayed expression evaluation seems to be an issue, I'd be inclined just to hold off on the @@@ stuff altogether for now until a more complete and unified approach to the issue presents itself. At least wait to see how Chip handles it in Spin II, so there's no disparity between the two versions.
Phil,
BSTC and Homespun already support @@@. People already rely on it. I've been asked to make it work in OpenSpin so that those who rely on it can switch to OpenSpin. As far as I understand, it does not work for spin pub/pri/var sections. You can use @@ & @ to get absolute addresses to hub memory in Spin land. It's only needed for DAT sections and PASM.
Also, what I meant by "showstopper" up there is more just in the context of my current changes to attempt implementing it. I need to back out those changes and rethink/restart the process with my new understanding of the problem.
... You can use @@ & @ to get absolute addresses to hub memory in Spin land. ...
Right. But you cant use them in constant expressions, since the absolute address is computed on the fly at run-time. My thought was that, if you did implement delayed expression evaluation, it would be nice to extend it to Spin as well.
I'm torn about accommodating those who have already taken their chances with an "off-brand" compiler*, at least until we see what Chip does with Spin II.
-Phil
*Addendum: Not that I wish to leave those who did so in the cold. It's just that OpenSpin is to become the official Spin compiler for the Prop I and that @@@ is a rather ugly hack scabbed onto those "other" compilers to meet an immediate need. I'd rather see a longer view taken with a more unified, complete, and elegant approach to the problem, rather than copying something that, in my view, falls short of those objectives. -P.
Comments
BTW Roy, do you have an option to post a warning when jmp label (rather than jmp #label) is used? Amazing how many errors I have caught with bst giving a warning - so easy to forget the #.
-Phil
Is the following desirable or useful? Particularly the mov line.
DAT mov temp, @@@label label long 0 temp res 1BSTC compiles it, but if @@@label is more than 9 bits it gives an error. However, what it's going to do for that mov line is read the cog register that @@@label happens to index. I can't really think of any cases where you want to use @@@ as part of an operand for an instruction except maybe with the # (immediate operator) on a rdlong (and friends). Even then, that seems unsafe and fragile, because if your object gets included by some other object then your hub addresses will move up and likely be out of the first 9 bits worth of hub address space. and it'll give you a compile error.
Isn't this more what you'd want?
DAT mov temp, label2 label long 0 label2 long @@@label temp res 1Also, issues with byte:
DAT mov temp, label2 fill long 0[100] label long 0 label2 byte @@@label temp res 1In this case BSTC compiles it, but the @@@label address is truncated to a byte. Thus it's not even the correct address. Even if you did happen to have it fit in a byte, how would you use it in there? It also has the same fragileness as mentioned above where your hub address moves out of range if you are not the top object, but worse because it still compiles.
Should I even allow you to use @@@ in operands? Should I allow it to be in a byte sized DATs? Seems like the only safe and useful ways to use it are in word and long DATs
Supporting those is pretty trivial, having to support S field, D field, and byte sized fixup locations makes things more complex for what I think is something that shouldn't really be used.
Roy, don't forget, you've also got to take care of stuff like this:
IOW, the linking pass will have to perform the delayed expression evaluation.
-Phil
So I have to do the more complex thing of keeping track of what type of fixup it is, and then handle them all. You are okay with the BYTE variant just truncating the value (like in BSTC). so it's easy to have compiled code that is broken?
Phil,
Yikes! Supporting delayed expression evaluation is kind of a showstopper for me with the current code. I'll have to make it even possible to do late expression evaluation. This sucks.
EDIT: I tried "rdlong @@@temp1, temp2", and BST does compile it. Using @@@ in the destination field doesn't make much sense to me, but maybe there's a use for it.
So there are situations where #@@@ in a source field is useful.
Andy
'Same thing's gonna happen if someone types a := constant(@label + 4) in Spin, which should be legit. (OTOH, it may be impossible to know how many bytes to reserve for the Spin bytecodes ahead of time.)
-Phil
My understanding from others was that @@@ doesn't work in spin like you showed. They say it's only allowed in DAT sections. If it's allowed in spin expressions, then that's even more of a showstopper for me.
In any event, if delayed expression evaluation seems to be an issue, I'd be inclined just to hold off on the @@@ stuff altogether for now until a more complete and unified approach to the issue presents itself. At least wait to see how Chip handles it in Spin II, so there's no disparity between the two versions.
-Phil
BSTC and Homespun already support @@@. People already rely on it. I've been asked to make it work in OpenSpin so that those who rely on it can switch to OpenSpin. As far as I understand, it does not work for spin pub/pri/var sections. You can use @@ & @ to get absolute addresses to hub memory in Spin land. It's only needed for DAT sections and PASM.
Also, what I meant by "showstopper" up there is more just in the context of my current changes to attempt implementing it. I need to back out those changes and rethink/restart the process with my new understanding of the problem.
I'm torn about accommodating those who have already taken their chances with an "off-brand" compiler*, at least until we see what Chip does with Spin II.
-Phil
*Addendum: Not that I wish to leave those who did so in the cold. It's just that OpenSpin is to become the official Spin compiler for the Prop I and that @@@ is a rather ugly hack scabbed onto those "other" compilers to meet an immediate need. I'd rather see a longer view taken with a more unified, complete, and elegant approach to the problem, rather than copying something that, in my view, falls short of those objectives. -P.