The key thing is making the focus of the label clear. That snagged me big.
I feel odd about the rep following the instructions to be repeated. Besides, it's a zero overhead loop. Seems natural for it to precede that which is to be looped. And wouldn't having the rep follow the instructions complicate the circuit?
I feel odd about the rep following the instructions to be repeated. Besides, it's a zero overhead loop. Seems natural for it to precede that which is to be looped. And wouldn't having the rep follow the instructions complicate the circuit?
No, the REP would only follow in code; it would still lead in the binary.
As for the odd feeling, it will pass. We have only ever seen/used REP in its current form, so anything else will initially feel unnatural. However, considering that the "contol" instruction for every other loop construct in PASM follows the block that's looped over, REP is already an oddball.
That would make the code look like:
'toggle clock n times and return
ToggleClkSub setb outa,#PinPclk
clrb outa,#PinPclk
rep #n, #ToggleClkSub
ret
Now it looks just like the others! (note: i also switched the operands around for consistency.)
In truth, I was somewhat jesting when I made the suggestion. But now that I've seen the code, it may actually make sense to do this! Maybe.
We've already got ## adding an instruction in. What if somebody wants to jump into the loop @ToggleClkSub? They might think doing that would work as written, but they might miss the REP in the binary as generated... or would they? With AUG, it gets inserted right at label address, so that would seem to always work.
Honestly, I'm open at this point. The label target really got me. Now it's just what is optimal.
I liked that REP mirrored SPIN somewhat, both in function and position.
Control instructions being at the bottom in assembly is basically goto. And the programmer is responsible for setting up the control structure too. REP is just one notch above that. The programmer is more specifying what an existing control structure does, and that's not quite like goto enough to potentially warrant REP being positioned differently.
This does very significantly reduce the potential for label ambiguity, to me at least.
I'll think on that one some... I might end up liking it.
I feel odd about the rep following the instructions to be repeated. Besides, it's a zero overhead loop. Seems natural for it to precede that which is to be looped. And wouldn't having the rep follow the instructions complicate the circuit?
No, the REP would only follow in code; it would still lead in the binary.
As for the odd feeling, it will pass. We have only ever seen/used REP in its current form, so anything else will initially feel unnatural. However, considering that the "contol" instruction for every other loop construct in PASM follows the block that's looped over, REP is already an oddball.
That would make the code look like:
'toggle clock n times and return
ToggleClkSub setb outa,#PinPclk
clrb outa,#PinPclk
rep #n, #ToggleClkSub
ret
Now it looks just like the others! (note: i also switched the operands around for consistency.)
In truth, I was somewhat jesting when I made the suggestion. But now that I've seen the code, it may actually make sense to do this! Maybe.
in the other loop cases the check&jump instruction will really be inserted at the end of the repeated instructions.
Here obviously not.
so this could cause some confusion if you read the created binary and find the instructions in strange order.
but usually we don't do this ;-) don't we
might be a surprise and needs good documentation if we did this.
and since the REP will only be executed once instruction counting would also be confused.
For me, in general, I'll populate the rough structure with jump variants, a couple of labels for storage, destinations, etc... and get that sorted, maybe with a test instruction or two.
Then I'll start to make it do something by filling in instructions. Often, a little can be done at a time, leaving the empty control structures there to be used as it all fleshes out.
For smaller routines, I'll write it and add controls inline as needed.
So far, when doing this, I think REP... then some stuff to get done. It comes from SPIN. Everything else, I think "goto" and that's just assembly language thinking. Most significantly, I don't consider REP in PASM as a primary element in a larger structure. It's narrow focus, like "get this stuff done X times, quick" atomic, as opposed to something bigger that may branch in and out, etc... non-atomic.
'toggle clock n times and return
ToggleClkSub setb outa,#PinPclk
clrb outa,#PinPclk
rep #n, #ToggleClkSub
ret
I doubt Chip's assembler is complex enough to find a REP and go back to the label and insert the instruction. I can think of some code (that wouldn't run properly) that might even get the assembler stuck in an infinite loop or recursion if the assembler isn't written properly, i.e. even more complexly. Also, doing this will make hand-calculating addresses much harder.
I quite liked the recent arrangement with the "loopend" labelling after the final instruction. One just had to make a point of leaving a gap after that label; the layout looked good then.
Putting REP at the end of code will probably lead to more confusion for SPIN users migrating to PASM.
I don't think shifting REP was a serious contender, but swapping operand order is an open suggestion.
You cannot use #Label as you did, as REP currently supports an immediate count as additional syntax, so Chip has @Label to allow both forms.
My preference is to simplify the most common - ie use no prefix for label, and # for immediate & for the less common register content, use a tag like [reg] or @Reg (both seen in other assemblers).
Comments
The key thing is making the focus of the label clear. That snagged me big.
I feel odd about the rep following the instructions to be repeated. Besides, it's a zero overhead loop. Seems natural for it to precede that which is to be looped. And wouldn't having the rep follow the instructions complicate the circuit?
No, the REP would only follow in code; it would still lead in the binary.
As for the odd feeling, it will pass.
That would make the code look like:
'toggle clock n times and return ToggleClkSub setb outa,#PinPclk clrb outa,#PinPclk rep #n, #ToggleClkSub retNow it looks just like the others! (note: i also switched the operands around for consistency.)
In truth, I was somewhat jesting when I made the suggestion. But now that I've seen the code, it may actually make sense to do this! Maybe.
We've already got ## adding an instruction in. What if somebody wants to jump into the loop @ToggleClkSub? They might think doing that would work as written, but they might miss the REP in the binary as generated... or would they? With AUG, it gets inserted right at label address, so that would seem to always work.
Honestly, I'm open at this point. The label target really got me. Now it's just what is optimal.
I liked that REP mirrored SPIN somewhat, both in function and position.
Control instructions being at the bottom in assembly is basically goto. And the programmer is responsible for setting up the control structure too. REP is just one notch above that. The programmer is more specifying what an existing control structure does, and that's not quite like goto enough to potentially warrant REP being positioned differently.
This does very significantly reduce the potential for label ambiguity, to me at least.
I'll think on that one some... I might end up liking it.
in the other loop cases the check&jump instruction will really be inserted at the end of the repeated instructions.
Here obviously not.
so this could cause some confusion if you read the created binary and find the instructions in strange order.
but usually we don't do this ;-) don't we
might be a surprise and needs good documentation if we did this.
and since the REP will only be executed once instruction counting would also be confused.
I like the REP in front
For me, in general, I'll populate the rough structure with jump variants, a couple of labels for storage, destinations, etc... and get that sorted, maybe with a test instruction or two.
Then I'll start to make it do something by filling in instructions. Often, a little can be done at a time, leaving the empty control structures there to be used as it all fleshes out.
For smaller routines, I'll write it and add controls inline as needed.
So far, when doing this, I think REP... then some stuff to get done. It comes from SPIN. Everything else, I think "goto" and that's just assembly language thinking. Most significantly, I don't consider REP in PASM as a primary element in a larger structure. It's narrow focus, like "get this stuff done X times, quick" atomic, as opposed to something bigger that may branch in and out, etc... non-atomic.
I doubt Chip's assembler is complex enough to find a REP and go back to the label and insert the instruction. I can think of some code (that wouldn't run properly) that might even get the assembler stuck in an infinite loop or recursion if the assembler isn't written properly, i.e. even more complexly. Also, doing this will make hand-calculating addresses much harder.
I don't think shifting REP was a serious contender, but swapping operand order is an open suggestion.
You cannot use #Label as you did, as REP currently supports an immediate count as additional syntax, so Chip has @Label to allow both forms.
My preference is to simplify the most common - ie use no prefix for label, and # for immediate & for the less common register content, use a tag like [reg] or @Reg (both seen in other assemblers).