Notch's Specification for the In-Game DCPU-16 • Hacker News Board

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

#161

Post by spc476 » Thu, Apr 05, 2012, 4:42 AM UTC

cpeterso wrote: post #89

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…

If the DCPU has only 64KB of RAM, encoding strings using UCS-2 or UTF-16 seems rather wasteful.

The DCPU address 64K worth of 16 bit word (in other words, 128KB, although you can't directly address 8 bits).

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

#162

Post by Zaak » Thu, Apr 05, 2012, 5:03 AM UTC

jiggy2011 wrote: post #132

Zaak wrote: post #121

Earlier quoted context omitted.

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.

Most likely it won't need anything other than some very basic firmware which would be part of the emulator. It is unlikely to need any mechanism for managing drivers for example (unless you can build custom hardware). You might need some form of scheduler if you are running different programs to do different stuff (weapons , engines , navigation) but this could be something very simple and again baked into the emulat…

You could run your spaceship computer like that, but you could also install a multitasking system that allows you to download files from your favorite space BBS while playing a game of solitaire and plotting the course to your next mining asteroid.

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

#163

Post by Tsagadai » Thu, Apr 05, 2012, 5:07 AM UTC

coderdude wrote: post #52

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…

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 doesn't even indicate protected memory segments. You should be able to implement traditional buffer overflows and self-modifying assembly on this processor (that is, you can write to your instructions as if they were any other type of memory).

Here is an analogy, what you are talking about is secure walls with a lockable door; what you have in this chip is some wood, a saw, some nails and a hammer.

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

#164

Post by paduc » Thu, Apr 05, 2012, 10:18 AM UTC

wglb wrote: post #144

swang wrote: post #115

Earlier quoted context omitted.

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.

What do you mean by "serious about programming"? Can a web developer be serious about programming? Assembly is a waste of time for them.

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

#165

Post by jonbro » Thu, Apr 05, 2012, 11:07 AM UTC

paduc wrote: post #164

wglb wrote: post #144

Earlier quoted context omitted.

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.

What do you mean by "serious about programming"? Can a web developer be serious about programming? Assembly is a waste of time for them.

having a low level understanding of program flow can help in many situations. If you are an extremely lucky programmer, you might be able to live your life only in high level languages, but most that I have met had to get down in the plumbing eventually. Understanding asm will help with that.

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

#166

Post by wglb » Thu, Apr 05, 2012, 12:04 PM UTC

paduc wrote: post #164

wglb wrote: post #144

Earlier quoted context omitted.

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.

What do you mean by "serious about programming"? Can a web developer be serious about programming? Assembly is a waste of time for them.

I am not so sure. To be a good web developer, you need to have a familiarity beyond css, js, html, and the framework you are using. You should be able to understand the underlying protocol, for example, what do the HTTP headers look like? How are they separated? How can SQL injection be dependent on header contents? You can unknowingly build a vulnerable web app if you don't understand the mechanics.

And in my mind, "serious about programming" extends beyond building web apps.

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

#167

Post by Anderkent » Thu, Apr 05, 2012, 12:06 PM UTC

uvdiv wrote: post #110

I'm not sure if it's well-specified. What does this do? JSR POP Does the argument POP (or [SP++]) get evaluated before, or after, the "[--SP] <- PC" implicit in JSR?

Interesting question.

Spec says 'a is always handled by the processor before b, and is the lower six bits.'

For Non-basic opcodes, 'a' is actually the opcode, and b is the argument. This would imply JSR is evaluated before POP.

What we want JSR POP to mean, of course, is 'jump to the last item on the stack, then push PC+1 to stack'. So I would guess that's how it actually works, and the spec needs a revision.

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

#168

Post by jiggy2011 » Thu, Apr 05, 2012, 12:16 PM UTC

Zaak wrote: post #162

jiggy2011 wrote: post #132

Earlier quoted context omitted.

Most likely it won't need anything other than some very basic firmware which would be part of the emulator. It is unlikely to need any mechanism for managing drivers for example (unless you can build custom hardware). You might need some form of scheduler if you are running different programs to do different stuff (weapons , engines , navigation) but this could be something very simple and again baked into the emulat…

You could run your spaceship computer like that, but you could also install a multitasking system that allows you to download files from your favorite space BBS while playing a game of solitaire and plotting the course to your next mining asteroid.

Notch suggested on twitter that there would be more than 1 CPU for each ship , so I imagine multitasking would work that way.

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

#169

Post by RodgerTheGreat » Thu, Apr 05, 2012, 12:54 PM UTC

ericbb wrote: post #159

RodgerTheGreat wrote: post #100

Earlier quoted context omitted.

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?

My first try would probably be to use SP for one stack and some other fixed register for the other stack. Also, traditional Forth interpreters don't use code like you showed. I think the main benefit of using Forth (unless you just happen to love RPN) is the compactness of the interpreted code. If you're not going to use an interpreter, then I'm not sure if Forth is really a win. Edit: Just to clarify about the inter…

What you've described is a threaded Forth, which is indeed the most common type of implementation. I was thinking about writing a subroutine-threaded (no inner interpreter) Forth that inlines common primitives and does some peephole optimization. Not necessarily as compact, but much faster. Forth still provides a flexible, structured programming environment compared to raw assembly, to say nothing of Forth's metaprogramming facilities. I'd also say that a fair amount of Forth's compactness comes from the programming style- lots of tiny subroutines allowing extensive code reuse.

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

#170

Post by jlouis » Thu, Apr 05, 2012, 12:56 PM UTC

tptacek wrote: post #138

swang wrote: post #115

Earlier quoted context omitted.

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…

Knuth would disagree with you. And PC LOAD LETTER?

That depends. The Knuth MIX architecture is much like the architecture Notch has in mind. But the more recent MMIX architecture is far more like a modern 64 bit RISC system. In fact, it does look odd that Notch would prefer such an old behemoth nowadays.

An MMIX like ISA would open up the world for compilers much more. With this, it looks like people should be confined to writing simple stuff - which is kinda the point but still rather sad.