That ABI is hard to implement in LLVM, mostly because of SP can't be addressed as [4+SP] in DCPU-16. So, DCPU16 LLVM backend uses C register as a frame pointer (to store local variables and other data) and SP as a stack pointer to store ret addresses.
There're other "flaws" in that ABI which increase the cost of developing an LLVM backend.
I am going to make the supported ABI closer to #0x12-dev ABI in v0.0.5 and report them the most annoying features of their ABI.
I don't think it makes any sense to follow any community-agreed guidelines until Notch finalizes his design.
Do you plan to make a short description of what exactly it took to create the backend?
I thought this would be an excellent excuse to learn about llvm, so been reading about its internals the past few days, and even though I realized that starting with MSP430 this would be relatively simple for someone who knows llvm, I am apparently too late to the party :) Nonetheless I would be interested in some overview.
Dude seriously this is awesome. Good work. DCPU-16 is perfect for learning about all these cool aspects of computer science. It's so stripped down (lacking, for example, instruction pipelining) that it's easy to get into and see what's going on at a very basic level. I look forward to looking over the repo later today (after I've slept).
That ABI is hard to implement in LLVM, mostly because of SP can't be addressed as [4+SP] in DCPU-16. So, DCPU16 LLVM backend uses C register as a frame pointer (to store local variables and other data) and SP as a stack pointer to store ret addresses.
There're other "flaws" in that ABI which increase the cost of developing an LLVM backend.
I am going to make the supported ABI closer to #0x12-dev ABI in v0.0.5 and report them the most annoying features of their ABI.