#kothorg
[7:05:32]gwilliams : I found this tutorial series useful for expression parsing [7:08:30]digital.wilderness : Hi <@UC1ETD68K>. Did you see the post in r.g.c about having different results with `add.a {0,#0`?[7:09:31]gwilliams : No, I did not[7:12:31]digital.wilderness : I haven't checked it myself. The OP mixed up the results from pMARS / in the first post. It should say "If one tracks the A-field of the ADD.A in pMARS, it is set to 5. However, on e.g. it is 4 instead." [7:13:11]gwilliams : Interesting, I'll check it out[7:36:45]gwilliams : [11:51:43]gwilliams : Ok, I am baffled by this one :smile:
So the A operand is predecremented and the A source is the number 5 from the preceeding instruction
But shouldn't the A operand decrement be stored in core before executing the Add operation e.g. -1 + 5 = 4?
Otherwise where does the predecrement (-1) go, it just gets abandoned somehow?[13:02:43]digital.wilderness : There's lots of strange behaviour. E.g. the following instructions in pMARS (with a nop 5,5 before each):
`add.f <0,0` becomes `add.f <5,4` but
`add.f <0,#0` becomes `add.f <5, #5`
`add.f {0,0` becomes `add.f {4,5` but
`add.f {0,#0` becomes `add.f {5,#5`
The standard doesn't appear to be much help (especially since it was written before a-indirect addressing modes were added). I'll investigate later.[13:08:18]gwilliams : I think the difference in my implementation is that the core is updated after the a operand is evaluated and before the b operand is. I think I can probably replicate the pmars behaviour although it'll be a bit clunky. You're right the standards do not help much! [13:09:53]digital.wilderness : It looks like if the b-mode is #immediate it buffers the instruction before the a-operand is evaluated.[14:01:54]gwilliams : [14:02:17]gwilliams : I think I have a fix for it, won't be live for a bit though..