a pipeline is needed covering shift and rotate operations. https://libre-soc.org/openpower/isa/fixedshift/ * OP_EXTSWSLI - done * OP_SHL - done * OP_SHR - done * OP_RLC - done * OP_RLCL - done * OP_RLCR - done
examining the shift operations, they generate CR0, and optionally the Arithmetic ones will set CA and also read carry in. do the Arith Shift also set the overflow flag? microwatt does not have OV set, which tends to suggest that we can drop XER.SO from the output regspec for this pipeline.
done, here, recorded the commit in case it needs to be reverted. commit e8e10da8650ff797faaad320fbd8b442a4bc4f0e (HEAD -> master, origin/master) Author: Luke Kenneth Casson Leighton <lkcl@lkcl.net> Date: Fri May 22 20:06:41 2020 +0100 remove sticky overflow from Shift Rot pipeline
ha, hilarious. took a while to notice: M-Form is this: rlwnm RA,RS,RB,MB,ME (Rc=0) where XO-Form is this: divdeu RT,RA,RB however, underneath, the 2nd argument is *consistently a constant*. this needs to be swapped in the CSV file. see issue #360
michael, i need your help, here: sraw "works" in shift_rot/test_pipe_caller.py only because carry isn't being checked in the test. i'm not sure if it's being set in the simulator? * sraw RA,RS,RB (Rc=0) * sraw. RA,RS,RB (Rc=1) n <- (RB)[59:63] r <- ROTL32((RS)[32:63], 64-n) if (RB)[58] = 0 then m <- MASK(n+32, 63) else m <- [0]*64 s <- (RS)[32] RA <- r&m | ([s]*64)& ¬m carry <- s & ((r&¬m)[32:63] != 0) CA <- carry CA32 <- carry Special Registers Altered: CA CA32 CR0 (if Rc=1) * srawi RA,RS,SH (Rc=0) * srawi. RA,RS,SH (Rc=1) n <- SH r <- ROTL32((RS)[32:63], 64-n) m <- MASK(n+32, 63) s <- (RS)[32] RA <- r&m | ([s]*64)& ¬m carry <- s & ((r&¬m)[32:63] != 0) CA <- carry CA32 <- carry Special Registers Altered: CA CA32 CR0 (if Rc=1)
(In reply to Luke Kenneth Casson Leighton from comment #4) > michael, i need your help, here: sraw "works" in > shift_rot/test_pipe_caller.py > only because carry isn't being checked in the test. i'm not sure if it's > being set in the simulator? > s <- (RS)[32] > RA <- r&m | ([s]*64)& ¬m > carry <- s & ((r&¬m)[32:63] != 0) > CA <- carry > CA32 <- carry > > Special Registers Altered: > > CA CA32 > CR0 (if Rc=1) Hmm. So the way carry gets set currently in test_pipe_caller.py is that it completely ignores modifications to the carry flag from the pseudocode and instead updates it based on the inputs and outputs. This is because for the arithmetic instructions (add/sub with carry), they don't actually set the carry flag in the pseudocode. However, it seems that the shift instructions do have pseudocode explicitly setting CA and CA32. I think parser.py should do something to instruction_info to tell caller.py to use the carry flag from the instruction globals and not generate one from the inputs and outputs. What would be the best way of going about this, does it fit with one of the existing fields?
(In reply to Michael Nolan from comment #5) > carry flag in the pseudocode. However, it seems that the shift instructions > do have pseudocode explicitly setting CA and CA32. I think parser.py should > do something to instruction_info to tell caller.py to use the carry flag > from the instruction globals and not generate one from the inputs and > outputs. What would be the best way of going about this, does it fit with > one of the existing fields? it appears to be a special case, just for sraw etc. i would be inclined to suggest allowing CA and CA32 to be picked up as output parameters then if spotted in the outputs the values put into corresponding XER fields. otherwise we need to do some messing about. although... when i looked at the pseudicode it looked very much like it was simply doing 32 bit carry i.e. bit 31 was detected as sign then 32 and above nonzero is "carry".
sradi is different carry <- s & ((r& ¬m) != 0) CA <- carry CA32 <- carry best add CA and CA32 to the fields that can be returned.
(In reply to Luke Kenneth Casson Leighton from comment #7) > sradi is different > > carry <- s & ((r& ¬m) != 0) CA <- carry CA32 <- carry > > best add CA and CA32 to the fields that can be returned. sorted. it's a bit of a mess, had to special-case it, but it's functional. also noted that rotator.vhdl has changed (support for OP_EXTSWSLI which i may add next)
(In reply to Luke Kenneth Casson Leighton from comment #8) > also noted that rotator.vhdl has changed (support for OP_EXTSWSLI > which i may add next) done in rotator.py should just need calling (setting the mode) from main_stage.py
(In reply to Luke Kenneth Casson Leighton from comment #9) > done in rotator.py should just need calling (setting the mode) from > main_stage.py done. found and reported bugs in V3.0B specification regarding sh. http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2020-July/008549.html