[P8X32A]: wrbyte wz

[konimaru]

This used to work, i.e. always works in test cases. Here it seems to depend on randomly inserted insn.

• I found the general issue (emulator Z flag not being set)
• wrbyte value, address wz with value == $xxxxxx00 should set the native Z flag
• current theory is memory corruption (behaves the same on two different h/w platforms, C3+QS)

[konimaru]

I placed a nop before and after a selected insn. The binary image stayed the same otherwise, i.e. no address references were affected. The only affected part was hub timing. Both images showed different behaviour (OK/NG).

This suggests interference from another cog doing hub ops.

[konimaru]

https://github.com/konimaru/modulity/tree/wrbyte-wz

[konimaru]

As a next step I tried to isolate the disturbance. The serial driver (running in parallel) does two rdlongs which fetch a non-zero value in byte lane 0 (last/first index). Creating a stand-alone code sequence shows the same behaviour. The serial driver is now started later (when everything is over) and the custom loop took its place.

By manipulating said loop I can make the emulator wrbyte wz call fail whenever I want (down to one non-zero read per hub window, i.e. always).

• validate the cogid distance (currently 1) distance doesn't matter
• figure out what's special about the emulator (standalone wrbyte wz seems to work)

[konimaru]

It's safe to say that the behaviour we want (see OP) is not guaranteed. The 6502 emulator code has been rewritten to cope with that (minimal overhead, a single long IIRC). All I can say right now is it's complicated.

[konimaru]

Time flies! Had another dig today and it jumped right into my face: if a cognew/coginit is in progress while the wrbyte wz is executed the Z flag remains zero (when it's expected to be set).

I chew on this a bit longer but I guess that's it.

[konimaru]

As already pointed out, a (manual) rdlong sequence has the same effect. Which ties in nicely with cognew & Co.

[konimaru]

current test case:

• archived state is showing a good result (wrbyte wz working)
• it includes 4 test cases (marked {TEST}) which - when activated - may affect the result
  • eins: cognew while emulator is running: NG
  • zwei: busy wrlong loop: OK
  • drei: busy cogid/rdlong loop: NG
  • vier: busy rdlong/cogid loop: OK

Note: if drei or vier are activated in combination with zwei the test result may be reversed (most likely timing). A busy rdlong loop will always be NG.

A good test result is indicated by the first printed 32bit hex value being of the form $000600??, a bad one will show $000400??.

wrbyte.wz - Archive [Date 2020.02.19 Time 07.49].zip

OK

NG

[Wuerfel21]

Hmm, something is up, can reproduce your test case failing.

Now here's a fun one: a much simpler test case where one can mess up everything at the price of uncommenting a single inconspicuously marked instruction
test_wrbyte_wz.zip