Flag Updates

[mw92]

In writing the Programmers guide I have just realised there is somewhat random behaviour of flag updates when the instruction is not arithmetic. This is a result of datapath ALU still allowing updates for all instructions. Does the controller currently ignore the flags update when instruction is not arithmetic? Otherwise instruction listings may get confusing..

[seblovett]

Yes. It only updates the Status Register on an arithmetic function.

[mw92]

so instructions 1-12

[seblovett]

LSR
LSL
NOT
NAND
NOR
XOR
OR
AND
CMPI
CMP
SUC
SUCI
SUBIB
SUBI
NEG
ADCI
ADC
ADDIB
ADDI
ADD
LDF

[seblovett]

Edit to original statement - and logic function. Plus loading of flags.

[mw92]

I assume youve just forgotten to type SUB and ASR on that list. It may be better to keep to JUST arith and LDF since flags will be from result of Ra+(Rb/imm4) with the ALU as it is currently (flag calculation comes from output of FullAdder in arith section)

[mw92]

The alternative would be rewiring ALU to use internal bus to update N & Z correctly, but C and V would make no sense.

[seblovett]

Do the flags not work for logic operations then? We did decide that they would. Shifts make sense not to though.

[mw92]

The flags produce an output for any operation, I just did not consider them being used for anything other than arithmetic, I can probably adjust ALU with little change (1 rowcrosser? & rewire) to make N, Z valid for the ALU output of any instruction.

[seblovett]

We definitely had the discussion the logic operations should give valid flags. Few options here:

• Resynthesise controller
• Make ALU changes as outlined above
• Change the instruction set to reflect that only N and Z are valid for logic operations (incl shifts), N,C,V and Z for arithmetic. All other operations don't update status reg.

Latter is by far easiest, and I think is valid. Thoughts?

[mw92]

Third point is not true without the ALU changes

[seblovett]

What is the best way to go forward with this in your opinion?

[mw92]

Just done some rewiring in ALU to make z,n always correct as id did not require any change to the size. Passed simulation on datapath_stim and sim.py interrupt

[seblovett]

Okay, cheers. I'm guessing C and V won't be valid. Do we want to change the controller to not store these? I think a note saying that they aren't valid after a logic operation as having flags which represent two different results would be confusing.

[mw92]

Yeah make sure C,V only stored for arith as any other would make no sense..

[seblovett]

Well, if we say they aren't valid, then it doesn't matter if we store C and V on logic operations as they shouldn't be used. Means simpler control.

[mw92]

true but what if the programmer wants to later use some values he calculated earlier? Should always know what to expect in the registers

[seblovett]

Do a CMP. I don't think you will ever do ADD R2 R1 R0 AND R3 R4 R5 BLT .loop and expect that to jump on the ADD result. The status reg will be split, in this case which is more confusing. A CMP instruction would need to be done instead.

[mw92]

Well I dont have enough assembly experience to think of a situation where it might be done, im just tihnking it makes sense for predictable values. If you leave it updating though it must be included in part of programmer tips in the guide @ashleyjr

[seblovett]

I've been thinking, and I stand by my previous answer. You wouldn't use a C or V flag after a logic op. Never a split status reg either where half the flags are the previous arithmetic and half from the previous logic op. For simplicity, the status reg will be updated always, as the C and V flags shouldn't be used after logic ops. Guide should say that the valid flags for arithmetic ops are N V C and Z. Valid flags for logic operations are N and Z.

[mw92]

even if you cant think of a situation where it would be used in that way the output should still be predictable

[seblovett]

They should not be used. Therefore it doesn't matter what they are. In the ideal world - I agree.

[mw92]

ive just updated the guide so it now has UNPREDICTABLE for selective flag updates Not sure if return values are correct though..

[seblovett]

"Invalid" is a much better word.

[mw92]

if found unpredictable used in reference manuals for actual processors and better suggests what the value actually is

[seblovett]

Fine.