Unplanned behavior in Prop I? Carried over to Prop II?

Phil Pilgrim (PhiPi)

I realize that some of this is old news, but please bear with me...

The downloadable Propeller Manual v1.1 flags some "improvements" relative to the printed version. A lot of these changes have to do with flag behavior. For example, in the addabs instruction, the originally described behavior of the carry flag was, "If the WC effect is specified, the C flag is set (1) if the summation resulted in an unsigned carry (32-bit overflow)." This would be the expected, useful, and (I would guess) intended behavior. But that's not really what happens. In the v1.1 manual, there's a footnote: "If S is negative, C Result is the inverse of unsigned borrow (for D - S)." This makes the carry flag less useful and is (I would guess) unintended behavior.

Another example is the min instruction. In the original manual, the zero flag behavior was described thus: "If the WZ effect is specified, the Z flag is set (1) if Value1 and Value2 are equal." This would be very useful behavior. When scanning a table to locate the maximum value, it would give you the option of reporting either the first occurence of the maximum or the last occurence:

               [b]min[/b]       maxval,val [b]wc[/b],[b]wz[/b]
   [b] if_c_or_z[/b] [b]mov[/b]       lastmax,index           'Record the position of the last occurence.
  [b]if_c_and_nz[/b] [b]mov[/b]       firstmax,index          'Record the position of the first occurence.

But this isn't how the zero flag actually works. In the revised manual, it states, "If the WZ effect is specified, the Z flag is set (1) if Value2 is zero (0)." This seems much less useful and is (I would guess) not what was originally intended.

There are other, similarly-afflicted instructions. My gut feeling is that the original documentation described the way the instructions were supposed to work, but that things didn't turn out that way in the silicon. I don't mean this in any way to sound accusatory, like the chip wasn't tested adequately, for example. But something happened to create a disconnect between the originally-described and actual behaviors. And each instance may be nothing more than a miscommunication or simple typo.

So my questions are:

1. Were these and other similar behaviors unintended?

2. If so, will these behaviors be "corrected" in Prop II, or does precedent trump the original intent?

In any event, I would encourage anyone who hasn't already done so to download the v1.1 manual. It will save you lots of head-scratching and debugging time!

Thanks,
-Phil

Post Edited (Phil Pilgrim (PhiPi)) : 3/2/2010 8:40:35 PM GMT

Cluso99

Thanks Phil for bringing this to our attention.

If this was one of the few unintended features (in ms*** speak) it is pretty·impressive compared to the errata I have noted on some of the alternative chips from companies that have huge budgets !!!

While discussing flags....

It is probably too late for Prop II, but it would have been nice to have·the read/write and djnz/djz/tjnz/tjz instructions which currently do not set all flags,·set them·for possible extra use (unless they have been used to extend the instruction set). For example...···

                                      [b][u]     Z      [/u][/b]     [b][u]      C       [/u][/b]
[b][u][/u][/b] 
rdbyte/word/long[b][noparse][[/noparse]/quadlong][/b]          Result=0          [b]S[noparse][[/noparse]7]/S[noparse][[/noparse]15]/S[noparse][[/noparse]31]/S[noparse][[/noparse]127][/b]
wrbyte/word/long[b][noparse][[/noparse]/quadlong][/b]          [b]Result=0[/b]         [b]S[noparse][[/noparse]7]/S[noparse][[/noparse]15]/S[noparse][[/noparse]31]/S[noparse][[/noparse]127][/b]
 
djnz/[b]djz[/b]                              Result=0          Unsigned Borrow [b](or D[noparse][[/noparse]31])[/b]     [b]C=negative[/b]
tjnz/tjz                              Result=0 (D=0)     [b]D[noparse][[/noparse]31]                       C=negative[/b]
 

Particularly, we often use·read (rdlong)·to check for either 0 or negative. 0 indicates ok/free whereas negative indicates an error. This would save a compare instruction following the rdlong.·So C should be set if the msb is 1, otherwise cleared.·Write should be set the same.

djz is a new instruction which is in fact just a tjz with the nr bit clear. All djnz/djz/tjz/tjnz should set C if the msb is 1, else cleared. The djnz/djz instructions already set the C flag for unsigned borrow. However, this is in fact functionally identical to using the msb of the result. So all·4 instructions could be identical in setting flags.

I have noticed that waitpne and waitpeq use 2 opcodes. However, they could share 1 opcode with the z (as in zcri bits = wz) as the determination for waitpne/waitpeq as the z flag is not set as a result.

An additional instruction (pair)·that would be handy in the Interpreter and elsewhere would be for setting and saving flags ...

flags d,s wz, wc, nr  'move flags
 
The flags instruction would work similar to the movi/movd/movs instructions. 
 
Only bits 0 & 1 of the source and destination would be relevant.
 
The zero flag would only be used if wz was set and the carry flag would only be used if wc was set.
 
If nr was not specified, then the existing flags (as determined by wz & wc) would be written to bits 0 & 1 of the destination, and other bits of the destination would be unaffected. This means if only wz was specified, only the single bit in the destination would be modified.
 
If nr was specified, then the flags would be set according to wz & wc and bits 0 & 1 of the source. Source could be immediate or not depending on the i bit).
 
I am unsure if nr is not specified (save flags) whether it should also replace the flags (like a swap flags), or whether the nr should be used as either a set or save flags instruction.
 
I have not identified whether bit0 or bit1 should be the Z bit and the opposite the C bit. (need to check the interpreter).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz