[llvm-dev] Having trouble getting started on writing a WDC 65816 backend

[Tim Northover via llvm-dev]

On Fri, 12 Jul 2019 at 17:14, <me at s5.pm> wrote:
> What does this mean exactly? How does the WDC 65816 not have fungible registers, while other processors do?

The targets LLVM supports right now have at lest 8 roughly general
purpose registers that LLVM can put values in (most have more) and use
for different instructions.

Below that, LLVM starts to struggle. I've certainly seen compilation
failures when the number is artificially constrained for some reason
(certain kinds of inline assembly will do it), but I don't think
anyone is really sure of how big the problem is.

> > One idea is to use some of bank 0 as
> > a source of registers, maybe with a custom pass to promote things to
> > real registers where possible after the fact.
>
> How would I end up doing this? Do you mean bank 0 of the actual SNES ROM?

I believe the first 256 bytes of memory are directly accessible from
instructions, so part (or all) of that might be usable as pretend
registers. Now that I've looked it up the term is zero "page" rather
than "bank".

> The big five issues right now are:
> 1. Code and data cannot be split across a ROM bank
> 2. Code and data need to be properly addressed by the specifics mentioned in the SO post
> 3. The bank code should be in can't be specified by the code itself
> 4. The SNES starts executing instructions at $008000 (bank 0, rom$ 0)
> 5. Hardware addresses; SRAM, VRAM writing, etc.
>
> How would a linker solve these problems though?

The linker's job is to lay objects out in memory. That seems to cover
1 and 3-5 pretty directly. 2 sounds like an issue for the compiler.

> Would it be efficient then to implement a CodeModel for each Environment detailing where code/data and hardware addresses should be?

The CodeModel would determine how far apart things can be, which
affects the instructions the compiler must use to access distant
objects. The actual final location of objects is still a linker issue.

> Does another target have an example of needing an external assembler?

I think NVPTX might, but I'm not sure that needing an external
assembler is the critical point. Most targets are capable of invoking
an external assembler if you tell them to via "clang
-no-integrated-as" (usually it's GNU as). To make a target "need" one
you just don't bother implementing the assembler bits
(MCTargetDesc/XYZMCCodeEmitter.cpp principally).

Cheers.

Tim.