Closed guerinoni closed 1 year ago
Since we moved the
shift
logic to a new function, we lose the fact that before the code was modifying thecarry
variable and later changing it in the cpu. Now theshift
function doesn't change the carry, thus theshift_operand
function doesn't updates thecarry
bit in the cpsr, since it only uses theresult
field of the returned value fromshift
I'm not sure about using
ArithmeticOpResult
here since it contains fields we would never use in such a context. The idea behind this struct was to carry the "new state" of an ALU operation (add/sub). Maybe we can rethink it? Maybe we could make it more "modular"
Ok now I re-designed a little bit and seems correct to me! Obviously the refactor will be nicer when all operation will be split as I did for shift
... But meanwhile... :)
Base: 56.26% // Head: 56.32% // Increases project coverage by +0.05%
:tada:
Coverage data is based on head (
92ce57e
) compared to base (d94b038
). Patch coverage: 43.47% of modified lines in pull request are covered.
:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
ShifKind
for u32/u16 conversionArithmeticOpResult
into alu_instruction moduleLSL
for shift register