🚀 go-pugleaf

In article <1993Jan11.011528.17746@arbi.Informatik.Uni-Oldenburg.DE> Ingo.Wilken@arbi.informatik.uni-oldenburg.de (Ingo Wilken) writes:
>
>4001: MOV  0014, @0009 ------+
>....                         |
>4005: CMP #7767,  0005 <-+   |  Example of indirection...
>....                     |   |
>4010: DAT #0000, #7995 --+ <-+
>....
>4015: DAT #0000, #0000
>
>Seems ok so far.  Now, from my interpretation of the ICWS-88 text 
>("redcode-icws-88" from soda.berkeley.edu), the B-field of the first MOV 
>should be processed like this:
>Read the b-field of 4010 (=> 7995), add the PC (=> 11996), then modulo
>coresize (=> 3996).  Result: Copy the bomb from 4015 to 3996.
>
>But the simulator does something else, it copies the bomb to 4005!
>It seems that instead of adding the address of the current instruction (4001)
>it adds the address of the DAT (4010).

The simulator is correct and you are just misinterpreting the ICWS-88 text
(which is amazingly easy to do, imho).  It all comes down to this meaning:
For indirect operands, take the value of the indirect mode for the current
instruction and use it to fetch the instruction it is pointing to.  (i.e.
@9 means fetch the instruction that is PC+9 locations away).  With this
newly fetched instruction, uses its B-Field as an offset from *that*
location to fetch yet a newer instruction...

So, in the above example, the "4001: mov 14, @9" means that @9 points 
to 4001+9=4010 which is "4010: dat #0, #-5".  The #-5 is then used to
calculate the new offset from *that* location (i.e. 4010), which is
4010-5=4005 which is "4005: cmp #-233, 5".

Well, I hope this will help clarify things... Good luck!

Scott
-- 
         Scott W. Adkins           Internet: sadkins@ohiou.edu
         ~~~~~~~~~~~~~~~                     ak323@cleveland.freenet.edu
    Ohio University of Athens        Bitnet: adkins@ouaccvma.bitnet