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).
Meh. It would not surprise me if notch fails to consult this "standards committee" when he finally communicates how this CPU will interface with game components.
Maybe the current drafts are flawed (e.g. I don't see a point for a file system draft at the moment), and maybe the people aren't the best, but the point is that we need to communicate and collaborate. I know we all like to say "why should these guys decide?", but if we want to be able to use libraries from different assemblers we need some standards/drafts.
And it's not really a "committee". Anyone can join the discussion. If the "committee" fails to understand your point, you are free to follow your own standards. If lots of people are unsatisfied, someone will fork it.
Just remember to communicate before you write lots of code/libraries/tools that only work with your own standard.
> but the point is that we need to communicate and collaborate.
You are missing the point.
>> It would not surprise me if notch fails to consult this "standards committee" when he finally communicates how this CPU will interface with game components.
> I know we all like to say "why should these guys decide?"
Except that in this case these guys shouldn't really disillusion themselves in thinking they are deciding. It's not their call - it's an in-game CPU and the standards are going to be what the implementors find convenient. The odds of notch finding this standard favorable to my standards are about the same as him favoring my standards.
> The odds of notch finding this standard favorable to my standards are about the same as him favoring my standards.
Huh? Notch doesn't have to give a shit about these standard. He's writing the emulator (and memory-mapped I/O); we still need conventions on top (calling external libraries; linking libraries and so on).
> the standards are going to be what the implementors find convenient.
Yes, of course. All I'm saying is that instead of each assembler/compiler/linker using its own "most convenient convention" we can at least try to unify them. And someone needs to write down drafts.
There's also the "those who can, do, those who can't, form standards committees" angle. (Of course, this does not apply to real standards committees that are formalizing post-hoc standards. But folks who form a standards committee to tell everyone else how to do their freely offered work before a de-facto standard is even in place? Please.)
Standards based on real working implementations generally make better standards. I'm sure the github conventions will evolve to better reflect what works in the real world. If they don't everyone will just ignore them.
