#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..