I created a subreddit for this interesting aspect of 0x10c if anyone is interested:
Notch's Specification for the In-Game DCPU-16
91–100 of 177 posts
Re: Notch's Specification for the In-Game DCPU-16
#92Earlier quoted context omitted.
Although some of the implications require experience to understand, I'd say it already is in "relatively plain English", you simply haven't been exposed to the vocabulary and concepts necessary. Trying to explain in any detail would basically be reproducing Wikipedia, so here are some links: http://en.wikipedia.org/wiki/Program_counter http://en.wikipedia.org/wiki/Word_(computer_architecture) http://en.wikipedia.org/…
A smarter way might be just implementing a new LLVM backend (gives us C via Clang, some other languages). However, even with C, the standard library probably won't leave much space for the user code itself -- so you might need something slimmer. Also, some kind of simple RTOS (www.freertos.org, maybe?) to run all these programs (I assume people would really want to run several programs at a time). I wonder if the 128…
The ANSI C library is quite small. It originates in an era when 128KB of RAM was reasonably roomy. To this day, there are C libraries designed to fit comfortably within that size.
Most of the library code will never even be present anyway. Your (statically-linked) binary will simply contain those functions actually used, which is likely to be a small subset of what is available.
Re: Notch's Specification for the In-Game DCPU-16
#93Just 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…
Re: Notch's Specification for the In-Game DCPU-16
#94That compulses me to take Compiler class next semester, and write a C compiler for this precious fictional CPU.
And what about creating this cpu?
Re: Notch's Specification for the In-Game DCPU-16
#95Earlier quoted context omitted.
Although some of the implications require experience to understand, I'd say it already is in "relatively plain English", you simply haven't been exposed to the vocabulary and concepts necessary. Trying to explain in any detail would basically be reproducing Wikipedia, so here are some links: http://en.wikipedia.org/wiki/Program_counter http://en.wikipedia.org/wiki/Word_(computer_architecture) http://en.wikipedia.org/…
A smarter way might be just implementing a new LLVM backend (gives us C via Clang, some other languages). However, even with C, the standard library probably won't leave much space for the user code itself -- so you might need something slimmer. Also, some kind of simple RTOS (www.freertos.org, maybe?) to run all these programs (I assume people would really want to run several programs at a time). I wonder if the 128…
An RTOS won't be of much use without interrupts. You could implement coroutines, but preemptive scheduling is not possible.
Re: Notch's Specification for the In-Game DCPU-16
#96Earlier quoted context omitted.
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?
Do not underestimate those old computers. When you remove audio, visual, and textual data from your programs, remove all the code for handling those and slinging them about and processing them, when you remove the textual file formats and replace them with hand-optimized binary, when you give up on any form of structured modern programming and just hand-compile custom assembler, when your opcodes aren't 64-bits wide,…
Exactly. Remember the 64kb video demos from 2004?
Re: Notch's Specification for the In-Game DCPU-16
#97Now here's an interesting bit: "Question: can we trade the programs we create? How will you stop malicious viruses etc?" "yes. And I won't stop viruses, the players will have to do that themselves." ~ https://twitter.com/#!/notch/status/187474819980328962
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…
It could have a system similar to EVE
I hope this is the opposite of EVE in practically every way... except the high-level concept. Let's not give Notch any ideas.
Re: Notch's Specification for the In-Game DCPU-16
#98Earlier quoted context omitted.
I was thinking they could treat software and components like we do when granting third-parties permission to access our Twitter/Facebook accounts: Plasma Shield Generator requests the following permissions: * Read/write to the ship's log * Draw power from the core * Use the red alert system Plasma Shield Generator will not: * Access communication protocols
It's 128KB of RAM, that's the same as the original Macintosh in 1984. I would be surprised if it ran at more than about 10MHz. And nevermind the constrained resources for implementing any of this hypothetical infrastructure, unless Notch adds an MMU, you can't enforce permissions You can't think about this in modern terms. It's not a modern computer. It's a 1980s computer, and it's supposed to run a spaceship. Think…
It should be possible to provide programs as "data" that is interpreted by the program "running" on Notch's CPU, thus allowing a fine-grained, whitelisted permissions even without MMU. No?
Re: Notch's Specification for the In-Game DCPU-16
#99Earlier quoted context omitted.
A smarter way might be just implementing a new LLVM backend (gives us C via Clang, some other languages). However, even with C, the standard library probably won't leave much space for the user code itself -- so you might need something slimmer. Also, some kind of simple RTOS (www.freertos.org, maybe?) to run all these programs (I assume people would really want to run several programs at a time). I wonder if the 128…
An RTOS won't be of much use without interrupts. You could implement coroutines, but preemptive scheduling is not possible.
Moreover, it would be very surprising if low-latency or deterministic timing properties would actally be useful in the game.
Re: Notch's Specification for the In-Game DCPU-16
#100Can't wait to see FORTH running on this CPU! FORTH ?KNOW IF HONK ELSE FORTH LEARN THEN
That's my plan actually. It should be a lot easier to get going than C or an LLVM backend as others are suggesting.
Same here. The main design decision is how to represent the secondary stack. I was thinking we could reserve a pair of registers to keep the parameter stack pointer and return stack pointer, and swap them out with SP as needed.
1 2 + >r
SET PUSH, 0x1
SET PUSH, 0x2
SET A, POP
ADD A, POP
SET X, SP // back up data stack pointer
SET SP, Y // switch to return stack
SET PUSH, A