MC64K: Just what you always wanted
  • Paladin of the Pegasos
    Paladin of the Pegasos
    Posts: 1109 from 2013/5/24
    From: Nederland
    MC64K aims to implement a Virtual Machine and assembler syntax insired by the legendary 680x0 series of microprocessors from Motorola.

    We want to write 680x0 style assembler for an imaginary 64-bit implementation of the 68000, because:
    We're old.
    It's our happy place.
    Why not?
    We can.
    Take your pick.
    We want to assemble that code into some easily interpretable binary format:
    Rapid execution.
    Should also be JITable.
    We want to execute that binary in a host application that provides basic IO, graphics and sound services:
    To amuse ourselves with tunnels, vectors and chiptunes.
    Any resemblance to genuine usefulness is purely coincidental and unintended.
    16 64-bit general purpose registers for integer / address operations.
    Byte, Word, Long and Quad operation sizes.
    16 64-bit IEEE-754 registers for floating point operations.
    Rich set of 680x0 inspired addressing modes.
    Large Code / Memory Model.
    Simplified branch programming model.
    680x0 inspired instruction set and syntax.
    Effective Addresses for both source and destination operands.
    Simple set of host provided read-only registers for configuration:
    RAM base address, size.
    Framebuffer address, format, meta.
    Initial PC start address.
    Microsecond walltime (since last reset).
    Intentional Limitations
    While we love the 680x0, there are some things we don't support.

    We aren't interested in hardware emulation or Operating Systems compatibility:
    No supervisor model or traps.
    No MMU.
    No atomic memory operations.
    We aren't interested in unecessary complexity:
    No binary-level compatibility.
    No extended precision FPU support.
    No Condition Code Register:
    Compare and branch model.
    No extended arithmetic (addx, etc).
    No Binary Coded Decimal.
    No memory indirect addressing modes.
    No support for packed decimal floating point.
    We aren't interested in your safety. If you use this, the chances are you aren't either:
    No memory access checks, access any address.
    No branch target validation, jump to any address.
    No checks for invalid operations, e.g. zero divide.
    No checks for infinite loop conditions.
    You're probably running the interpreter on an OS that will handle these anyway.
    Intentional Differences
    The 64-bit consumer device space is dominated by x64 and ARM. Both of these architectures use litte endian memory models. As the focus is primarily on 680x0 style programming and not on 680x0 emulation, the Virtual Machine is designed with little endian memory models in mind.

    Reduces complexity and improves performance on target hardware by eliminating unnecessary byte swapping.
    Improved consistency. 680x0 processors treat registers as if they are little endian when dealing with operand sizes less than the full register, but has the opposite behaviour on memory.

    There are some features we haven't fully decided on yet but have in mind:

    Streaming instructions:
    Should use host native vector intrinsics.
    Should be worth the cost under interpretive emulation. This is tricky to get right and will likely depend on processing larger amounts of data in one virtual instruction than a typical SIMD vector register.
    JIT compiled execution model.
    1.67GHz 15" PowerBook G4, 1GB RAM, 128MB Radeon 9700M Pro, 64GB SSD, MorphOS 3.15

    2.7GHz DP G5, 4GB RAM, 512MB Radeon X1950 Pro, 500GB SSHD, MorphOS 3.9
  • »10.03.22 - 21:11