I'm sure pull requests would be graciously considered. :)

Sorry, this came off a bit rude. I just saw the Go version having the same magic numbers all over instead of using a straightforward enum for no cost, so I felt like this was worth mentioning.

On the other hand, I feel that building all kinds of stuff around notchs MMO-CPU is just an outlet for all of the excitement that has built up. I guess its upon Mojang to deliver and stop people from diverting off course.

I think you're a bit prejudiced against "magic numbers". If a number is used only once in the entire program, why bother giving it an enum? Just write a comment explaining what it is. That's what I did with the Go implementation.

I am not prejudiced, I just know the problem. Enums provide type safety, they integrate with the tools we use, the debugger knows about them, many languages allow you to get a string representation of them for pretty debug output. And best of all, they are completely free.

Looking at this C code; it could be made more self documenting with a few constants (in enum if you want) for the values rather than just putting them in. Comments are fine but it seems like most of the values are used twice.

An enum is a type of comment that can be enforced by the compiler and is likely less typing than adding /* regular comments */.

It can only be enforced if it's used more than once.

> If a number is used only once in the entire program, why bother giving it an enum?

Software changes, and is often changed by someone other than the original author.

I hate magic numbers, i believe comments should be made as last resort. The code should be self-documenting. It's about reading and understanding the code easier. One thing that i learned wit CS is that it's all about making higher abstractions, making the logic closer to the domain you are modeling. If there is a word that resumes CS, i would say abstraction. Thats why we have high level languages, OOP, Operating Sytems, folders and files and etc.

Normally enum is better.

Here enum is not a good idea if you have a switch case like:

switch (val) { /* val is uint8_t / case OP_XXX: break; case OP_YYY: break; case OP_ZZZ: break; }

Looks nice, but in debugging, you have no idea where we are going when you set a breakpoint at the switch. because the val is not an enum type, so debugger can't make the job easier for you.

Now it is much better:

switch (val) { / val is uint8_t / case 0: / XXX / break; case 1: / YYY / break; case 2: / ZZZ */ break; }

> Looks nice, but in debugging, you have no idea where we are going when you set a breakpoint at the switch. because the val is not an enum type, so debugger can't make the job easier for you.

So .. move forward a step?

Things could be more complicated than that.

The val may be a corrupted value which are not covered by any of the listed case. However, you will be able to identify what's going wrong right away by comparing the value with listed cases.

Yes, it is rare. but sometimes I do wish I haven't used enum.

    putting three spaces in front of a line formats it as code and allows use of *

not putting those spaces means that text in asterisks become italics

Well, I think of it more as "fan art", if you will, than a serious project. I was trying to aim for a "one page" implementation for a one page spec (given how generally clean and tidy the design is) because it was fun.

And I'm pretty sure the O register isn't supposed to be set in all cases. And what was lit[] supposed to be for?

Yeah, think you're right. I'm out of spec there. That's what you get for trying to be cute. Fixed now.

I think your lit table also implies you can write to literals. So I can 'SET 2, 0x1f; SET A, 2' and now A is 0x1f.

There's a check in the writeback phase that prevents that.

Ah-ha, yes there is. Sorry.

He needs 'lit' so dcpu_opr() can uniformly return a pointer for all results, including literal values.