I was waiting for the "You are free to not use it." argument to come out.
It's perfectly true of course.
My worry about such things is that they can become mind bendingly complicated for anyone but the author to read. Probably hard for the author if he revisits his code after half a year.
That's OK too.
Except, wizards will use such things. Their code will end up in OBEX or whatever.
Others coming along to investigate the P2 will see that and run!
No need to make this personal. I think he's making a valid statement. While I like the general idea (being able to quickly skip a number of intructions), I think skip has got some real issues that shouldn't just be swept aside or marginalized.
Obviously some details need to be worked out, but so far the SKIP concept looks very compelling.
See. The guy who is not afraid to light a fire under his butt gets it.
I think we all get it. But this minor change has potentially significant impact on how code is written. As a result, taking a critical look at it is the right thing to do, no?
I see it as allowing for speed and compactness that is not achievable by any other means. This is ninja programming in assembler.
Indeed! And I like it, mostly! I just think it would be safer if it was cancelled by a branch instruction. It would still allow for ninja coding (your example above would still work, right?) without accidentally throwing a shuriken in your foot.
I see it as allowing for speed and compactness that is not achievable by any other means. This is ninja programming in assembler.
Indeed! And I like it, mostly! I just think it would be safer if it was cancelled by a branch instruction. It would still allow for ninja coding (your example above would still work, right?) without accidentally throwing a shuriken in your foot.
Or at least a RET...
trying to think of cases where Branch would be useful and it seems the whole idea behind skip, is to allow removal of branch instructions.
In XIP code, a re-address has a significant time cost, so skips within the range of the short-skip (9 single opcodes) would usually be faster.
I think we all get it. But this minor change has potentially significant impact on how code is written. As a result, taking a critical look at it is the right thing to do, no?
I agree, I think it also needs some Assembler support, so the Skip MASK does not have to be manually crafted and maintained in the most common use cases (as in my IF-ELSE example above). That does not look hard to do.
Even more obtuse cases, like Chips, could benefit from some simple tools intelligence.
I see it as allowing for speed and compactness that is not achievable by any other means. This is ninja programming in assembler.
Indeed! And I like it, mostly! I just think it would be safer if it was cancelled by a branch instruction. It would still allow for ninja coding (your example above would still work, right?) without accidentally throwing a shuriken in your foot.
That it endures through branches is a really strong point. It's going to make The bytecode interpreter really compact. I will have an example up shortly.
That it endures through branches is a really strong point. It's going to make The bytecode interpreter really compact. I will have an example up shortly.
I agree that this is really powerful, but unless you have really good tools and debugging facilities to help manage this, it's *going* to come back and bite you in the Smile. Use it sparingly. This feels like templates and lambda functions rolled into macro-magic to me. (C++ programmers will understand what I mean)
That it endures through branches is a really strong point. It's going to make The bytecode interpreter really compact. I will have an example up shortly.
Does it need to endure thru a RET ?
It's not an issue, I think, because if you allow the RET in your SKIP bits, you would not have any 1's above. The exception would be if the RET was conditional, I suppose.
Making SKIP end upon RET would be trivial, anyway.
Heater, this is ASM, why should it be restricted to the beginner level. You always bring up the OBEX and beginners seeing this stuff and freaking out. That is a fine argument for Spin remaining simpler and intuitive, but ASM is for the advanced coders. Also, have you been to the OBEX? It's full of piles of very scary code. P1 is capable of some gnarly obfuscated stuff if you want to do it. You can easily make completely unreadable, hard to follow, obfuscated messes in Spin/PASM for P1. You can also make very clean, simple to follow, elegant code. I think both things are true for P2 and these new changes/additions.
P2 has interrupts now, so that complicates the Smile out of everything for debugging and following code paths. You can write interrupt code that messes with the mainline code flow (isn't it glorious?!) and that's even more invisible at a glance.
Others:
I think it's simpler to understand if there are no caveats, like cancelled by some instructions and not others. The aug/alt instructions are instructions so they take a bit in the mask. It allows for even more combinations and compactness. Yes, it's all a bit harder to read/follow, but with comments/documentation it's workable. It's a huge code density win.
I think trying to make the assembler facilitate the generation of SKIP masks is a fool's errand, as it would impose some structure which could really constipate matters. If you're going to use SKIP, you're just going to need to be responsible and wise about it.
and labelling "SKIP" related code blocks like this
' Read/write hub memory
'
rw_mem
.1 rfbyte m 'one of these (offset) 3 x
.2 rfword m
.3 rflong m
.4 add m,pbase 'one of these (base) 3 x
.5 add m,vbase
.6 add m,dbase
.7 popa x 'maybe this (index) 2 x (on/off)
.8 shl x,#1 '...and maybe this
.9 shl x,#2 '...or maybe this
.10 add m,x '...and this
.11 rdbyte x,m 'one of these (read) 6 x
.12 rdword x,m
.13 rdlong x,m
.14 _ret_ pusha x '...and this
.15 popa x 'or this (write)
.16 _ret_ wrbyte x,m '...and one of these
.17 _ret_ wrword x,m
.18 _ret_ wrlong x,m
I think trying to make the assembler facilitate the generation of SKIP masks is a fool's errand, as it would impose some structure which could really constipate matters. If you're going to use SKIP, you're just going to need to be responsible and wise about it.
I'm not following the logic here ?
The assembler-help use, is not intended to cover all cases, you are always free to enter random bit patterns, in hand crafted kernels.
The assembler cases suggested are for the common IF_ELSE structures, where mask bits are not random, but are really opcode-counters.
I can see uses for Skip in XIP code, and if it is a revision minefield, it will tend to be avoided because of that.
The software help needed here is not complex, just a variation on existing relative jump calculations.
jmg,
You can already do common if/else stuff with the if_z/if_nz prefixes (or the other variants). The skip instruction is for multiple combination and more complex cases.
The aug/alt instructions are instructions so they take a bit in the mask. It allows for even more combinations and compactness. Yes, it's all a bit harder to read/follow, but with comments/documentation it's workable. It's a huge code density win.
With some simple Assembler housekeeping, it can be no harder to follow at all. Comments are not code, and often give a false sense of what you hoped would happen....
I'm OK with the SKIP instruction. I hope that anybody that uses it documents it well so the code is semi-readable. In my opinion, I don't think it's necessary to complicate the assembler by adding special support for the SKIP instruction. Let people handcode the skip patterns. Why take the fun out of it by letting the assembler generate the patterns.
SBIC - Skip if Bit in I/O Register is Cleared
Description:
This instruction tests a single bit in an I/O register and skips the next instruction if the bit is cleared. This instruction operates on the lower 32 I/O registers - addresses 0-31.
This is pretty wild too, let an I/O pin control whether code is executed or not...
I can think of cases where I would not want the skip to be cancelled by a ret. I think it's better if it's not cancelled by anything (except another skip).
I'm OK with the SKIP instruction. I hope that anybody that uses it documents it well so the code is semi-readable. In my opinion, I don't think it's necessary to complicate the assembler by adding special support for the SKIP instruction. Let people handcode the skip patterns. Why take the fun out of it by letting the assembler generate the patterns.
My approach is a little different.
I like to write code that is inherently clear, and safe.
PC's and software exist to manage the housekeeping.
That is why I already use Macros, and Conditionals in my Assembly
Mundane Housekeeping is less 'fun', than risk. "Let people handcode the skip patterns" seems like quite bad advice to give any novice, but there was no winky here.
jmg,
You can already do common if/else stuff with the if_z/if_nz prefixes (or the other variants). The skip instruction is for multiple combination and more complex cases.
Not in a SKIP format, which is the broader appeal Skip has to me.
Of course, Skip can also be used for complex cases, but it is by no means limited to that.
I agree that this is really powerful, but unless you have really good tools and debugging facilities to help manage this, it's *going* to come back and bite you in the Smile. Use it sparingly. This feels like templates and lambda functions rolled into macro-magic to me. (C++ programmers will understand what I mean)
I'm not sure what your objection to lambda functions is. Maybe they're more awkward in C++ than they were in LISP.
Comments
It's perfectly true of course.
My worry about such things is that they can become mind bendingly complicated for anyone but the author to read. Probably hard for the author if he revisits his code after half a year.
That's OK too.
Except, wizards will use such things. Their code will end up in OBEX or whatever.
Others coming along to investigate the P2 will see that and run!
No need to make this personal. I think he's making a valid statement. While I like the general idea (being able to quickly skip a number of intructions), I think skip has got some real issues that shouldn't just be swept aside or marginalized.
See. The guy who is not afraid to light a fire under his butt gets it.
I think we all get it. But this minor change has potentially significant impact on how code is written. As a result, taking a critical look at it is the right thing to do, no?
Indeed! And I like it, mostly! I just think it would be safer if it was cancelled by a branch instruction. It would still allow for ninja coding (your example above would still work, right?) without accidentally throwing a shuriken in your foot.
I can see massive potential in activating/de-activating debug code snippets inside code.
The speed/size benefits for SPIN2 are worth it.
trying to think of cases where Branch would be useful and it seems the whole idea behind skip, is to allow removal of branch instructions.
In XIP code, a re-address has a significant time cost, so skips within the range of the short-skip (9 single opcodes) would usually be faster.
I agree, I think it also needs some Assembler support, so the Skip MASK does not have to be manually crafted and maintained in the most common use cases (as in my IF-ELSE example above). That does not look hard to do.
Even more obtuse cases, like Chips, could benefit from some simple tools intelligence.
That it endures through branches is a really strong point. It's going to make The bytecode interpreter really compact. I will have an example up shortly.
It's not an issue, I think, because if you allow the RET in your SKIP bits, you would not have any 1's above. The exception would be if the RET was conditional, I suppose.
Making SKIP end upon RET would be trivial, anyway.
P2 has interrupts now, so that complicates the Smile out of everything for debugging and following code paths. You can write interrupt code that messes with the mainline code flow (isn't it glorious?!) and that's even more invisible at a glance.
Others:
I think it's simpler to understand if there are no caveats, like cancelled by some instructions and not others. The aug/alt instructions are instructions so they take a bit in the mask. It allows for even more combinations and compactness. Yes, it's all a bit harder to read/follow, but with comments/documentation it's workable. It's a huge code density win.
skip ##!{1,6,13,14} ' "use these" jmp #rw_mem 'instead of skip ##%001111110111100 'execute jmp/rfbyte/add/rdlong/pusha jmp #rw_memand labelling "SKIP" related code blocks like this
The assembler-help use, is not intended to cover all cases, you are always free to enter random bit patterns, in hand crafted kernels.
The assembler cases suggested are for the common IF_ELSE structures, where mask bits are not random, but are really opcode-counters.
I can see uses for Skip in XIP code, and if it is a revision minefield, it will tend to be avoided because of that.
The software help needed here is not complex, just a variation on existing relative jump calculations.
You can already do common if/else stuff with the if_z/if_nz prefixes (or the other variants). The skip instruction is for multiple combination and more complex cases.
Chip has said that is easy to do.
Chip has cases where preserve across Branch are useful, and I'm ok with that. We wait for examples.
With some simple Assembler housekeeping, it can be no harder to follow at all.
Comments are not code, and often give a false sense of what you hoped would happen....
Or, not let SKIP be skipped...
Any RET that is skipped, is surely invisible ? - skip has no idea WHAT it skips over.
SBIC - Skip if Bit in I/O Register is Cleared
Description:
This instruction tests a single bit in an I/O register and skips the next instruction if the bit is cleared. This instruction operates on the lower 32 I/O registers - addresses 0-31.
This is pretty wild too, let an I/O pin control whether code is executed or not...
My approach is a little different.
I like to write code that is inherently clear, and safe.
PC's and software exist to manage the housekeeping.
That is why I already use Macros, and Conditionals in my Assembly
Mundane Housekeeping is less 'fun', than risk.
"Let people handcode the skip patterns" seems like quite bad advice to give any novice, but there was no winky here.
A novice is not coding in ASM.
It's the ON X GOTO of PASM.
I agree with Roy here. It's Assembly language.
Of course, Skip can also be used for complex cases, but it is by no means limited to that.