public
Last active

DCPU16 Cycle Count Proposal

  • Download Gist
DCPU16_cycle_count.md
Markdown

Motivations

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

Theory

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.

Rules

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

Examples

  • 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

Extras

  • 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.

Downsides

  • 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

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

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

Please sign in to comment on this gist.

Something went wrong with that request. Please try again.