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

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

#171

Post by tptacek » Thu, Apr 05, 2012, 2:51 PM UTC

jlouis wrote: post #170

tptacek wrote: post #138

Earlier quoted context omitted.

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 poi…

I'm sure part of the goofiness of this ISA is just that Notch wants to keep it nerdy and somewhat retro, but I wonder if he also wants to keep compilers from getting out of hand; like, he wants people writing (at least sometimes) in assembly.

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

#172

Post by ericbb » Thu, Apr 05, 2012, 4:16 PM UTC

RodgerTheGreat wrote: post #169

ericbb wrote: post #159

Earlier quoted context omitted.

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 metaprog…

That's interesting. Sorry for not getting it right away. It's making more sense on second reading. :)

Now I'm curious how you'd encode subroutine calls. Your example was completely inlined but the call-sequence will be critical in determining how compact the code ends up.

Also, were you thinking of using a cross-compiler and keeping the dictionary out of the DCPU-16s memory? Let me know if you create a public repo. I'd be interested to see what you come up with!

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

#173

Post by RodgerTheGreat » Thu, Apr 05, 2012, 6:27 PM UTC

ericbb wrote: post #172

RodgerTheGreat wrote: post #169

Earlier quoted context omitted.

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 metaprog…

That's interesting. Sorry for not getting it right away. It's making more sense on second reading. :) Now I'm curious how you'd encode subroutine calls. Your example was completely inlined but the call-sequence will be critical in determining how compact the code ends up. Also, were you thinking of using a cross-compiler and keeping the dictionary out of the DCPU-16s memory? Let me know if you create a public repo. I…

No worries, I should've been more detailed in my original post- what I'm describing is definitely an atypical (if not unprecedented) Forth. I agree, the call-sequence is critical. My initial thought was to ensure that we always leave the stack pointers in "return stack mode" before calling, and return them to that state before exiting a routine. Thus, procedures:

  : A   dup * ;
  : B   2 A A 1 A ;

would look like:

  A:
    SET Y, SP
    SET SP, X // switch to data
    SET PUSH, PEEK
    SET A, POP
    SET B, POP
    MUL A, B
    SET PUSH, A
    SET X, SP
    SET SP, Y // switch to return
    SET PC, POP

  B:
    SET Y, SP
    SET SP, X // switch to data
    SET PUSH, 2
    SET X, SP
    SET SP, Y // switch to return
    JSR A
    JSR A
    SET Y, SP
    SET SP, X // switch to data
    SET PUSH, 1
    SET X, SP
    SET SP, Y // switch to return
    JSR A

As you can see, a little bulky, but doable. Optimizing stack operations to make better use of the registers can get rather nasty- still thinking about the best way to approach it. I'm definitely thinking in terms of a cross-compiler, and ignoring things like defining words for the sake of simplicity, at least at first. I'll drop you a comment if I get a prototype working.

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

#174

Post by uvdiv » Sat, Apr 07, 2012, 3:45 AM UTC

Anderkent wrote: post #167

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.

I think that line is specific to the basic instructions only (if it weren't, "...and is the lower six bits" would be false).

"For Non-basic opcodes, 'a' is actually the opcode"

Actually it's the single argument -- 'o' is the opcode.

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

#175

Post by zoul » Sun, Apr 08, 2012, 8:17 AM UTC

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

https://github.com/krasin/llvm-dcpu16/

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

#176

Post by dspillett » Tue, Apr 10, 2012, 9:18 AM UTC

AnIrishDuck wrote: post #90

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)

Many CPUs with branch prediction carry a penalty of a least one cycle for mispredicted branches as the fetch stage(s) of the pipeline must be invalidated. From wikipedia: The time that is wasted in case of a branch misprediction is equal to the number of stages in the pipeline from the fetch stage to the execute stage. Modern microprocessors tend to have quite long pipelines so that the misprediction delay is between…

Ah, obviously my experience is somewhat out of date! My "hacking cycles off loops in assembler" days were all before I got my hands on any kit advanced enough for pipelining and branch prediction to be a consideration.

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

#177

Post by RollAHardSix » Fri, Apr 13, 2012, 3:14 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.

I disagree. I recently designed and implemented virtualized image servers (real ones coming once the Requisition request comes through) for faster image serving. This was basically unheard of by anyone I work with however by having read the http specs I was able to give a report on why we wanted to serve images in parallel. It's easy to dismiss Web Developers as (X)HTML/CSS, Javascript & Php. In reality there are FAR, FAR, FAR more uses for programming competent Web Developers. Shoot, even having a good grasp of fundamental Computer Science helps with understanding Php's array's (or lack-thereof ;) ).

Now for practical usage? Sure Assembly is probably a waste of time. I still haven't found a real way to implement that wouldn't be. But the fundamental understanding of how a computer works, how decisions are made so close to the machine enhanced my understanding about programming which in turn enhanced my understanding about how I wanted to develop and engineer, even for the web.

My .02 cents anyway.