The _ret_ may be kludgy, but just 'ret' looks too understated, I think. All the conditions have underscores in them, so my eye expects to see an underscore in a prefix. I wish we could just use if_ret, but that don't make a lick of sense. I tried do_ret, but it looks weird. There is probably a better idea, but I don't have it.
NOP = 0000_0000000_000_000000000_000000000
ROR = eeee_0000000_czi_ddddddddd_sssssssss
But...
_RET_ ROR 0,0 will be treated as a NOP.
Any ROR with conditional (if_xxxx), ddddddddd <>0, sssssssss<>0, or #sssssssss will execute correctly. So it's only an extremely specific case which has no purpose that becomes a NOP. This case/exception could be flagged by the assembler.
However, what happens if this _RET_ ROR 0,0 is preceded by an AUGxx ???
... but I still find this simpler, less cluttered, and easier to read & edit.
djnz count,#loop
ret
'or
add r0,r1
ret
Identical binary code results.
PC's should be doing the housekeeping, so programmers do not have to.
And how will you write it if you want 2 instructions, an ADD and a RET ?
In Assembler you need to have control over every aspect of the generated code, you need to be able to count the cycles and the instruction count from the source.
Both is here not possible without knowing how the assembler optimizes this code.
In Assembler you need to have control over every aspect of the generated code, you need to be able to count the cycles and the instruction count from the source.
Yup, completely agree about control - which is why the solution above exists.
Count the cycles ? - somewhat less so, as already the P2 stalls in various places, making that impossible.
If I really want cycles, I time the code in a real device, or use a simulator. I do not expect to be able to extract all the timing nuances from assembler source.
Instruction count ? - I already look at List files for that, because I commonly use Macros and conditionals in my ASM for other MCUs. Many P2 designers will do the same. (once the tools catch up)
both work, but I still find this simpler, less cluttered, and easier to read & edit.
djnz count,#loop
ret
'or
add r0,r1
ret
Identical binary code results.
PC's should be doing the housekeeping, so programmers do not have to.
Totally disagree. It is a single instruction so it shouldn't be represented as two instructions. It's much easier to calculate how many clocks are being used.
So you never use macros then ?
Or include files ?
Or generic calls ?
Or conditional code ?
There are already many cases where any exact ASM source-line-to-bytes rule is broken.
Yep, bin there, done that.
At some point, when your program is big enough and complex enough to require macros and high level language features you start to ask yourself "Why am I doing all this?". It's time to just use a proper high level language.
With all that complexity added to PASM the user now has three languages to learn instead of two. Spin + PASM + all that asm meta-programming, rather than simply Spin + PASM.
Since the approach I suggest (which does get rid of the horribly ugly _underscores_) is not mutually exclusive, you are of course free to use the _ret_ form. A user taste choice.
I get the idea. It's just that now instructions as written may generate a variable number of actual instructions. Which makes all that instruction counting that people like to do on the Propeller, to get timing right, rather more difficult.
I have always campaigned for simplicity in the P2, but that boat seems to have sailed a long time ago.
Right now, PASM can be written P1 COG style, and it's still reasonable and clean. Out in HUB land, there is more, but there should be too.
In terms of large assembly language programs, people have two choices right now:
Just write PASM as the current syntax for doing that is pretty sweet.
Or
Online it as well as write procedures, methods on SPIN.
At some point macro capable tools will happen. That's a third, clearly optional thing.
I submit, as it should be. SPASM, heh, has all one needs to max out the chip and make effective space / speed choices.
Re: instructions
I'm in favor of some explicit declaration for this return functionality. A "ret" should only appear as an instruction when there is one generated.
If we don't do that, labels can get confusing. Say someone wants to jmp to the ret as an early exit, or something similar. They will have trouble.
It's tempting to say we are already doing that with the self modify instructions, but really those do not have the label problem, and can always be made explicit.
This ret if no branch functionality is different enough to warrant it's own syntax. Doing that has been a part of PASM the whole time.
I really like RET_AFTER. Is there any way to get that under 8 characters, though, so that it can sit at the tab stop just prior to the instruction? Then, it aligns with most IF_x prefixes.
I really like RET_AFTER. Is there any way to get that under 8 characters, though, so that it can sit at the tab stop just prior to the instruction? Then, it aligns with most IF_x prefixes.
I don't think the tab stop matters since we also have IF_NC_AND_NZ and similar.
I agree with the reasoning about RET being placed along with WC and WZ, after the instruction and operands, but it would be marooned way out there. I think this thing needs to go where the conditionals go, so that it jumps out in a consistent position. Otherwise, it gets lost in the noise.
Comments
Compiler features and naming doesn't impact silicon.
Personally, there are much more deficiencies in the compilers than converting 1op into 2 instructions or visa versa.
NOP = 0000_0000000_000_000000000_000000000
ROR = eeee_0000000_czi_ddddddddd_sssssssss
But...
_RET_ ROR 0,0 will be treated as a NOP.
Any ROR with conditional (if_xxxx), ddddddddd <>0, sssssssss<>0, or #sssssssss will execute correctly. So it's only an extremely specific case which has no purpose that becomes a NOP. This case/exception could be flagged by the assembler.
However, what happens if this _RET_ ROR 0,0 is preceded by an AUGxx ???
IF_RET opcode ..... _RET opcode ..... opcode ...... [WC][,][WZ][,][RET]Perhaps the last idea makes more sense because it is only performed if a jump/branch is not taken (DJxx etc).
The AUGx will be applied to the next #immediate related to the AUGx.
both work, but I still find this simpler, less cluttered, and easier to read & edit.
Identical binary code results.
PC's should be doing the housekeeping, so programmers do not have to.
And how will you write it if you want 2 instructions, an ADD and a RET ?
In Assembler you need to have control over every aspect of the generated code, you need to be able to count the cycles and the instruction count from the source.
Both is here not possible without knowing how the assembler optimizes this code.
Andy
Easy, already covered above.
The instance with the label, is made larger and slower, because the assembler does not (easily) know what jumps
to the label.
Yup, completely agree about control - which is why the solution above exists.
Count the cycles ? - somewhat less so, as already the P2 stalls in various places, making that impossible.
If I really want cycles, I time the code in a real device, or use a simulator. I do not expect to be able to extract all the timing nuances from assembler source.
Instruction count ? - I already look at List files for that, because I commonly use Macros and conditionals in my ASM for other MCUs. Many P2 designers will do the same. (once the tools catch up)
Totally disagree. It is a single instruction so it shouldn't be represented as two instructions. It's much easier to calculate how many clocks are being used.
Love the RET_AFTER syntax!
For me, it works in both examples.
At some point, when your program is big enough and complex enough to require macros and high level language features you start to ask yourself "Why am I doing all this?". It's time to just use a proper high level language.
With all that complexity added to PASM the user now has three languages to learn instead of two. Spin + PASM + all that asm meta-programming, rather than simply Spin + PASM. I get the idea. It's just that now instructions as written may generate a variable number of actual instructions. Which makes all that instruction counting that people like to do on the Propeller, to get timing right, rather more difficult.
I have always campaigned for simplicity in the P2, but that boat seems to have sailed a long time ago.
In terms of large assembly language programs, people have two choices right now:
Just write PASM as the current syntax for doing that is pretty sweet.
Or
Online it as well as write procedures, methods on SPIN.
At some point macro capable tools will happen. That's a third, clearly optional thing.
I submit, as it should be. SPASM, heh, has all one needs to max out the chip and make effective space / speed choices.
Re: instructions
I'm in favor of some explicit declaration for this return functionality. A "ret" should only appear as an instruction when there is one generated.
If we don't do that, labels can get confusing. Say someone wants to jmp to the ret as an early exit, or something similar. They will have trouble.
It's tempting to say we are already doing that with the self modify instructions, but really those do not have the label problem, and can always be made explicit.
This ret if no branch functionality is different enough to warrant it's own syntax. Doing that has been a part of PASM the whole time.
I see no reason to break that idea.
RET_NXT would fit though.
That would fit.
RET_BACK
RET_THEN
RET_PAST
This would save having to count instructions to be repeated.
Perhaps then the SETQ instruction could have pseudo REP for setting the repeat count.
This might simplify the logic???
LABLE IF_X OP RET
Hmm...Do we still have WC flags and such.
BTW there would no no IF_xxx possible on these instructions because it is a condition 0000.
That's a neat idea, and doable, but it would preclude the use of a conditional on the last repeated instruction.
PRET
P_RET
or just
RETURN
Would it simplify the logic?
Would be nice to not have to count instructions although the assembler can do it.
Isn't there a NOP or two delay after the REP instruction before the repeat loop starts? If using a SETQ or similar idea, would this avoid the nop(s)?
Not sure if precluding a conditional on the last instruction is a problem. Would take an extra instruction (2 clocks) if a conditional was required.
RET_IF
"if" for if no jmp. IF also implies what bits it's playing with...