RCL/RCR/ROL/ROR inconsistent with P1

Comments

• Electrodude Posts: 1,673

  2015-10-21 03:26

  This seems to be the new convention for the C flag on the P2. It happens for RCL/RCR, you earlier stated that it happens for NEGx, and I think I remember reading that it also happens on SHL/SHR. Why don't you just make one thread to deal with this rather than several?
  
  Someone who has an FPGA should file an inconsistency if they find an instruction that still exhibits the P1 behavior.
• potatohead Posts: 10,261

  2015-10-21 04:29

  FWIW, very early on the idea of being P1 compatable was tossed out. That discussion involved SPIN and PASM, and the idea was to maximize the next design and plan a little for the future.
  
  We probably need a general statement from Chip on this.
• jmg Posts: 15,193

  2015-10-21 04:33

  Seairth wrote: »

  P1
  C : first bit shifted out
  
  P2
  C : last bit shifted out

  
  Do you mean in cases of more than one-bit-shift ?
  I'd expect multiple bits to behave like a chain of RCLs, which would mean the last shifted bit is in C.
  
  
• Cluso99 Posts: 18,071

  2015-10-21 04:48

  Yes.
  
  In the P1 the spec states (in many of the instructions) that the C is set using the Source b[0] or b[31] depending on the instruction.
  
  On the P2, this was fixed to mean the last bit shifted/rotated out.
  
  Perhaps some instructions are using the Destination b[0] or b[31], which would also be a fixup from P1.
  
  Some instructions set C as odd parity in the Destination.
  
• Roy Eltham Posts: 3,000

  2015-10-21 06:27

  I really think it's fine to be inconsistent or incompatible with P1. These work more like the standard instructions across every other CPU/MCU.
  
  PASM will require porting from P1 to P2 no matter what, I think P2 should strive for the best options rather than be saddled with P1 compatibility.
  
  
• potatohead Posts: 10,261

  2015-10-21 06:49

  Yep, that's what we agreed on way back when this whole thing got started.
• Seairth Posts: 2,474

  2015-10-21 11:04

  I'm fine with it changing. I just want to make sure that it's an intended change. My unit tests are based on the P1 "concise truth tables", which is the only reason I'm encountering these issues. If we have new truth tables, no problem. I'll update and move on.
  
  This also makes me think that we need a table/grid that states these differences between P1/P2.
• Seairth Posts: 2,474

  2015-10-21 11:47

  Seairth wrote: »

  This also makes me think that we need a table/grid that states these differences between P1/P2.

  
  Started. You can find (and modify) the list at:
  
  https://docs.google.com/document/d/1O27nO2tMjBTvUNblFFRtEp5DHvcvsSGXcPvH9FaJ9u8/edit#bookmark=id.n1suwwbjxuk4