Good news! Philipp Klaus Krause just informed me that using the later snapshot builds allows the use of the command line parameter:
--allow-undocumented-instructions
and it works. I just found my generated asm having iyh and iyl.
As for what is supported I quote:
SDCC will use any undocumented instruction that is an official instruction in the eZ80 to access iyl and iyh.
sdasz80 / inline asm allow more.
Note: Official 4.2 is not recent enough.
What a timing! I just added Pletter support to MSXgl yesterday and ran into the problem of undocumented instruction support.
In the code, I replaced these instructions by their equivalent in raw data, but I left them as comments... just in case. ^^
Even if I personally won't use undocumented instructions, it is still useful to include third party code.
I hope they will add a pragma to enable this option only on some source code.
@Bengalack I can't found information about how to use undocumented instructions with SDCC.
I guess --allow-undocumented-instructions
is a command line parameter for SDCC and concerns the assembly code generated from the C sources.
However, I did not find how to use it with sdasz80 and/or with the inline assembler.
.z80 .allow_undocumented
...generates an error.
PS: I got the last snapshot (build 13495).
I had the same problem, if you use .z180 instead of .z80 it does work.
I use .allow_undocumented
(only) in the asm-file with sdasz80 without problems. But for c-code, I use the command-line-parameter (and "-mz80
"). I guess the functionality is so new, it didn't reach the documentation yet.
I guess --allow-undocumented-instructions is a command line parameter for SDCC and concerns the assembly code generated from the C sources.
It would be weird if it were otherwise. And in the parts in assembler, SDCC should just tell us that we are using undocumented instructions.
With the last SDCC snapshot, I got an error (Error: .org in REL area or directive / mnemonic error
) even if I use only .allow_undocumented
... :-/
Use the command line option
Command line option is for the C compiler (my assembler code is assembled with sdasz80).
For now, I converted the unsupported opcode to binary data.
In the assembler .z180 should work