#3825 some Z80N sdasz80 failures

[Janko Stamenović]

Testing sdasz80 for how Z80N codes are generated, I've observed:

1) ldws is not implemented, an error is reported.
2) using mirror without parameters crashes the assembler (mirror a is OK)
3) there's an implementation of mirror de which doesn't exist in Z80N anymore
4) ldirscale doesn't exist anymore

Removing 3 and 4 won't have any impact. I expect that I can very easily fix both 1) and 2) and that fixing them will also have no impact to the existing regression tests (as they are clearly not used by them). I can submit one patch for all 4 soon, it shouldn't be hard.

[Janko Stamenović]

as a reference, this source contains all the Z80N codes that exist now, and it hasn't changed since 2019:

https://github.com/z00m128/sjasmplus/blob/master/tests/z80n/op_zx_spectrum_next_2_00_26.asm

[Janko Stamenović]

This fixes all 4 issues:

Index: sdas/asz80/z80mch.c
===================================================================
--- sdas/asz80/z80mch.c (revision 15242)
+++ sdas/asz80/z80mch.c (working copy)
@@ -1712,17 +1712,12 @@
                 break;

         case X_ZXN_MIRROR:

-                t1 = addr(&e1);
-                if (t1 == S_R8 && e1.e_addr == A) {
+                t1 = more() ? addr(&e1) : 0;
+                if (!t1 || (t1 == S_R8 && e1.e_addr == A )) {
                         outab(0xED);
                         outab(0x24);
                         break;
                 }
-                if (t1 == S_R16 && e1.e_addr == DE) {
-                        outab(0xED);
-                        outab(0x26);
-                        break;
-                }
                 aerr();
                 break;

Index: sdas/asz80/z80pst.c
===================================================================
--- sdas/asz80/z80pst.c (revision 15242)
+++ sdas/asz80/z80pst.c (working copy)
@@ -279,8 +279,8 @@
     {   NULL,   "ldirx",        X_ZXN_INH2,     0,      0xB4    },
     {   NULL,   "lddx",         X_ZXN_INH2,     0,      0xAC    },
     {   NULL,   "lddrx",        X_ZXN_INH2,     0,      0xBC    },

-    {   NULL,   "ldirscale",    X_ZXN_INH2,     0,      0xB6    },
     {   NULL,   "ldpirx",       X_ZXN_INH2,     0,      0xB7    },
+    {   NULL,   "ldws",         X_ZXN_INH2,     0,      0xA5    },
     {   NULL,   "mirror",       X_ZXN_MIRROR,   0,      0       },
     {   NULL,   "nextreg",      X_ZXN_NEXTREG,  0,      0       },
     {   NULL,   "pixeldn",      X_ZXN_INH2,     0,      0x93    },

Attached in the .zip: this .diff and the .asm from the previous link adapted to sdasz80 syntax.

Edit: updated to use 0xA5 constant (and not 0xa5), consistent to all other capitalized.

[Janko Stamenović]

Attached: a script to test the encodings from testallz80n.asm from the previous.

[Philipp Klaus Krause]

Looks okay to me (though I'd suggest to make mirror without an operand give an aerr()-error instead of silently giving it the semantics of mirror a, since there is another Z80-derivative that has a mirror r-like instruction, but I do not have a strong opinion on this).

[Janko Stamenović]

I've kept it only because, if I understand, that other assembler accepts it without the explicit A and using that example source induced the crash where I started too look for the cause. I also understood that sdasz80 has these modes, i.e. .zxnand my understanding is that it's only the handling of X_ZXN_MIRROR that I've impacted. If that helps SDCC elsewhere I can definitely put that explicit requirement of an operand.

Edit: I also haven't studied the exact cause of the crash: why exactly mirror without a parameter crashed and some other instructions also don't check more before they use similar constructs, even if the syntax is practically AFAIK == what that machine function implements.

[Philipp Klaus Krause]

So I suggest to leave out the part about mirror for now, and only put the changes for the other instructions into the next branch (or trunk after the SDCC 4.5.0 release).

[Janko Stamenović]

I fully agree. The only change that a potential user could see in 4.5.0 (minus the Win x64 crash which is anyway much less specific, now I understand that) would be an absence of ldws but that never prevented any hypothetical use case because it can be implemented with an assembler macro too.

[Philipp Klaus Krause]

I still see an error trying to use ldws in current trunk.