Documentation Error for Z flag on WRLONG, WRWORD and WRBYTE Instructions
pjv
Posts: 1,903
Hi All;
The following may already have been previously addresssed elswhere, but in case it has not, then here is a description of a trap that may catch someone unawre.
I believe there is an error in the Propeller Manual V1.2 regarding the state of the Z flag in the WrLong/WrWord/WrByte instructions. The previous manual version was more correct albeit not totally clear.
For the cited assembly instructions, the current manual indicates (pages 374/375/376) in their respective improved "Opcode Table" that the Z flag is unaffected (by means of a dash unde Z Result) and in footnote2 under the "Concise Truth Table" that "The Z flag is set (1) unless the main memory address is on a long boundary" My tests indicate the Z flag results (when enabled) are not impacted at all by the location of the hub address. Instead, the Z flag is ONLY determined by the content of the register's associated LONG, WORD, or BYTE segments being written.to hub.
For example considering a cog register with the following contents, and writing to any arbitrary location in hub:
Register = $0000_0000 : with WrLong Z=1; with WrWord Z=1; WrByte Z=1;
Register = $8000_0000 : with WrLong Z=0; with WrWord Z=1; WrByte Z=1;
Register = $0000_8000 : with WrLong Z=0; with WrWord Z=0; WrByte Z=1;
Register = $0000_0080 : with WrLong Z=0; with WrWord Z=0; WrByte Z=0;
Perhaps most assemby programmers were already aware of this, but it was news to me! So hope this helps, and happy Propping.
Cheers,
Peter (pjv)
The following may already have been previously addresssed elswhere, but in case it has not, then here is a description of a trap that may catch someone unawre.
I believe there is an error in the Propeller Manual V1.2 regarding the state of the Z flag in the WrLong/WrWord/WrByte instructions. The previous manual version was more correct albeit not totally clear.
For the cited assembly instructions, the current manual indicates (pages 374/375/376) in their respective improved "Opcode Table" that the Z flag is unaffected (by means of a dash unde Z Result) and in footnote2 under the "Concise Truth Table" that "The Z flag is set (1) unless the main memory address is on a long boundary" My tests indicate the Z flag results (when enabled) are not impacted at all by the location of the hub address. Instead, the Z flag is ONLY determined by the content of the register's associated LONG, WORD, or BYTE segments being written.to hub.
For example considering a cog register with the following contents, and writing to any arbitrary location in hub:
Register = $0000_0000 : with WrLong Z=1; with WrWord Z=1; WrByte Z=1;
Register = $8000_0000 : with WrLong Z=0; with WrWord Z=1; WrByte Z=1;
Register = $0000_8000 : with WrLong Z=0; with WrWord Z=0; WrByte Z=1;
Register = $0000_0080 : with WrLong Z=0; with WrWord Z=0; WrByte Z=0;
Perhaps most assemby programmers were already aware of this, but it was news to me! So hope this helps, and happy Propping.
Cheers,
Peter (pjv)
Comments
-Phil
-Phil
What Phil said is my observation. The previous manual sort of said "Z = test of RESULT"
Cheers,
Peter (pjv)
1. Old manual says, "Z = test of RESULT."
2. But what's the result? It's usually the contents of the destination register.
3. But, oops! Somebody noticed that when you wrote $xxxx_0000 as anything but a long, the Z flag is set.
4. By a leap of logic, this was taken to mean, "If you write to anything but a long address, the Z flag is set -- i.e. the wrong conclusion.
The issue is that not enough data was taken, and the conclusion reached was probably consistent with the meager sample set. Which all brings me to a question for Peter: did you test to see what happens when the destination addresses are misaligned with the data types being written?
-Phil
@ Phil, yes I did, and was pretty sure of the accuracy of my results.
But I have been wrong several times before on my estimation of some propeller peculiarity, and just about ready to post my findings, to take another look and find an error in my conclusion. So you are very correct to suggest to take more than a minimum data set on which to base one's logic.. Thanks!
@ Kuroneko; I don't read most posts, nor remember most of those that I have read unless they are significant and add to my overall understanding of the Prop. This one I had not seen before.
I recall seeing other significant errors (at least in my opinion) in the documentation. Perhaps Parallax should set up a convenient global errata feedback method where such findings could be posted and held for document revision. Or perhaps one already exists, and I'm just not aware of it!
Cheers,
Peter (pjv)