

LLVM backend for DCPU-16 - codezero
https://github.com/krasin/llvm-dcpu16/

======
sp332
Just a suggestion: there's a lot of cool stuff going on with this project, and
it would be a shame if interested people missed out on it. At the same time,
posting every cool thing to HN could flood the front page for months :) So
let's move discussion of new implementations, assemblers, and disassemlers (at
least) to the DCPU subreddit? <http://www.reddit.com/r/dcpu16>

~~~
vyrotek
Thanks. I didn't know there was a subreddit for this.

Oh dear. DCPU emulation on DCPU?
[http://www.reddit.com/r/dcpu16/comments/rz6fd/dcpu_emulation...](http://www.reddit.com/r/dcpu16/comments/rz6fd/dcpu_emulation_on_dcpu/)

------
Zr40
I'm also working on a compiler targeting the DCPU-16. It doesn't compile C
code, instead there's a simple C-like language supporting modules and
pointers.

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>

------
judofyr
Too bad it doesn't follow the calling conventions proposed on #0x12-dev:
[https://github.com/0x10cStandardsCommittee/0x10c-Standards/b...](https://github.com/0x10cStandardsCommittee/0x10c-Standards/blob/master/ABI/Draft_ABI_1.txt)

~~~
krasin
(dcpu16 llvm backend developer here)

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.

~~~
viraptor
Great work :) I just spotted something in the compiled example and wonder if
this:

    
    
        SET  J, [4+C] ; The Notch order
        ADD  J, 1 ; The Notch order
        SET  [4+C], J ; The Notch order
    

Is not transformed to

    
    
        ADD  [4+C], 1
    

due to some assumptions in llvm, or do you not handle the literal values as
arguments yet?

~~~
krasin
It's just because the focus is now on generating valid assembly (there're tons
of bugs so far) and I have not paid any attention to optimization yet.

Thanks for reporting, tracked by issue <https://github.com/krasin/llvm-
dcpu16/issues/67>

------
RDeckard
Excuse the ignorance, but what is the big deal about DCPU-16?

~~~
Natsu
It's a toy CPU that's perfect for learning. It's about to be part of Notch's
new game (he created Minecraft). So it's a great combination of fun +
educational. Honestly, I'm surprised no one has made one of these CPUs in
Minecraft yet. I can guarantee that it's possible.

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.

~~~
i386
Post a video please :-)

~~~
Natsu
I'll do you one better and give you the whole world:

<http://www.mediafire.com/?6ywsyy18qhening>

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.

~~~
i386
Awesome! Can't wait to give it a go :)

~~~
Natsu
Let me know what you think :) There's a lot of stuff in there and you may see
that I'm a bit OCD about labeling things. I doubt most people have a sign
marking the bedroom. But everything else in the house has a sign, so...

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.

~~~
i386
FYI There is a bukkit plugin that allows you to duel the dragon as many times
as you want.

~~~
Natsu
Interesting. Might have to look that up sometime. Hope you've enjoyed my
world, even though I know it doesn't hold a candle to some of the fancy
creations out there.

But hey, I do have a collection of every single color of sheep, neatly sorted
into pens :)

------
colinmarc
Next up: compile a JVM and run the game within the game???

Joking aside, what are some scripting languages with tiny interpreters that
could feasibly compile eventually?

~~~
bitbckt
Forth, Lisp and BASIC immediately come to mind, and are period appropriate.

~~~
pjmlp
Turbo Pascal and C would also be quite cool, as they were heavily used in the
16bit days.

------
swdunlop
"Binary distribution for Linux x64 is available. (v0.0.2, 170MB)"

170MB to emulate and compile targeting a 128kb virtual machine. Funny how
things have bloated.

~~~
zoul
It’s a reasonable price for the convenient abstraction. What’s interesting is
the size of the binaries and the compression ratio of the whole thing (0.2):

    
    
        zoul@naima:llvm-dcpu16 $ du -sh *
         286M	bin
          13M	include
         522M	lib
          76K	share
    

What’s in the binaries so that they are so huge and compress so well?

~~~
viraptor
I'm tempted to point at various graph fragments and other cpu descriptions
which are partly auto-generated. It's a guess though, I'd like to know a real
answer too. Is is a high price to pay for a framework which allows people to
port compilers to a whole new architecture in a matter of days?

Also this binary may actually include all targets, not just dcpu16.

------
10098
This is so incredibly cool! But how did you implement I/O?

~~~
dalore
Certain memory areas correspond to the console. If you have a look at Notch's
Hello World example you see him putting letters in memory areas.

Now if this is how it will communicate with the rest of the ship, I don't
know.

~~~
richdougherty
A few days ago he was thinking of a message queue... not sure how it would
work though.

<http://twitter.com/#!/notch/status/187448370107912192>

~~~
viraptor
Since he wants to simulate the cpus all the time and there's no sleep / wait
which actually stops execution, tight wait loops shouldn't be an issue. Just
wait for some mmaped [msg_no_ptr] to be >0.

------
tkahn6
This is so cool! Just finished my implementation and it runs the fib example
flawlessly†!

<https://github.com/tkahn6/dcpu16-haskell/>

† 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.

~~~
carterschonwald
You can use a monad to thread the computation for strictness while retaining
purity.

