Shop OBEX P1 Docs P2 Docs Learn Events
Documentation Error for Z flag on WRLONG, WRWORD and WRBYTE Instructions — Parallax Forums

Documentation Error for Z flag on WRLONG, WRWORD and WRBYTE Instructions

pjvpjv Posts: 1,903
edited 2012-04-07 01:09 in Propeller 1
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)

Comments

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-04-06 12:53
    Thanks for that, Peter. Your observation makes perfect sense. (I don't believe I've ever used wz with those instructions, though.)

    -Phil
  • RaymanRayman Posts: 13,767
    edited 2012-04-06 13:16
    Does this mean that the Z flag tells you something about the previous contents of the wrlong/word/byte target?
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-04-06 13:26
    I took it to mean that it applies to the value written.

    -Phil
  • RaymanRayman Posts: 13,767
    edited 2012-04-06 13:34
    Ok, that makes more sense (unfortunately).
  • pjvpjv Posts: 1,903
    edited 2012-04-06 13:40
    Rayman;

    What Phil said is my observation. The previous manual sort of said "Z = test of RESULT"

    Cheers,

    Peter (pjv)
  • Cluso99Cluso99 Posts: 18,066
    edited 2012-04-06 20:47
    IIRC the P2 will be using the wz and wc on the hub writes for different options of the instruction.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-04-06 21:46
    If I were to guess how the manual got screwed up, it would be this scenario:

    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
  • kuronekokuroneko Posts: 3,623
    edited 2012-04-06 21:57
    ... what happens when the destination addresses are misaligned with the data types being written?
    FWIW, the alignment has no effect on the Z flag behaviour. There is also an outstanding ticket (first birthday in May) mentioning this. Admittedly in a report re: timing info so maybe it simply got overlooked.
  • pjvpjv Posts: 1,903
    edited 2012-04-06 22:56
    Hi;

    @ 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)
  • kuronekokuroneko Posts: 3,623
    edited 2012-04-07 01:09
    pjv wrote: »
    @ 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.
    It wasn't a forum post. Parallax Semiconductor has a support portal. Over there I have an open ticket originally created to get the timing info updated. While I was at it I added some more info re: missing flag info. Unfortunately this didn't make it into the last update.
Sign In or Register to comment.