Ok. I think I just mentioned that once and I did not think anybody had noticed, much less remembered after a year.
you underestimate how desperately i want an open source compiler for this chip that could potentially build itself which would give us a native 65816 C compiler!
First, are we talking 6502 or 65816 here? So far I have not really looked into it for those targets. I think they are not very well suited for that. As you mention a microkernel, I have the feeling you do not need only position-independent code, but also data and/or constants, right
65816, and IMO it is very much suited for PIC. (with the limitation that Code never exceeds a 64kB Bank)
and yea the name is a bit weird as "PIC" usually refers to both position independent code and data.
for code it's fairly easy, replace
JMP with
BRL and
JSR with a macro called
BSR (branch subroutine) which i have defined as such in my SBC's include file:
Code: Select all
.macro BSR addr
PER :+ - 1 ; Pushes the Address to the last byte of the BRL instruction to the stack
BRL addr
:
.endmacro
indirect versions of
BRL/
BSR can also be done via macros but i don't know if your backend makes use of Indirect jumps in the first place (probably for long switch statements?)
anyways, for data it's more complicated. every data section (rodata, data, bss) could be loaded to anywhere in memory so unlike code it's pretty much impossible to figure out the addresses at runtime. and i think there are 2 ways that could be solved.
1. force users to load the entire program as one blob into memory, one segment after another. that way the program can know where everything is relative to the code and use
PER and indirect addressing modes to access data at runtime.
2. have the system's ROM/OS deal with it, idea being that the backend reserves some space on the stack or the direct page to store each segment's starting address, and the startup code (written by the user) has to fill those in before main() starts execution. how that is done exactly is up to the user so the backend doesn't have to worry about that, and only has to work similar to 1. using those specific variables plus indirect addressing modes to access data at runtime.
Either way it's quite a lot more overhead (though i think 2. would be simplier to implement and less limiting) and both absolute and absolute long addressing modes will be basically useless (except for accessing hardwired addresses like IO).
so it's your call if you want to be able to support something like this or if you say o65 is enough for relocatable executables and it's not worth the effort toi support PIC directly.
