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

yea BDD is a curious as I, as i recall that one mention in the thread about C compilers around a year ago followed by absolute radio silence.
obviously you don't owe us any kind of updates, but it would be nice to hear about how things are going from time to time...
(though i guess you did give an update in the other thread already, good to see the project wasn't forgotten and is still on track)

speaking of your update, you mentioned a test suite that you're using, is that available somewhere online? i would love to have something to test my own backend with.
and on another note, is PIC (Position Independent Code) planned as an option in any way? or atleast the o65 object format so you can relocate code at runtime?
i kinda need this sort of functionality for a microkernel-looking project of mine

Ok. I think I just mentioned that once and I did not think anybody had noticed, much less remembered after a year.


It is not public, but you can mail me and we can check if it might be helpful for you.


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? That is fine for a 68k, and even a 6809 can do it reasonably easy. But at first glance that seems to require much more overhead and additional work for 6502/65816. I would guess that relocation is probably a better choice there.


AFAIK vlink already supports the o65 format, so you should be able to create o65 output by just using the appropriate linker options.

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!


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:

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.

Don't get your hopes up too much. vbcc is likely much too big to run natively on a 16bit system.

There are of course function pointers.

How to obtain the segment address is probably not the big issue, but - as you mention - the overhead of indirect accesses can be pretty substantial. It will also require some non-trivial additions to the backend. We do support this for the 6809 (OS9 uses it) and there are quite a number of special cases even though the 6809 has an additional register that can be used as data pointer. Maybe I will have a look at it in the future, but it will probably not be high on the priority list.

Now that this has come up... what about lib6502 as target?
It's a library already defined in an OS agnostic way.

http://www.6502.org/users/andre/lib6502/index.html

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

I had a short look at the page, but I am not sure I quite understand. Is this a library implementation (if yes, where?) or just a specification?

my expectations are that it will release in a functional state within my lifetime. so i think i should be fine


i tried compiling my sw32vm backend with Calypsi C and yea, VBCC expects ints to be atleast 32-bits wide.
but then again sw32vm is 32-bits. so assuming that the 65816 backend can be optimized and shrunken down in size to fit with ~1MB of code and data, then it could in theory work... even if it were really damn slow due to running through a bytecode VM.


i took a look at the format specs and noticed that v1.3 doesn't support the 65816 in native mode. only v2 does which is apparently just a draft despite looking fairly finished and being 20 years old at this point.
this makes me wonder which version of o65 current assemblers/linkers use for the 65816.

ok after writing that last part i checked what the cc65 suite would do when told to output a 65816 specific o65 file. and answer is v1.3. it sets the word size to 32-bits but specifies that the CPU is a 6502 core (CPU = 0, CPU2 = 0000). besides that everything else seems correct, it handles the bank addresses just fine.
honestly the CPU bits being wrong seem more like an oversight to me than anything else.

It's a spec, and as far as I know there are two implementations:
1. My GeckOS one here https://github.com/fachat/GeckOS-V2/tree/master/lib6502
2. Lunix is supposed to use it too - although in source compatibility only

André

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

Indeed the CPU bits are not that well thought out. I wasn't aware of these intricacies and didn't have experience with 65816 native mode. Now it's difficult to maneuver out of this.

I believe though there is a 65816 header bit, separate from the CPU type bit field - not sure why cc65 doesn't set it. Maybe we need to file a bug.

André

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

Well..most people on this forum seem to emphasize how old they are, so...
It is the part about a 65816-native vbcc that I was addressing.


Using a VM that removes some of the 65816 limitations could get you there, this is true. However, 1MB is probably not enough.


From looking at the code in vasm and vlink, it seems that bit 15 in the mode word in the header is set for 65816. Otherwise bits 4-7 seem to be set according to the 6502-variant.

My BCPL system uses a bytecode VM. Yes, it's slow but it removes all the '816 limitations and gives you a 32-bit VM with linear addressing. But it's not really that slow - faster than BBC Basic but nowhere near as fast as native code. The upside is code density. The BCPL compiler is about 48KB and runs well in 512KB of RAM.

I have thought of re-targeting a C compiler to that bytecode, but time+effort renders it a bit out of reach for now.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

So that would mean to add a target for GeckOS and/or Lunix. I'll have to have a look at them, but no promises for the moment.