Hacker News Reader

It's just a big switch/case over the instruction set by the looks of it. Those things can get pretty damn large if your are implementing anything close to a proper CPU.

It's just very condensed, I imagine so he can change a bunch of values and re-test quickly.

It's not quite as bad as it would be in a program other than an emulator, granted, but I can't imagine that it's easy to notice a bug in a 200-character line of:

    int pos=(ram[PC++&0xffff]+X)&0xff; byte v=ram[(ram[pos]&0xff)|

And so on. It just seems like some sort of code generation would be much easier.

This is true, but it should be easy enough to make a script that can pack/unpack the code as needed.

Most likely when you have a bug in something like this it will be isolated to one specific instruction. So you can just zoom in on the bit you need.

If you followed the standard Java practice for this you would probably have an Instruction class that inherited from several base classes and that would make your project very large and difficult to navigate indeed.

You cannot really do code-generation when all the lines have meaningful differences. What you saw was very likely the most compact representation of the VM -- any other form would likely be just as bad.

That kind of code generation is unlikely to exist. Each line of that code has its own specific purpose, it's not some copy pasta. And surprisingly, it should be trivial to test it! there are no conditions of edge cases apart from the conditional instructions. As long as you test for ranges and off by ones, there's no space for mistakes really. I'd take that kind of code over usual "business logic" any time :-)

Nonsense! Look at the code again. There are a lot of repeated motifs, like the things that fetch from memory and increment the program counter. It cries out to be partially automated. If nothing else, there has got to be a more human-readable equivalent to all that bit-masking and offset-adding.

Code generation doesn't need to be heavyweight.

Even some one-line functions or macros would make that code much more compact and readable.

Off by one errors, maybe we'll even bring back the golden age of buffer overflow exploits, emergent realistic hacking gameplay mechanics, Notch you're a genius...

Part of the battle system could be causing segfaults in rival ship computers.

Looks like standard emulator coding to me. Op-codes and state changes.

Very cool. Haven't ever delved into this kind of code. Got any pointers/tips for me? :)

Well, seeing as how it's 16-bit:

0x0000

0x0001

0x0002

...

That help?

I would suggest you attempt to solve the "Cult of the Bound Variable" programming problem[0]. The first stage of the problem requires you to write an emulator for an "ancient" computer that has a very easy to follow instruction set.

[0]: http://www.boundvariable.org/task.shtml

That looks like pretty much every small virtual machine I can remember reading. There's nothing atrocious about it; that's what small virtual machines look like.

With a couple of simple macros, the code could be fraction of its size and much more readable. Code with that property is atrocious in my mind. For example these "argument reading" bits are repeated over and over again:

ram[PC++0xfff]&0xff

((ram[PC++0xfff]&0xff)|((ram[PC++0xfff]&0xff)<<8))

Of course Notch said it has been generated, so he probably had a neat definition that barfed this garbage out. But it's strange that so many commentators here are defending the output as a reasonable coding style for a VM!

it's just a bunch of (virtual) CPU state changes, really easy to read if you've ever simulated a CPU before. Take the INY instruction for example. it does: increment Y register, set the Z(ero) flag/bit to whether Y is now equal to zero, set the N(egative) flat/bit to whether Y is now less than zero.

Or BNE (branch not equal): if the last instruction (hopefully a compare) set the Z(ero) flag, jump ahead t instructions. otherwise don't do anything.

Maybe notch has asserted that if he can't fit what an instruction does in ~60 characters, that instruction is doing too much

"...if the last instruction..."

I know this sounds like nitpicking, but that mistake right there has caused many a 6502 emulators to produce erroneous results. The 6502 core's status register is resident and the flags in it are changed only when an op-code directly does so; it never "resets" arbitrarily, so proper conditionals that act on a specific status flag can actually occur far and wide between the op-code that actually affected that one specific flag.

I don't know if the behavior you describe is commonplace on other cpus, but it seems quite reasonable, if only because it greatly reduces the complexity of the emulator because not every instruction has to touch every status register. What would JMP set the Z(ero) or N(egative) status bits to anyway?

I've only briefly glanced through the dcpu-16 spec, but it doesn't seem to explicitly call Z or N by the names I've imputed, I think they're just regular registers that get used for a certain purpose sometimes.

"this _sounds_ like nitpicking"

when emulating a cpu, there's nothing but nits. pick away :)

There appears to be a 'CpuBuilder.java' on a tab a bit further along, so that code may be generated.

No, It's Java.

CPUBuilder is most likely a class with a single method:

buildCPU()

{

   return new CPU();

}

Then there's probably an AbstractCPUBuilderFactory to go along with it.

It was, indeed, auto-generated:

https://twitter.com/#!/notch/status/181791985164746753

Looks like from that screenshot the project was originally called "SpacePuter" ...

Reply on news.ycombinator.com