Imaginary 64-bit 680x0

[Karlos]

Have you ever wondered what it would be like to have a 64-bit 68000? Not specifically the hardware architecture per se, bur the familiar programming environment? Of all the assembly languages I ever learned, 68000 was my favourite. During lockdown, a few of us wondered about it a bit too much, so we decided to build our own. We aren't hardware engineers bur I've implemented a few virtual machines in my time, so we went that route...

https://youtu.be/3W7gG8MXit4

[nicholas]

Have all the creatives left? 

[BozzerBigD]

@Karlos

It would just address more memory, I can't see what other difference it would make and it would be pointless unless 64-bit apps became standard.

[nicholas]

Whoosh!

Here is there repo. The readme is quite upfront about what this is and why we are doing it.

https://github.com/intuitionamiga/mc64000

[Karlos]

@BozzerBigD - I think you may have missed the point of this. It's not about what difference it would make to end users, it's about what it might be like to write code for. When AMD extended the x86 to 64 bit, it wasn't just wider registers, there were more of them, newer instructions, etc.

For MC64K, for example, we merged the integer and address registers into 16 64-bit ones. Similarly we increased the FPU to 16 registers too. We also allowed effective addressing modes to be used for source and destination operands for all dyadic instructions that made sense and likewise made some of the monadic ones dyadic. As we were making a virtual machine to run the code on we were free to experiment in this way without worrying about how difficult it would be to implement in in silicon.

[psxphill]

Is it really a 64 bit 680x0 though?

It kinda reminds me more of a 64bit MIPS cpu.

[Karlos]

Is it really a 64 bit 680x0 though?

It kinda reminds me more of a 64bit MIPS cpu.

It's a virtual machine so any similarity to any silicon (living or dead) is coincidental. MIPS is a load-store, register-to-register RISC style architecture. MC64K is not. You can use most of the familiar 68000 addressing modes for each operand. It just doesn't support the "memory indirect" modes added in the 020. It's also much easier (and preferred) to write position independent code because branch offsets are 32-bit and you'd be doing well to create bytecode gigabytes in size.

The largest divergence from 680x0 is in the handling of conditional logic. Maintaining a status register is a pain and for the vast majority of executed instructions it's wasted effort since the condition codes are not used. Instead we implemented a "compare and branch" model for simplicity. We aren't creating a simulator or emulator and accept that this will not be able to do "anything a 68000 can" because it doesn't do overflow or carry, for example. However for the things it can do, you can often do in fewer instructions because there are wider types, more available registers, ability to use effective addresses for both source and destination at the same time, etc.

These simplifications allow the bytecode interpreter to run at speeds that make it actually fun to play with. The simple Rotozoom demo in the video, for example, is running full RGB 640*480 at 30fps with time to spare despite being the most naive implementation I could think of. Factoring in the idle time and instructions per pixel, it's about 350 MIPS on my laptop (i7-7500U). Not going to win any prizes but it's adequately fast enough for most things. Obviously a JIT would be better but that's a long way off.

[Karlos]

It's also little endian, so there's that I suppose. Not as big of a deal as it sounds as it's not an emulator and doesn't have to have binary compatibility with anything. The choice was dictated by the fact the immediate target hosts are x64 and AArch64. It means little from an assembly language perspective since registers have always behaved little endian on 68000 and the only gotcha is when accessing memory at the same address.

[AJCopland]

It's cool that you can just decide to create a virtual CPU because it's fun!

Interesting and cool work

[Karlos]

It's cool that you can just decide to create a virtual CPU because it's fun!

Exactly. We were having a nostalgic conversation about the days when assembler was fun to write and still legible, things we'd wished the 68000 had, or had done differently from a user programming perspective.

Designing bytecode machine was pretty easy as I've done more than one in the past. By far the largest effort was actually writing the assembler tool itself. It's not especially brilliant but it does work.
Right now the focus is on building a "host" that provides the IO, graphics, audio etc. that are exposed through a trap like mechanism.

[Pyromania]

Very cool project.

[psxphill]

Obviously a JIT would be better but that's a long way off.

Even lazy flag calculation in an interpreter would be a win, I did that when I wrote an interpreter in 6502 assembler.

The no flags is what made me think of MIPS, but then 88100 doesn't appear to have flags either. But the 68k does.

You can create a virtual CPU if you want, I just think it's not inspired enough by the 68k to make a big deal out of it.

6502 was inspired by pdp11, but that was never once mentioned in documentation.

[nicholas]

 

6502 was inspired by pdp11, but that was never once mentioned in documentation.

As was the 68000, which is sod all like the 6502.

mc64k is inspired by the 68k because that's what we know and love the best.

Feel free to use it or not. No skin off our noses.

[Karlos]

I think you're conflating the implementation specifics with the intent. The intent is to provide a programming experience familiar to those used to writing 680x0 assembly but providing 64 bit support. The no flags implementation was a simplification trade off. If your code is mostly comprised mostly of conditional branching instructions then sure, it's going to less familiar. You're also probably doing something a bit weird.

The Rotozoom demo code his here: https://github.com/IntuitionAmiga/MC64000/blob/main/assembler/test_projects/rotozoom/src/main.s

I'm sure most 68000 programmers would have no difficulty understanding it and navigating the differences from actual 68000.

[Karlos]

Even lazy flag calculation in an interpreter would be a win, I did that when I wrote an interpreter in 6502 assembler

For an emulator yes. For an interpreter? Why? Unless you intend to support arithmetic overflow and other special cases, I can't think of a single reason to implement it. If you want to take a branch because an operand is zero, not zero or bigger than some other operand, comparing them directly means you don't have to evaluate the side effects of any operation.