new instructions for prop2
Bill Henning
Posts: 6,445
Hi guys (and Chip)
I think that if there is time, and the equivalents do not already exist for the Prop2, a few extra instructions detailed below would help immensely:
MUX0 dest,mask
MUX1 dest,mask
Just what it looks like - forcing selected bits to 1 or zero - since Parallax suggests using MUX instead of using OR and AND with the outa and sometimes the state of Z or C is not clearly known, it would save an instruction to force Z or C to a known state.
Whats even better is that this could easily be implemented without using any additional opcodes!
MUXC dest,mask WC <--- if for this instruction WC meant set C to 1 would be equal to MUX1
MUXNC dest,mask WC <-- again, if WC meant set C to 1 would be equal to MUX0
Assemblers could then implement new nmemonics which would map onto MUXC/MUXNC
MUX0
MUX1
SETC - if the mask is zero it would only set the carry flag
Other simple additions that would be EXTREMLY useful would be byte/word packing/unpacking - I suggest the following:
MOVBxy dest,src
would move byte y of source into byte x of dest without disturbing the rest of the destination, x and y would be 0..3
MOVWxy dest,src
would move word y of src into word x of dest again without disturbing the other half of the long register, x and y would be 0 or 1
This would improve the speed of packing bytes into longs greatly, which would speed processor emulations and external memory greatly.
Oh yes... and it would save precious registers in the cogs...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
I think that if there is time, and the equivalents do not already exist for the Prop2, a few extra instructions detailed below would help immensely:
MUX0 dest,mask
MUX1 dest,mask
Just what it looks like - forcing selected bits to 1 or zero - since Parallax suggests using MUX instead of using OR and AND with the outa and sometimes the state of Z or C is not clearly known, it would save an instruction to force Z or C to a known state.
Whats even better is that this could easily be implemented without using any additional opcodes!
MUXC dest,mask WC <--- if for this instruction WC meant set C to 1 would be equal to MUX1
MUXNC dest,mask WC <-- again, if WC meant set C to 1 would be equal to MUX0
Assemblers could then implement new nmemonics which would map onto MUXC/MUXNC
MUX0
MUX1
SETC - if the mask is zero it would only set the carry flag
Other simple additions that would be EXTREMLY useful would be byte/word packing/unpacking - I suggest the following:
MOVBxy dest,src
would move byte y of source into byte x of dest without disturbing the rest of the destination, x and y would be 0..3
MOVWxy dest,src
would move word y of src into word x of dest again without disturbing the other half of the long register, x and y would be 0 or 1
This would improve the speed of packing bytes into longs greatly, which would speed processor emulations and external memory greatly.
Oh yes... and it would save precious registers in the cogs...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
Comments
>> MOVBxy dest,src
>> MOVWxy dest,src
Yes, yes, yes! I've been thinking about that too. Today's lack of a "reverse MUX" is quite limiting.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
You can do MUX0 and MUX1 already. Just use OR to set selected bits to 1 and use ANDN to set selected bits to 0.
I agree that byte and word packing and unpacking would be useful. It's a lot of opcodes though and it's pretty late
in the game at this point. Your scheme doesn't deal with variable packing and unpacking where I might want to use
a counter or index to select which byte or word to use. It would be possible to set some combination of Z and C flags
from a counter and use that to control which of 4 instructions to use conditionally, but it might be just as fast and just
as much space to do shifts and logical operations.
It is late in the game... I think I suggested these last year already, but wanted to suggest them again.
Using shift/and/or is very slow relatively speaking... and as for using a counter or index, you could set the extra source/destination bits in the instruction
I would love to use them even if there was no way of changing the byte index... consider the code below:
mux30 temp, ina
mux31 temp, ina
mux32 temp, ina
mux 33 temp, ina
It would build a 32-bit long from four consecutive samples at 50ns intervals... excellent for ViewPort like applications and a LOT more
Bill
p.s.
I've used AND's and OR's for MUX0/1 functionality, however Parallax strongly suggested in many places that MUX{N}[noparse][[/noparse]C|Z] be used
instead, as I recall.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
Post Edited (Bill Henning) : 5/1/2009 2:48:34 PM GMT
I could be wrong, but any suggestions that Parallax has made regarding MUXes I'm sure were meant to improve a program's efficiency over bulkier code, not to suggest that they operate on the hardware differently from ANDN and OR. Both types are read-modify-write instructions.
-Phil
Excellent... I've been avoiding them based on a vague memory.
Thanks,
Bill ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
Doing that like literally took over 20 instructions off my lookup rountine and made the code so much faster.
Because really, unless your using the crazy asm loader techniques to delete the asm images the array will take up space in the main memory anyway.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Granted. And that is fine for many situations, however, there are situations where wrbyte, etc are not useful especially where time is a factor. It is much faster to compose a long and use wrlong even with shift blah. It is even better to just keep it all in the cog if possible.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230