Oh dear. DCPU emulation on DCPU? http://www.reddit.com/r/dcpu16/comments/rz6fd/dcpu_emulation...
It's not really finished and can surely produce better code, but I wanted to share it anyway.
Here's the fib example from the LLVM backend's README: https://gist.github.com/2336867. My compiler currently manages to compile fib to 30 instructions (0x2E words) compared to 38 instructions (0x41 words) for the LLVM backend.
Here's the source: https://github.com/zr40/dcc
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.
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.
SET J, [4+C] ; The Notch order
ADD J, 1 ; The Notch order
SET [4+C], J ; The Notch order
ADD [4+C], 1
Thanks for reporting, tracked by issue https://github.com/krasin/llvm-dcpu16/issues/67
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.
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.
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.
In other words, this has a lot of people excited about a game that doesn't even exist yet. Oh, and given the popularity of Notch's games and the buzz for this one, I'm sure that a few people will manage to turn a tidy profit based on their fun. There are more than a few highly popular Minecraft websites, YouTube channels, etc. So there are a lot of things that appeal to hackers. It's a great toy system to play with, it's going to be an important part of an interesting game, etc.
Note that some people have already learned about electronics by building redstone circuits in Minecraft. It abstracts away everything but the logic, so it's a fun way to play with logic gates and whatnot to build something interesting. For example, I have a giant circuit hooked to a redstone clock to periodically flood the spawning pads of the gigantic mob grinder that covers my base camp and increase the number of items I get. It's enormous, but not particularly exceptional by Minecraft standards. It does help me produce a lot of TNT, though. I put a record player in the item collection room to pass the time.
Note that it's in the new format. I deleted the parts in the old format to make it smaller. The mob grinder is the huge thing in the sky. The items fall into a room in the upper level of the house.
If you're wondering, that railway leads to the dungeon with the end portal. The dragon is dead and his egg warped into the end portal back before I could collect it. Sorry about that. I'm not quite clear on whether I could just delete the region files for the end and make it all respawn, but I might want to try that some time.
There's also a fairly complete map of the area centered on the house in a chest upstairs at the end of the hall. And there are a few random outposts in dungeons. If you ever get lost, there should be lots of markers pointing the way home.
But hey, I do have a collection of every single color of sheep, neatly sorted into pens :)
It's not like there haven't been games with instruction sets before.
So what if it's not conceptually new? Why would people not be excited about a very good-looking entry to a fantastic genre?
I think it tickles some of the same interest points as Corewars, but a little less abstract and with a newly-galvanized and potentially larger community.
And others will find it evidence of the further sub-redditing of HN.
Joking aside, what are some scripting languages with tiny interpreters that could feasibly compile eventually?
170MB to emulate and compile targeting a 128kb virtual machine. Funny how things have bloated.
zoul@naima:llvm-dcpu16 $ du -sh *
Also this binary may actually include all targets, not just dcpu16.
Now if this is how it will communicate with the rest of the ship, I don't know.
† Because mine is a pure state machine and Haskell is lazy, I had to introduce a HLT instruction instead of using `:crash SET PC, crash`. Nothing ever gets printed using the latter convention.