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

101–110 of 177 posts

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

#101

Post by omgtehlion »

msarnoff wrote: post #85
dspillett wrote: post #64

Earlier quoted context omitted.

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)

AVR behaves similarly. Branch instructions take 1 cycle if the condition is false, and 2 if the condition is true.

low and mid-range PICs too

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

#102

Post by jiggy2011 »

javert wrote: post #98
nknight wrote: post #57

Earlier quoted context omitted.

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?

You would have to abstract the CPU in some way and then write the permissions management in software as part of the interpreter. Bear in mind that this is already only a 16bit CPU with a restricted address space.

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

#103

Post by SimHacker »

RodgerTheGreat wrote: post #100
tvorryn wrote: post #66

Earlier quoted context omitted.

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 becomes something like 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 Thoughts?

Oh yeah, you could whip a sweet little Forth system up for this processor.

The first thing to do is to write a DCPU-16 assembler in Forth, and use that to write the primitives. That's pretty simple -- just look at the 6502 assembler: http://www.forth.org/fd/FD-V03N5.pdf

Some Forth systems have metacompilers so they can retarget themselves to different architectures. http://www.ultratechnology.com/meta.html

Using a metacompiler with a Forth DCPU-16 assembler would be the best way to go. Then you could easily experiment with different threading schemes, stack architectures, etc.

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

#104

Post by ricree »

javert wrote: post #98
nknight wrote: post #57

Earlier quoted context omitted.

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?

Depends on how it's structured, doesn't it? It's entirely possible that programs and data will share the same memory with no sandboxing between programs. In that case, then without some sort of MMU a virus could just inject code into an otherwise benign program.

Even with finer program access controls, it would still be hard to protect as long as untrusted code was allowed to alter trusted.

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

#106

Post by javert »

ricree wrote: post #104
javert wrote: post #98

Earlier quoted context omitted.

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?

Depends on how it's structured, doesn't it? It's entirely possible that programs and data will share the same memory with no sandboxing between programs. In that case, then without some sort of MMU a virus could just inject code into an otherwise benign program. Even with finer program access controls, it would still be hard to protect as long as untrusted code was allowed to alter trusted.

You don't understand what I'm proposing. If you want to put it in terms of sandboxing, what I am proposing is a sandbox.

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

#107

Post by javert »

jiggy2011 wrote: post #102
javert wrote: post #98

Earlier quoted context omitted.

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?

You would have to abstract the CPU in some way and then write the permissions management in software as part of the interpreter. Bear in mind that this is already only a 16bit CPU with a restricted address space.

You would have to abstract the CPU in some way and then write the permissions management in software as part of the interpreter.

Yes, that's what I said. :)

Bear in mind that this is already only a 16bit CPU with a restricted address space.

I suspect the interpreter could be made to fit, with limited space left for the untrusted (to-be-interpreted) code. As has been pointed out elsewhere, though, if there is a backing store (i.e., simulated hard drive), it's probably possible to have effectively unlimited "RAM" in the game in practice, unless Notch implements a slowdown for accessing the backing store.

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

#108

Post by dlikhten »

exch wrote: post #23
phoboslab wrote: post #13

Now 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

Nice. With a bit of fiddling one could perhaps invert an enemy's shield polarity. That always seems to work miracles in any sci-fi show.

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?

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

#109

Post by redthrowaway »

overshard wrote: post #69

I wonder if it's just me but this game has me more excited about programming in ASM than I ever have, ever... Also in this game I feel like I'll be playing the reverse role I play in real life. IRL I generally always advocate using things like Python and open sourcing everything. In this game I'm definitely going to pull a Steve Jobs, hire out a few friends of mine to program my ASM apps and sell them in some kind of…

When you sell it, however, you'll be selling the source. No pre-compiled binaries, here. Might be a bit difficult to charge for something people can trade for free.
Post reply on HN