Hi all,

I've been experimenting with a skunkworks port of the LLVM tools to the 65xx. I'm at the point where I need to choose standard relocation types for the compiler and linker. LLVM clearly prefers ELF style executables and libraries, and I'm able to emit compiled assembly code plus fixups now.

One thing that's still currently up in the air, is a canonical set of ELF relocation types for the 65xx series. As arbitrary choices sometimes get set in stone, I figured I'd poll for a sanity check instead of declaring them unilaterally.

EDIT 2021.09.13: A version of this specification is viewable at:

https://llvm-mos.org/wiki/ELF_specification

Comments and improvements are solicited.

Welcome! A good idea all round, I think, and good to have read up on previous work.

The only thing I can think of is stack addressing - not sure if that's a different case
TSX
LDA 01xx, X
It's an absolute two byte address, not a relocatable two byte address.

Actually, sometimes the same thing will happen with zero page: for some reason code might use a two byte address to refer to zero page.

André's o65 format is the only one of which I'm aware. It's well thought out and were I seeking to build relocatable 65xx binaries o65 is what I would likely implement.

That said, neither the 6502 or 65C02 is particularly well-suited to this sort of thing. The number one problem is the 65xx instruction set is really geared to fixed addressing—the 6502 was not really conceived as a general-purpose microprocessor. Complicating matters, of course, is the stack being hard-wired to page 1 and the heavy dependence on zero page for indirection. It's not impossible, of course, but very tricky to implement well.

The 65C816 is substantially better suited for this sort of thing due to its movable zero page (aka direct page), 16-bit stack pointer and availability of more flexible addressing modes (e.g., stack relative).

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I have also been frustrated by the relocation types in the ELF format. It appears there are different sets for each processor type and they are not well documented without having to find source code which has to deal with it.

I am avoiding things like o65 and x86 OMF out of fear they may not be well suited for other processors.



I get the distinct impression he is looking for a linkable file format and not a relocatable binary image.

In my linker I export the required expression wrapped in an element that determines the target size. It lets you do some interesting things:

assembles into (my object code format is XML)

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Perhaps I wasn't entirely clear in my original post... Although this work may have future applications to dynamic loaders, and relocations on loading and such, I'm really just focusing on extending the ELF format sufficiently to encompass all the kinds of fixups that would happen during ordinary linking of 65xx executables. ELF provides a great deal of flexibility for a target to declare its own relocation types. A short overview of ELF relocation types for x64 and x86 is at https://intezer.com/blog/elf/executable-and-linkable-format-101-part-3-relocations/.

At this particular moment, I'm not intending to create another 6502 dynamic loadable format. This could certainly be done at some point, but I'm merely trying to extend ELF .lib and .o formats to encompass all the types of relocations that would normally be necessary, during LLVM compilation and linking of MOS targets. I'm sure that other authors here have thought through all the possible fixup types in their own linkers. Thoughts?

Thanks for the use case. LLVM seems to have support for complicated expression types built in: https://llvm.org/doxygen/classllvm_1_1MCExpr.html So it seems to me that LLVM should be able to handle complex linker expressions already, and I don't personally have to do anything special to support it.

You probably already know that LLVM uses gas as an assembly format. I've extended LLVM to understand that $ is a hex prefix, as so much existing 6502 code depends on that convention. The more modern 0x convention works as well, just because that's what LLVM does anyway.

Absolutely. I think you can appreciate my concern about checking with the community, before I run off and implement Yet Another Relocation Convention. Whichever one we go with, I'll make sure it is sanely documented somewhere.



Agreed. ELF contains a superset of information contained in those formats, and it might be possible at some point to write an elf2o65 converter; but premature optimization is still the root of all evil.



BillG, you are entirely correct. The linkable file format that LLVM prefers, is good old ELF. ELF must be extended per platform to support exactly the types of fixups that can exist for that particular platform, during normal linking; but everyone seems to write these relocations without consulting anyone else, or documenting their work.

I've been working on an assembler that currently outputs ELF as one of its output formats. I do intend to implementing linking as well, but currently it only outputs a .o file. One of my next steps is relocations, so I could use the same constants that you define. Eventually I'll probably also need a relocating loader. Potentially I could use the llvm linker instead?

So far readelf is able to read my output file and make sense of it. My next step was adding relocations but I haven't started that yet.

I wasn't too concerned with ELF compatibility as I didn't think that there was anything else out there to be compatible with, but I've been using the linux tools for testing, readelf etc. and it's quite helpful to maintain ELF compatibility so that these tools can be used.

ELF doesn't have standard constants for 6502, 65816 etc. as far as I could find. It would be good to document these too so that everyone uses the same values. I've made my own up currently, below is what I have been using.

The machine architecture. This is problematic for standard ELF as I started the numbering again, so these values would need to change if we had any sort of standard:



I have these (future) OS definitions. If there was such a thing as standard calling conventions we could use these constants to identify the calling convention standards.



I've started work on relocations, it looks like you have all the values covered for 6502 up to 65816 for simple cases. There could be more if, for example, you allowed for linking Program Counter Relative Long values across code modules. But we probably don't need that sort of complexity.

I have used Direct Page as a name in my code instead of Zero Page as it's more generalised. If you are working on 6502 output for llvm then targeting the 65C816 would be worthwhile as well as it should generate significantly better code.

Hmm, if you're defining e_machine then I think those values are not compatible with the current ELF standard. My understanding is that there should be a single value for everything under the MOS umbrella (EM_MOS, let's say) and there should be architecture-specific e_flags values for each of the various instruction sets. So, for example, there should be exactly one e_machine value for everything related to MOS (shall we say 6502?), and there should be e_flags that look something like:



Here is how I'm currently doing it: https://github.com/johnwbyrd/llvm-mos/blob/mos/master/llvm/include/llvm/BinaryFormat/ELF.h



I do have some ideas about how a calling convention will behave with LLVM, but of course nothing is set in stone. Please feel free to review and comment on https://github.com/johnwbyrd/llvm-mos/wiki/To-do, specifically the Calling Convention section.



I'm not sure how an eabi even makes sense for 6502. I'm not aware of an "OS 16", are you? It's not like it's Linux versus Win32 out there for 6502. I suggest just using eabi-none, unless you can think of a compelling reason not to.



At the moment I'm simply referring to it as 8-bit addressing. "Direct page" to me implies that the other 16 bit memory addresses are accessed indirectly, and indirect addressing has another meaning on the 65xx.

I certainly want to leave the door open to '816 compatible output in the future, so yes, we might as well get those constants solidified early on.

PC-relative addressing probably should be added.

I am not sure whether additional relocations might be useful for non-base models of the 6502 series.

With respect to sub-models of the 65xx family, I think there are three major generations of the architecture, with some degree of upward compatibility.

1: The NMOS 6502. Supports the common minimum instruction set. Also supports some extended, "undocumented" opcodes that do not exist on later models. There are some bugs which a compiler and/or linker needs to be aware of and avoid.

2: The CMOS 6502. Supports an improved instruction set and fixes most of the noticeable bugs in the NMOS design. There are two common extensions to this architecture model which are unlikely to be used by compilers: the Rockwell instructions and the WDC WAI/STP instructions.

3: The 65816. As a compiler target, this is a very different animal from the earlier CPUs, with much more flexible addressing modes and better support for 16-bit operations. Is incompatible with the Rockwell instruction set extension, but usually implements WDC WAI/STP. Technically upwards compatible with earlier models, but only in Emulation mode; most systems will however run in Native mode.

There are also some very rare variants, which are not useful to write a compiler backend for.

So an e_flags field might look like this:

D'oh! Of course, thank you very much.

color=#000000]
Just to be clear, the "Rockwell instructions" (BBR, SMB, etc.) were backported into the core 65C02 design by WDC shortly after conception (it's a not-uncommon misconception the 65C02 was a Rockwell design—Rockwell was licensed by WDC to produce the 'C02). It is extremely unlikely one will encounter a 65C02 that doesn't have them.

That said, and as often noted, BBR, SMB and the like are limited in value, generally not being of much use unless device registers appear in zero page. If I were designing a 65C02 compiler I would ignore those instructions, since the more flexible TRB and TSB instructions can do what BBR, BBS, RMB and SMB do.[/color]

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!