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

[via llvm-dev]

Sorry about the "Sent by Migadu" message at the bottom of these emails. I looked through settings but I don't know how to get rid of it.

July 10, 2019 1:29 PM, "Tim Northover" <t.p.northover at gmail.com> wrote:

> As I recall the big one is that LLVM isn't well adapted to instruction
> sets without fungible registers.

What does this mean exactly? How does the WDC 65816 not have fungible registers, while other processors do?

> 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?

>> <srnb> - How do I handle ROM banks? (
>> https://stackoverflow.com/questions/56925635/equivalent-of-org-in-llvm-ir )
>> <srnb> - Does it make sense to use `ENVIRONMENT` (where it's usually either `gnu` or `musl`) for
>> the different ROM types? (`lorom`, `hirom`, `sa1`, etc)
> 
> I think it could be made to work, but the physical start address would
> normally be handled by a linker. If you're trying to avoid a linker
> entirely, many hacks are possible.

I wouldn't mind a linker.

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 wider issue of different ROM banks (how pointers must be defined
> and accessed so that all possible values are in range) looks more like
> a CodeModel on other targets to me (with existing values of tiny,
> small, medium, ... but you could make your own if you don't like
> those).

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

> Most LLVM targets implement an assembler too so that they don't have
> to call out to an external program. But you don't have to do that, and
> if you want to start out using an external assembler then at some
> point you'll probably want to teach Clang how to invoke it properly
> (the alternative is telling your users they have to add lines to their
> build system to do it, which is also fine to begin with). I believe
> the key code is in clang/lib/Driver/ToolChains, for copy/paste
> purposes.

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

>> I'm using CLion on Windows with Msys2-mingw64 (my VoidLinux-musl installation isn't that great for
>> development yet). Importing the project works correctly, but I don't know how to build the project
>> or test the project or test my backend.
> 
> That I can't help you with I'm afraid. I get the impression most of us
> here use CMake/ninja directly to do builds (see
> https://llvm.org/docs/GettingStarted.html), and maybe an IDE to edit
> the source files. I certainly do.

The targets listed in CLion are the same ones that you can call in CMake or Make I'm fairly certain.

Sent via Migadu.com, world's easiest email hosting