Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Notch's Specification for the In-Game DCPU-16

0x10c.com

Post reply on HN
Print view View original

141–150 of 177 posts

Re: Notch's Specification for the In-Game DCPU-16

#141

Post by asdfaoeu »

ealloc wrote: post #60
TomFrost wrote: post #3

Earlier quoted context omitted.

> * Word-addressed memory will make string processing interesting to implement. Maybe in space, everyone uses UTF-16. Everyone in Minecraft, too -- almost. The string encoding in Minecraft's protocol spec is UCS-2, just a sneeze away from UTF-16. It seems Notch has a soft-spot for large encodings. It makes sense from a calculation and lookup perspective, but I wonder if the increased bandwidth and storage of 16-bit b…

By going UTF-16, he would make the game much more accessible to those not using a latin alphabet. If I was designing the game, I would favor internationalization vs space efficiency in the virtual computer. That way russian kids would get to have fun learning to write silly programs too.

UTF-8 still has all the characters UTF-16 does it just uses more bytes to encode them. UTF-8 makes more sense if most of your characters can be represented in 8 bits.

Re: Notch's Specification for the In-Game DCPU-16

#142

Post by duaneb »

Zaak wrote: post #133
duaneb wrote: post #50

I'd be interested to see details on memory protection. Self-modifying code means evolutionary programming, which I am very much for. Conditional branching is strange.

I very much hope there will be some kind of memory protection mechanism. Virtual memory would enable wonderful things.

On the other hand, if there is no protected memory.... code wars abound!

Re: Notch's Specification for the In-Game DCPU-16

#143

Post by _sh »

cobbal wrote: post #83
ekosz wrote: post #48

I'm not a low level programmer, but could someone tell me if you could write a LLVM backend for this CPU? If one does that, could it not then work with many programming languages that support LLVM? http://llvm.org/docs/WritingAnLLVMBackend.html

I've never written an LLVM backend, but one difficulty that immediately jumps out at me is the 16-bit architecture. LLVM specifies types with bitwidths and 32 is most commonly used, meaning a backend would have to either emulate 32 bits, forbid the frontends from generating 32 bits, or silently cast them all down to 16 bits.

32-bit types are only common in LLVM because typically the target architecture is 32/64-bit. LLVM will handle 16-bit (and even 8-bit or 13-bit) targets just fine.

That said, a LLVM backend is overkill for this and I'm sure the simple interpreter Notch has rigged up will be just fine for its purpose.

Re: Notch's Specification for the In-Game DCPU-16

#144

Post by wglb »

swang wrote: post #115
dlikhten wrote: post #108

Earlier quoted context omitted.

This opens a whole stream of electronic warfare, however, the problem is that this will be writing programs that have no real-world usage. Except... These programs will be a great way to introduce both kids and adults to programming as learning it will give an edge to people. Question: Will we need to program an OS? And does it run Linux?

Learning about assembly/to-the-metal coding is probably not the best way to learn programming. "OP? LOAD? REGISTER? PC LOAD LETTER? What's a word? There's only 8 registers? Does that mean I can only save 8 things? What do you mean I have to push things into a stack?" This is why most people advocate learning python or ruby. You don't have to deal with the underlying manipulation of the computer until you've decided y…

Works for a lot of people. I started with FORTRAN and quickly went to assembly. I recommend doing some sort of assembly for anyone serious about programming.

Re: Notch's Specification for the In-Game DCPU-16

#145

Post by wglb »

wagabond wrote: post #7
unwind wrote: post #2

Just waiting for the first post about programming this CPU to pop up on Stack Overflow ... :) It's quite an interesting architecture. From an initial perusal, I found these features note-worthy: * Explicit access to PC as a register, makes "computed goto" trivial and very natural. * Because of the above, there is no JMP instruction. * Treating operations on registers as "values" makes the instruction set very orthogo…

I'm a self-taught programmer, and don't know much about CPUs. Would someone mind putting this into relatively plain english, I'm quite curious to know the practical implications of this. Can we expect to see Python running on it in the near future for example :) ?

I would be astonished if there wasn't soon a FORTH running on it. And something like http://code.google.com/p/femtolisp/ might not be totally out of the question.

But who can say. The second Fortran compiler I used ran on an IBM 1800 (equivalent to the IBM 1130, but for process control) had something like 29 phases, and ran on a machine with a total of 4k 16-bit words.

Re: Notch's Specification for the In-Game DCPU-16

#146

Post by wglb »

nknight wrote: post #51
jiggy2011 wrote: post #49

Earlier quoted context omitted.

I worry about the griefing potential here. I can imagine nothing pissing off a noob more than getting a virus within 10 minutes of play and having no idea how to stop his ship from self destructing. Perhaps this will need some sort of firewall system built in where ships cannot communicate unless ports have been explicitly opened. Perhaps some sort of communications proxy that can serve for safe communications. It co…

Firewall? Ports? Communication proxy? It has 64K 16-bit words. What exactly are you expecting the default software to do that opens it up to viruses?

Wow, like if you are programming assembly, that is a pretty huge space. One example of what can be done in 128k bytes is http://www.ciexinc.com/telemed/index.html.

Re: Notch's Specification for the In-Game DCPU-16

#147

Post by calebmpeterson »

wglb wrote: post #145
wagabond wrote: post #7

Earlier quoted context omitted.

I'm a self-taught programmer, and don't know much about CPUs. Would someone mind putting this into relatively plain english, I'm quite curious to know the practical implications of this. Can we expect to see Python running on it in the near future for example :) ?

I would be astonished if there wasn't soon a FORTH running on it. And something like http://code.google.com/p/femtolisp/ might not be totally out of the question. But who can say. The second Fortran compiler I used ran on an IBM 1800 (equivalent to the IBM 1130, but for process control) had something like 29 phases, and ran on a machine with a total of 4k 16-bit words.

I wondered if I'd be the first to suggest a LISP implementation... glad to see I wasn't.

Re: Notch's Specification for the In-Game DCPU-16

#148

Post by tlrobinson »

Zaak wrote: post #121
dlikhten wrote: post #108

Earlier quoted context omitted.

This opens a whole stream of electronic warfare, however, the problem is that this will be writing programs that have no real-world usage. Except... These programs will be a great way to introduce both kids and adults to programming as learning it will give an edge to people. Question: Will we need to program an OS? And does it run Linux?

I expect that there will be some kind of default OS released with the game, and that many alternatives will pop up very quickly. It will not run Linux, because Linux requires a 32-bit CPU with megabytes of RAM. Someone might write a Linux-like system for it though.

Not to mention a MMU. Of course that didn't stop someone from implementing an ARM emulator on an AVR and running Linux on it... http://hackaday.com/2012/03/28/building-the-worst-linux-pc-e...

Re: Notch's Specification for the In-Game DCPU-16

#149

Post by dy9 »

dspillett wrote: post #64
unwind wrote: post #2

Just waiting for the first post about programming this CPU to pop up on Stack Overflow ... :) It's quite an interesting architecture. From an initial perusal, I found these features note-worthy: * Explicit access to PC as a register, makes "computed goto" trivial and very natural. * Because of the above, there is no JMP instruction. * Treating operations on registers as "values" makes the instruction set very orthogo…

The thing that looked odd to me was: >* IFE, IFN, IFG, IFB take 2 cycles, plus the cost of a and b, plus 1 if the test fails* It is a long time since I worked in assembly, but I don't remember comparison functions having different timings depending on results when I were a lad. (FYI, most of the assembler I played with was for 6502s (in the old beebs) with a little for the Z80 family and early x86)

It seems to me the extra cycle is used to read the first word of the next instruction, since it needs to know how long the next instruction is to skip it.

Re: Notch's Specification for the In-Game DCPU-16

#150

Post by eridius »

evincarofautumn wrote: post #28
evilpie wrote: post #16

Just for fun, I wrote a disassembler for his instruction set. https://gist.github.com/2300590 I previously wrote some assembler routines for x86, which is very complex, working with Notch's design is a breeze and actually enjoyable. Does he somewhere mention if the code is loaded into the RAM? This would make self-modifiable code possible.

It doesn’t say in the spec, unless you interpret the memory dump for his assembled example as residing at address 0x0000 rather than offset 0x0000. But I don’t see any reason why PC shouldn’t refer to a RAM address. It would be great for code economy in such a constrained system.

It's definitely loaded into ram. Some of the operands are defined in terms of "next word of ram", which clearly refers to reading (and incrementing) the PC.
Post reply on HN