[llvm-dev] Question about target instruction optimization

Bruce Hoult via llvm-dev llvm-dev at lists.llvm.org
Wed Jul 25 15:59:10 PDT 2018


On Wed, Jul 25, 2018 at 3:21 PM, Michael Stellmann <
Michael.Stellmann at gmx.net> wrote:

> Regarding the heavily overlapped register structure and the asymmetric
> instruction set of the Z80, would you recommend to try mapping more
> instructions in the form of generic pseudos that expand to multiple
> instructions during legalisation (leading to more custom lowering code), or
> try to map as many instructions and variations according to the allowed /
> limited operators as possible in a 1:1 way, leading to simpler lowering
> code (not sure if I am using the right words here)?
>

I don't know. It's going to be tough.

The register structure and especially the overlaying is very close to the
8086/386, so you can probably get some ideas there. AF is related to AX
(AH/AL). The 8086 expands A to a full 16 bit accumulator and puts F
elsewhere, but there are instructions to copy AH to F and to copy F to AH!
BC, DE, and HL are a lot like BX, CX, and DX. IX and IY are I guess like SI
and DI except they're overlaid on top of HL. BP is extra on 8086.

The available instructions are a LOT more limited on Z80 though, especially
for memory addressing and 16 bit operations. That's going to be tough. SP
in particular is so crippled that I think you'll have to keep a copy of it
in IX or IY basically all the time so you can access variables in stack
slots using the (IX+n) addressing mode. You can copy HL, IX or IY to SP but
not vice-versa! But you can add SP to HL, IX or IY. If you tie up, say, IX
with a copy of the stack pointer all the time then you're going to be very
very short on other places to keep pointers.

The more I look at it, the harder I think z80 will be. I'd almost rather do
6502! At least there you just admit the registers are useless and use zero
page as registers -- and there are as many as you could ever want! The code
size is awful though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180725/98e85cac/attachment.html>


More information about the llvm-dev mailing list