You are right, but I think explaining the range is just fine.
The way I see it, getting the benefit of wraparound at values other than powers of two is easily worth having to consider the bounds. Once done, it works as expected.
Maybe INCCMP is better?
I agree MOD isn't as accurate as everybody would like. But I also thing it conveys what will happen when somebody reads the instruction description too...
INCTSTZ ? Increment D, test against S and zero? It's hard to put into a mnemonic that gets one as far as MOD does, with only a bounding value consideration.
INCPMOD "Increment with pseudo-mod?" Maybe that is most accurate? Heh, INCNMOD, for "it's not division modulus!"
Chip?! These are instructions for PASM2 that we will use in our SOFTWARE. Just because it's combining what would normally be two things into an atomic operation, doesn't mean it's not software anymore!
The problem here is that you guys are quite certain that people are going to conflate division modulus with counter modulus because they can't think about the letters MOD in any other way, even when coupled with another letter sequence INC that doesn't make any sense, anyway, when combined with their concept of MOD.
Not to argue about the potential confusion INCMOD and DECMOD might cause, but just look at this to understand something about modulus counters, which have existed before software languages used the letters MOD to imply division modulus:
11.3 Modulus of a Counter
The modulus (MOD number) of a counter is the number of different logic states it goes through before it comes back to the initial state to repeat the count sequence. An n-bit counter that counts through all its natural states and does not skip any of the states has a modulus of 2n. We can see that such counters have a modulus that is an integral power of 2, that is, 2, 4, 8, 16 and so on. These can be modified with the help of additional combinational logic to get a modulus of less than 2n.
That's pretty much the concept Chip. Again, I personally am fine with explaining the value check going in. From there, it's really useful and not hard to grok.
I'm for leaving it and simply educating people on what it does.
Of course, we could stretch it out to seven characters:
INCMODU/DECMODU
But that would only cause further consternation as programmers would struggle to make sense of what "INCrement (division) MODulus Unsigned" was actually doing in their PASM code. That could really detonate some heads! I would have to ask, "What did you think you were going to do with that instruction?"
Ah, please take no offense, Roy and jmg. I'm just having some fun here.
I'm quite certain people have a predefined notion of what modulus/modulo means, period. Regardless if it's counter modulus or division modulus. It's still a fundamental math operation.
Also, I don't understand why it matters at all about the electronics hardware description. These are assembly instructions for use in software, by programmers who are going to think MOD means modulo operation, which means INCMOD and DECMOD are not going to work as they expect. The manual is going to need large underlined bolded red text stating the for values of D that are above N, these operations do not do what you think!
I foresee a P2 manual filled with large underlined bolded red text for programmers to have to constantly go back to read to remind themselves about some special consideration they need to deal with... I don't think of that as very fun at all.
In the case of MOVBYTS and SETBYTS are the Z and C flags written? The latest document shows that the flags are not written.
It just occured to me that I do the Flag test wrong in my testcode, so forget all the Z and C flag description in my post.
It was anyway surprising that the flags always behaved the same, so I should have noticed it.
I will test the flags again when I have time.
I think I can speak for at least some of us that are easily confused. I think INCMOD and DECMOD are good for peeps like me.
The problem with INCLIM and DECLIM is that they sound like you are making limit changes.
Just as a reminder, the purpose of this thread is to get more details about P2 instructions that are listed in Prop2_Docs.txt, and not to suggest changes for the instructions. Though INCMOD and DECMOD are not fully defined in Prop2_Docs.txt they are defined in the P2 document posted at http://parallaxsemiconductor.com . It would be useful to compare the two documents and update Prop2_Docs.txt with detail from the older document.
It just occured to me that I do the Flag test wrong in my testcode, so forget all the Z and C flag description in my post.
It was anyway surprising that the flags always behaved the same, so I should have noticed it.
I will test the flags again when I have time.
It looks like ESWAP8 and ESWAP4 always set the Z flag and clear the C flag.
SETBYTS and MOVBYTS don't allow WC or WZ, the bits are used as part of the instruction encoding.
It would be useful to compare the two documents and update Prop2_Docs.txt with detail from the older document.
This should be done with great caution. Lack of documentation is better than out of date but authoritative-looking documentation.
And for my background as a near 100% software developer, anything that says "MOD" implies the modulus operator and I can use it to clamp a value. Appreciating that the modulus of a counter means something different, I agree with Roy that this will probably trip up some developers and will need special calling out in the documentation. FWIW, "INCWRAP/DECWRAP" is a more accurate name to my sensibilities.
This should be done with great caution. Lack of documentation is better than out of date but authoritative-looking documentation.
And for my background as a near 100% software developer, anything that says "MOD" implies the modulus operator and I can use it to clamp a value. Appreciating that the modulus of a counter means something different, I agree with Roy that this will probably trip up some developers and will need special calling out in the documentation. FWIW, "INCWRAP/DECWRAP" is a more accurate name to my sensibilities.
bartgrantham, my suggestion for including text from the earlier document was intended for the editor of Prop2_Docs.txt, which I think is Chip for the most part. I'm sure he can determine whether the information is accurate or not.
As far as INCMOD and DECMOD, the current names make about as much sense as any of the others that have been proposed, so I don't have a problem with keeping the names as they are.
Bits [7 to 0] of S are copied to bits [25,17,9,1,24,16,8,0] of D.
Bits [15 to 8] of S are copied to bits [27,19,11,3,26,18,10,2] of D.
Bits [23 to 16] of S are copied to bits [29,21,13,5,28,20,12,4] of D.
Bits [31 to 24] of S are copied to bits [31,23,15,7,30,22,14,6] of D.
Z flag is set and Carry flag is cleared when WZ WC effect is used.
Below is a list of the corresponding bit destinations.
It takes the four original bytes, spaces apart their bits, then interleaves them together. Why? We don't know.
Because it can??
Never mind, I'm walking my bits through Brian's example: So if you have 0000_0000_1111_1111_0000_0000_1111_1111 you get 0101_0101_0101_0101_0101_0101_0101_0101 ?
It takes the four original bytes, spaces apart their bits, then interleaves them together. Why? We don't know.
There's still the ones for WORDs right? Take two words and interleave their bits in a destination DWORD, and take a DWORD and do the reverse, right? That's the really interesting and useful variant.
There's still the ones for WORDs right? Take two words and interleave their bits in a destination DWORD, and take a DWORD and do the reverse, right? That's the really interesting and useful variant.
Yes, they are there. This is output of MERGEW instruction -
P2 Test Toolbox V1.5
Before: Pass #0 Log: OFF=0 Dump:BYTE
Instruction: %1000111_11_0_1111_000000100_000000011 $004,$003 4,3
Flags: Z=0 C=0
D=$0000_0000 %0000_0000_0000_0000_0000_0000_0000_0000 0
S=$0000_FFFF %0000_0000_0000_0000_1111_1111_1111_1111 65535
After: Pass #1 Log: OFF=0 Dump:BYTE
Instruction: %1000111_11_0_1111_000000100_000000011 $004,$003 4,3
Flags: Z=1 C=0
D=$5555_5555 %0101_0101_0101_0101_0101_0101_0101_0101 1431655765
S=$0000_FFFF %0000_0000_0000_0000_1111_1111_1111_1111 65535
>S$FFFF0000 <-------- change the S register here
' run it again D is how it was after first execution
>O
P2 Test Toolbox V1.5
Before: Pass #0 Log: OFF=0 Dump:BYTE
Instruction: %1000111_11_0_1111_000000100_000000011 $004,$003 4,3
Flags: Z=1 C=0
D=$5555_5555 %0101_0101_0101_0101_0101_0101_0101_0101 1431655765
S=$FFFF_0000 %1111_1111_1111_1111_0000_0000_0000_0000 4294901760 -65536
After: Pass #1 Log: OFF=0 Dump:BYTE
Instruction: %1000111_11_0_1111_000000100_000000011 $004,$003 4,3
Flags: Z=1 C=0
D=$AAAA_AAAA %1010_1010_1010_1010_1010_1010_1010_1010 2863311530 -1431655766
S=$FFFF_0000 %1111_1111_1111_1111_0000_0000_0000_0000 4294901760 -65536
FYI, the SPLITB/MERGEB pair can be used to do 3 and 4 dimensional z-order curves, while the SPLITW/MERGEW paiir is good for the normal 2 dimensional z-order curve.
FYI, the SPLITB/MERGEB pair can be used to do 3 and 4 dimensional z-order curves, while the SPLITW/MERGEW paiir is good for the normal 2 dimensional z-order curve.
z-order curves (sometimes called morton order) are used heavily on GPUs for textures, giving better spacial relationship to data. It can also be used for quadtree arrangements among other things.
Odd bits (1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31) are copied to upper word (16 to 31)
Even bits (0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30) are copied to lower word. (0 to 15)
Below is a list of the corresponding bit destinations
So the interesting thing is that you can take an X, Y 2d location and put into MERGEW and then use the result as it's address in memory.
You can take the memory address, and run it thru SPLITW, and get the X, Y location in 2d space.
It looks like ESWAP8 and ESWAP4 always set the Z flag and clear the C flag.
Andy
if this is true, then what sense does it make to destroy the ZC flags if no new information is provided by always setting Z and clearing C ???
wouldn´t it be better to leave ZC at their previous values?
if this is true, then what sense does it make to destroy the ZC flags if no new information is provided by always setting Z and clearing C ???
wouldn´t it be better to leave ZC at their previous values?
He meant that if you provide WZ and WC suffixes to the instruction, those are the values that will be received by the flags. Without those suffixes, the flags are not affected.
So the interesting thing is that you can take an X, Y 2d location and put into MERGEW and then use the result as it's address in memory.
You can take the memory address, and run it thru SPLITW, and get the X, Y location in 2d space.
That's wild! I'd have to think about that for a while to let it gel in my head.
When you employ that method to order your 2D data, then a linear read of memory will give you an NxN section of your 2D data. For example, if you store 8bit pixels, then reading 4 consecutive bytes (aligned) gives you a 2x2 chunk of the pixels, reading 16 consecutive bytes gives you a 4x4 chunk of pixels. It makes for much more cache friendly memory accesses when walking through that 2D data in any direction from one 2D location to another.
Comments
The way I see it, getting the benefit of wraparound at values other than powers of two is easily worth having to consider the bounds. Once done, it works as expected.
Maybe INCCMP is better?
I agree MOD isn't as accurate as everybody would like. But I also thing it conveys what will happen when somebody reads the instruction description too...
INCTSTZ ? Increment D, test against S and zero? It's hard to put into a mnemonic that gets one as far as MOD does, with only a bounding value consideration.
INCPMOD "Increment with pseudo-mod?" Maybe that is most accurate? Heh, INCNMOD, for "it's not division modulus!"
The problem here is that you guys are quite certain that people are going to conflate division modulus with counter modulus because they can't think about the letters MOD in any other way, even when coupled with another letter sequence INC that doesn't make any sense, anyway, when combined with their concept of MOD.
Not to argue about the potential confusion INCMOD and DECMOD might cause, but just look at this to understand something about modulus counters, which have existed before software languages used the letters MOD to imply division modulus:
http://my.safaribooksonline.com/book/electrical-engineering/9780470032145/11-counters-and-registers/sec_11_3_html
I'm for leaving it and simply educating people on what it does.
INCMODU/DECMODU
But that would only cause further consternation as programmers would struggle to make sense of what "INCrement (division) MODulus Unsigned" was actually doing in their PASM code. That could really detonate some heads! I would have to ask, "What did you think you were going to do with that instruction?"
Ah, please take no offense, Roy and jmg. I'm just having some fun here.
Also, I don't understand why it matters at all about the electronics hardware description. These are assembly instructions for use in software, by programmers who are going to think MOD means modulo operation, which means INCMOD and DECMOD are not going to work as they expect. The manual is going to need large underlined bolded red text stating the for values of D that are above N, these operations do not do what you think!
I foresee a P2 manual filled with large underlined bolded red text for programmers to have to constantly go back to read to remind themselves about some special consideration they need to deal with... I don't think of that as very fun at all.
Sounds ok, or INCLIM / DECLIM for increment inside limit, as I believe this is a Bounded/Limited increment that Wraps.
What exactly does it do, outside the limit - I'm presuming it increments until the limit boundary is hit, then snaps back.
It just occured to me that I do the Flag test wrong in my testcode, so forget all the Z and C flag description in my post.
It was anyway surprising that the flags always behaved the same, so I should have noticed it.
I will test the flags again when I have time.
Andy
The problem with INCLIM and DECLIM is that they sound like you are making limit changes.
Rich
It looks like ESWAP8 and ESWAP4 always set the Z flag and clear the C flag.
SETBYTS and MOVBYTS don't allow WC or WZ, the bits are used as part of the instruction encoding.
Andy
This should be done with great caution. Lack of documentation is better than out of date but authoritative-looking documentation.
And for my background as a near 100% software developer, anything that says "MOD" implies the modulus operator and I can use it to clamp a value. Appreciating that the modulus of a counter means something different, I agree with Roy that this will probably trip up some developers and will need special calling out in the documentation. FWIW, "INCWRAP/DECWRAP" is a more accurate name to my sensibilities.
My proposal is to use instead of MOD
> COUNTMOD
As far as INCMOD and DECMOD, the current names make about as much sense as any of the others that have been proposed, so I don't have a problem with keeping the names as they are.
Bits [7 to 0] of S are copied to bits [25,17,9,1,24,16,8,0] of D.
Bits [15 to 8] of S are copied to bits [27,19,11,3,26,18,10,2] of D.
Bits [23 to 16] of S are copied to bits [29,21,13,5,28,20,12,4] of D.
Bits [31 to 24] of S are copied to bits [31,23,15,7,30,22,14,6] of D.
Z flag is set and Carry flag is cleared when WZ WC effect is used.
Below is a list of the corresponding bit destinations.
It takes the four original bytes, spaces apart their bits, then interleaves them together. Why? We don't know.
Because it can??
Never mind, I'm walking my bits through Brian's example: So if you have 0000_0000_1111_1111_0000_0000_1111_1111 you get 0101_0101_0101_0101_0101_0101_0101_0101 ?
I guess I should just try it and see.
Yes, they are there. This is output of MERGEW instruction -
I haven't done SPLITW yet, but it's next.
Brian's Test Toolbox is really cool!!
FYI, the SPLITB/MERGEB pair can be used to do 3 and 4 dimensional z-order curves, while the SPLITW/MERGEW paiir is good for the normal 2 dimensional z-order curve.
SPLITW works as advertised, too.
I'll take your word for SPLITB/MERGEB!
Odd bits (1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31) are copied to upper word (16 to 31)
Even bits (0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30) are copied to lower word. (0 to 15)
Below is a list of the corresponding bit destinations
You can take the memory address, and run it thru SPLITW, and get the X, Y location in 2d space.
wouldn´t it be better to leave ZC at their previous values?
He meant that if you provide WZ and WC suffixes to the instruction, those are the values that will be received by the flags. Without those suffixes, the flags are not affected.
That's wild! I'd have to think about that for a while to let it gel in my head.