OT: comparing DCPU-16 to 65Org16 (and variants)

[BigEd]

The DCPU-16 is a 16-bit cpu defined for an as-yet unreleased multiplayer game called 0x10c(*). The game is somewhat like corewars updated and crossed with Elite, and has a pedigree with Minecraft which is very popular and has attracted some impressive technical feats. So it's likely to be a popular game and therefore a popular, if virtual, CPU.

The interest lies in the shape:

• 16 bit registers (8 of them, plus SP and O, a fullsize overflow register)
  16 bit 'bytes'
  16 bit 'address bus'
  opcode is 1 'byte' plus 0, 1 or 2 operand 'bytes'

This bears just a little similarity with our 65Org16, except we only have 3 registers. EEye's 65Org16.b as presently implemented has 16 accumulators and 2 index registers and SP. Of course we have a 32-bit address bus and therefore 2-'byte' pointers, and therefore we can, and do, have such a thing as zero page.

The spec of the DCPU-16 is simple, and is very clearly laid out here. It's more regular than our machines: all registers except SP can perform all roles. It lacks a status word, instead having a set of skip on compare instructions. All instructions take two operands, where the operands can be registers, literals, memory or indirect accesses, or special. (These are quite powerful addressing modes)

It seems likely that someone will come up with a C compiler before too long. I'm not sure how applicable that will be as a starting point for targetting the 65Org16.b, given the differences in the machine. At the very least, the backend would be issuing macros or sequences of 65Org16 instructions, which would cost time and space. A peephole optimiser might make up a little of the slack. (But a C compiler which produces less them optimal code on a CPU running at 100MHz might be better than none at all)

There's a subreddit which is presently too new to have much in it. There's a tag on stackoverflow which is again too fresh to have any meat.

Edit: and there's a forum here

Cheers
Ed

(*)The c is a superscript but it seems that we don't write it out as 0x10^c

[Dajgoro]

I am a huge Minecraft fan, and i can't believe that they are going to do such a game, i was long dreaming of a space-like game that has some real technical stuff in it(i am also a sci-fi fan)! I also own a Minecraft server i which i am mostly the only payer(for now), and in which i am trying to make that simple cpu that i was discussing in one of my topics here, but the 6502 sbc project is a bigger priority so i am spending my free time finishing it.
I am looking forward to see how this develops, and i have a feeling i am going to know all the cpu details one day...

[ElEctric_EyE]

I never heard of Minecraft, but looking quickly at a youtube video it sorta looks like Quake series type first person shooter 3D. I'm a big fan of those, but they're aimed at systems that have high end graphics cards...

I'm curious though, is all of this virtual on the PC or what kind of hardware are they running it on? I've not had alot of time to look at all their info.

[Dajgoro]

ElEctric_EyE wrote:

I'm curious though, is all of this virtual on the PC or what kind of hardware are they running it on? I've not had alot of time to look at all their info.

At what exactly are you referring to?

[ElEctric_EyE]

Dajgoro wrote:

At what exactly are you referring to?

I gather it's a multiplayer game, and has some new cpu. What is the hardware platform?

[cjb]

You missed the part where it'll be a monthly subscription to play. Another thing that made Minecraft popular was the ability to run pirated copies (try before you buy...), which the new game is cracking down on. The Buzz on the Cyberstreets (or rather, the forums that originally brought Minecraft to popularity) aren't showing much enthusiasm.

[BigEd]

For my part, and for the purposes of the post, I was only interested in the details of the DCPU-16 rather than the game! I'm particularly interested in the tools which people create. (Forum sticky post on the subject)

To answer EEye's question: just think of it as an online PC game with spaceships which have computers on them. As part of the game you program the computers to control the spaceships. The CPUs on those computers are this, fictional, DCPU-16. The game's central servers will be simulating these fictional CPUs to run everyone's control programs all the time, whether or not they are currently playing online.

So, there's no hardware platform for the game purpose. Enthusiastic people have written emulators, assemblers, debuggers already (github search). And it seems there's already at least two efforts at tiny C-like languages too.

(I did read a hint that some people might build DCPU-16 in hardware - and why not - but that's not part of the game. As a CPU, when I last looked at the spec, it lacked interrupts.)

Cheers
Ed

Edit: collection on github, not sure what the status of this collection is.

[Arlet]

Last year I also designed a 16 bit CPU core (the "X18"), targeted for FPGA, and optimized for speed. The "18" comes from the fact that the opcodes are all 18 bit wide, which matches the width of a block RAM, if you include the parity bits.

It's usable, but it still needs refining a bit. You can check out the Verilog here:X18. The top of the Verilog file contains a summary of the instruction set.

It's got 16x16 bit registers (not including a separate 14 bit PC), and a dedicated hardware stack (only 16 deep, although on Spartan 6 it could be expanded to 64 at no additional resource cost). General instructions execute in a single cycle. Memory reads, multiply, and barrel shifts take 2 cycles. Branches take 3 cycles. It's got a nice set of load/store instructions, with pre-decrement and post-increment, and small offsets. So you can do:

Code: Select all

mov  (r0)+, (r1)+

This will load from address in register 0, store in address in register 1, and increment both registers, all in 2 cycles (because it involves a memory read)

It was getting close to 100 MHz on a Spartan-3. Haven't tried it on Spartan-6 yet.

[BigEd]

Nice. I like machines where all the registers can do all the same things - yours, DCPU-16, ARM. I think they are easier to learn, to explain, to implement and presumably also better compiler targets. Also nice to use the freedom of FPGA to get post-increment without taking an extra cycle (and to get multiply in only one or two cycles.)

With 6502, I suspect more than one beginner has wondered why they can't do arithmetic or logic operations on X or Y, or struggled to remember which addressing modes use which of the two. And then the intermediate 6502 programmer will be loading and saving X and Y while the expert always seems to have the right values already in place.

If (or when) we had 65Org16 variations with more regularity, it wouldn't prevent the use of X and Y in their traditional roles, but it wouldn't limit them.

I see lots of DCPU-16 activity on github: yesterday I found 2 python and 4 go projects, also a verilog project. Lots of updates in my RSS feeds this morning. I hope there will be some good ideas and maybe even code we can use in py65 or visual6502, for presenting a front panel and for controlling single-stepping, tracing and debugging.

Also I notice an ABI.

[Dajgoro]

BigEd wrote:

As a CPU, when I last looked at the spec, it lacked interrupts.

I registered to their forum, my nickname there is D101h(as on many other places where i don't wish to disclose my name), and i started a few topic, in one of them i proposed that interrupts could be added, but it seems that Notch(the game creator) for some reason doesn't like interrupts. If the community wants to see interrupts, somebody will have to change Notchs mind.

[GARTHWILSON]

BigEd wrote:

With 6502, I suspect more than one beginner has wondered why they can't do arithmetic or logic operations on X or Y, or struggled to remember which addressing modes use which of the two. And then the intermediate 6502 programmer will be loading and saving X and Y while the expert always seems to have the right values already in place.

Good observation. As for the number of registers, the main situations I can think of where the 6502 falls short is really just a matter of the registers not being wide enough. For operations of 16 bits or more, you have to do one byte, put it back (even though you know you're going to need it again right away), get the next one, operate on that one, etc.. That is solved however by having wider registers, which is one reason I find the '816 a lot easier to program. The other reason is just that it has more instructions and addressing modes. After a lot of experience, I don't really see the value in having a lot of registers, except that as Samuel pointed out, it would be nice to be able to switch to another set for interrupts, to avoid the need to push things onto the stack and later pull them back off. I would like it to be re-entrant though-- not that that would be used very frequently, but there is a use for it.

[Arlet]

One of the places where I'd like at least one extra register is in the (ZP),Y addressing.

In other places, the zero page fulfills a role of a bunch of registers, but this comes at a price. A simple INC ZP takes 5 clock cycles, whereas incrementing a register on a RISC machine only takes 1 cycle.

[BigEd]

Indeed. The familiar refrain that 6502 has lots of 'registers' holds true for as long as it isn't important that the code size and speed just got a bit worse. This is where an on-FPGA cache would help, of course, whether specific to zero-page or not.

With FPGA we're now free to have as many registers as our instruction encodings and assemblers can provide for. EEye has demonstrated that it's quite painful to use the TYA, TAY, TSX, TXS style of mnemonic when you expand the register set a lot. (At least, it is if you write macros by hand.)

For a 16-bit machine I think 8 or 16 registers is going to be best, but I'm not sure which. (8 registers gives 2 more bits for opcode encoding, assuming two register operands.)

Interesting that the DCPU-16 keeps S outside of the register pool, and has PUSH and POP rather than a general pre/post decrement/increment. But then, for reasons of in-game backstory, this isn't meant to be a perfect CPU!

Edit to add: Notch, the originator of the DCPU-16, was earlier working on a 6502, but subsequently tweeted:

Quote:

There we go, invented my own 16 bit cpu that is waaay less annoying to program for. Sorry, all 6502 fans. ;D

Ed

[ElEctric_EyE]

BigEd wrote:

...With FPGA we're now free to have as many registers as our instruction encodings and assemblers can provide for. EEye has demonstrated that it's quite painful to use the TYA, TAY, TSX, TXS style of mnemonic when you expand the register set a lot. (At least, it is if you write macros by hand.)

For a 16-bit machine I think 8 or 16 registers is going to be best, but I'm not sure which. (8 registers gives 2 more bits for opcode encoding, assuming two register operands.)...

Not too painful, as I use alot of copy, paste, and then modify the nybble values...

Originally, I thought alot of registers would be more like the 1802 CPU in the fact that with more registers, there would be less need for external memory...
There are some very intriguing features of this 'ancient' 1802 CPU I would like to bring back to life.

[8BIT]

ElEctric_EyE wrote:

Originally, I thought alot of registers would be more like the 1802 CPU in the fact that with more registers, there would be less need for external memory...
There are some very intriguing features of this 'ancient' 1802 CPU I would like to bring back to life.

my first computer was the 1802-based COSMAC ELF II. I was 14 years old and taught myself how to program in machine language using a hex keypad. I really liked the 1802's registers. Any one of the 16 register could be a stack register, program counter, or data store. I also like the 4 input bits that were directly mapped to instructions along with the Q output bit. Great times!

Daryl