Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
DCPU16 Cycle Count Proposal


  • simplify cycle counting so it's easier to understand
  • make the time it takes to emulate 100kcycles more regular


Memory access has inconsistent costs currently. When decoding instructions it costs cycles, but things like [A] don't. For both a "real" DCPU and the emulator (assuming typical cache behavior), memory accesses are more expensive than register accesses.


  • memory accesses cost 1 cycle
  • some operations take extra cycles:
    • +1: MUL, MLI, STI, STD, IF*
    • +2: DIV, DVI, MOD, MDI
    • ... (HW*, interrupts)


  • SET A, B
    • 1 cycle -- read opcode
  • SET [A], [B]
    • 3 cycles -- read opcode, read a, write b
  • MUL A, 2
    • 2 cycles -- read opcode, extra execute
  • MUL A, 200
    • 3 cycles -- read opcode, read a, extra execute
  • MUL [A], 200
    • 5 cycles -- read opcode, read a, read b, extra execute, write b


  • ADD/SUB should preferably be 1 cycle -- it's no more expensive than shifting.
  • Instructions generally cost +1 cycle if there's any branching or extra complexity in the emulator executing them.


  • Makes the DCPU16 more realistic
  • Discourages weird optimizations based on DCPU weirdness

set [A], [B] should write to A, not B. But a good idea. Makes a lot of sense

ColErr commented Aug 26, 2013

It's writing to b, not B, as in the first operand.

I like it. I think that this must be apply now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment