I posted this on Amiga.org the other day but thought I'd share it here also.

Back at the start of the first UK lockdown myself and a few friends (mostly Nicholas and GadgetMaster) were nostalgically discussing the 68000 and how it might have evolved had it have gone 64 bit. Not so much from an end user's perspective, but from a coders.

One thing led to another and we built a virtual one. A 68000 style assembler front to a bytecode engine that is inspired by the 68000 architecture. There are some significant changes beyond having 64 bit registers, mostly to simplify things. Ultimately the thing serves no purpose except to pander to nostalgia but it certainly has been fun to work on and it's starting to become fun to actually write code for.

Here's a quick demo of it in action https://youtu.be/3W7gG8MXit4

Repository here: https://github.com/IntuitionAmiga/MC64000

_________________
Doing stupid things for fun...

@Karlos

Beautiful.

See, friend Karlos, how this post being one of the oh so rare few that actually carries a tale of true skill and dedication and technical knowledge, is left drifting away from the homepage with a sad zero answers?

LET'S CHANGE THAT






/mega

Last edited by MEGA_RJ_MICAL on 22-Mar-2022 at 12:18 AM.

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

@Karlos

Interesting.

_________________
All the way, with 68k

@Karlos

Quote:

Karlos wrote: Here's a quick demo of it in action https://youtu.be/3W7gG8MXit4 Repository here: https://github.com/IntuitionAmiga/MC64000

I watched the video. The code doesn't appear to have any 64 bit instructions in it. In what way would this code work differently than with a regular 32 bit 680x0?

What is the speed like compared to native 'c' code?

Being little-ended is a bummer. Why can't you make it big-ended?

@bhabbott

That particular demo doesn't really need any 64 bit operations but you will notice move.q is used for pointers though because addresses are 64 bit. The point of the demo is to be "familiar" to 68000 coders. However it does make use of the additional floating point registers as there is a slightly faster code path for selected register to register 32 and 64 bit operands.

As for endianness, there's simply no benefit to big endian given the target hosts are x64 and AArch64. Also, 68000 registers have always behaved little endian, it's just the memory accesses that requires you to think the other way around. It doesn't change how you represent any literal data in your code, for example. Making the machine big endian would just cost performance for zero benefit.

Performance wise, well, it's an interpreter. The demo in the video represents about 350 MIPS based on the instructions per pixel, number of pixels, frame rate and percent idle time left per frame. Native code on the host would crush it, but that's not the point.

Last edited by Karlos on 22-Mar-2022 at 08:05 AM.
Last edited by Karlos on 22-Mar-2022 at 07:58 AM.

_________________
Doing stupid things for fun...

There are other changes that are not shown in the demo. For example:

You can use effective addresses for both source and destination operands of every dyadic instruction.

Many instructions that were monadic in 68000 are dyadic in MC64K.

Registers a0-d7/a0-a7 are just accepted aliases of r0-r15 and each one can be used as an address or data register.

Pretty much all code code can be written position independent because branch displacements are 32 bit (there are short 8-bit displacements the assembler can use in some cases).

The biggest change to the user programming model are that branching is simplified. There are no condition codes and b
Conditional branching operations take one or two arguments (other than the target) depending on whether or not you're comparing two different values, or comparing a value to zero.

_________________
Doing stupid things for fun...

@Karlos

That's an interesting concept. At first I thought this was a Vampire competitor. MC64K is also an interesting label.

I see the point is not another 68K. But more like a ColdFire 68K. Inspired but not binary compatible.

A few points come to mind. The 64K isn't 68K but like it. Against x64 where they have dropped x86 as if 64 bit is exclusive to x86 now.

The endian thing. I don't see big endian as a problem because modern CPUs have native endian support. Apart from endian mode x86 has better support for big endian than PPC has for little endian. A modern x86 can read and write in big endian as well as byte swap. The only blocker I see is language and compiler not being up to scratch. You may need to elaborate what you mean by the 68K being more like little endian internally as I didn't fully understand that. OTOH, I've thought of x86 as being big endian internally, since the result of maths and logical operations would be just like 68K and PPC.

Likewise, your model is byte based. Keeping things simple and codes progressively expand depending on complexity. The 68K is word based. All code blocks build on 16-bit datas.

The prefix thing. That isn't a 68K thing. That's an x86 thing.

At the last point, and this is also after reading the description on github, it looked more like an x86-64 than a 68K. I think if you stripped down x64 you ended up at 64K. Your r0 to r15 is even like this. I wonder if a modern assembler was built that simplfied mnemonics, throwing out all the legacy AX/EAX/RAX crap, how it would compare to yours?

That was my impression anyway.

What's hotrods opinion of this Imaginary 64-bit 680x0?

:)

_________________
Sent from my Quantum Computer.

@Hypex

To address a few points:

Quote:

MC64K is also an interesting label.

It's tongue-in-cheek. It's a 64-bit memory model and lacks a few things from the actual 68K, so 64K it is.

The idea is that the machine is "inspired" by the 68000 from a programmer's perspective, in particular the assembler syntax, which uses broadly the same instruction names and type suffixes for the same operation types. It being a bytecode machine was purely for ease of implementation.

Quote:

The 64K isn't 68K but like it.

Yes. It's in no way binary compatible and it isn't 100% assembler compatible either.

The 68000 has 16 integer registers, they just aren't general purpose. You can only do some limited arithmetic on address registers and you can't use data registers for addressing (except as indexes some addressing modes). There are good reasons for this in the hardware implementation followed by Motorola but there's basically no reason for the separation in a virtual machine. If anything, it just makes it more complicated. For this reason we opted for 16 general purpose registers that can be used in either context and adopted the convention that d0-d7 would alias r0-r7 and a0-a7 would alias r0-r15. We respect this in the fledgling ABI that we have with the host interpreter too, passing/returning pointers in r8 for example. In addition to a7, sp is also accepted as an alias for r15 and, like the 68000, the stack grows downwards.

Having 16 registers is nice from a bytecode perspective as register pairs can be readily packed into a byte and this is used for some register-to-register operations. Having decided on 16 General Purpose Registers (GPR from now on) it was only logical to go for 16 FPR in the FPU.

The bytecode format was designed for (hopefully) fast interpretation. For a general dyadic instruction, the format goes:

{ instruction opcode } { destination EA } { ... any additional EA bytes } { source EA } { ... any additional EA bytes } { ... any additional operation bytes, e.g. branch offset etc }

fadd.d (a0, d0.l * 8), 16(a1, d1.l * 8)

{ instruction opcode } { destination EA } { ... any additional EA bytes } { same as destination }

{ fast path } { instruction opcode } { packed register pair }

move.l #$fe000000, d0
add.b #1, d0

move.l #$fe000000, (a0)
add.b #1, (a0)

move.l #$fe000000, (a0)
add.b #1, 3(a0)

move.l #$fe000000, r0
add.b #1, r0

move.l #$fe000000, (r0)
add.b #1, (r0)

blt.w d0, d1, .where_to

Last edited by Karlos on 22-Mar-2022 at 06:52 PM.
Last edited by Karlos on 22-Mar-2022 at 05:40 PM.
Last edited by Karlos on 22-Mar-2022 at 05:38 PM.
Last edited by Karlos on 22-Mar-2022 at 04:58 PM.
Last edited by Karlos on 22-Mar-2022 at 04:55 PM.
Last edited by Karlos on 22-Mar-2022 at 04:53 PM.

_________________
Doing stupid things for fun...

@DiscreetFX

Quote:

DiscreetFX wrote: What's hotrods opinion of this Imaginary 64-bit 680x0? :)

Maybe you should ask Ted.

@Hypex

Also see: https://github.com/IntuitionAmiga/MC64000/blob/main/docs/programming/Migration.md

_________________
Doing stupid things for fun...

@Karlos


Karlos wrote:
There are other changes that are not shown in the demo. For example:

You can use effective addresses for both source and destination operands of every dyadic instruction.

Many instructions that were monadic in 68000 are dyadic in MC64K.

Registers a0-d7/a0-a7 are just accepted aliases of r0-r15 and each one can be used as an address or data register.
[/quote]

Shouldn't it make sense on a modern CPU if integer and FPU processing could be done a the same ALU? So registers could be uses for integer values, addresses and floating point values?

Quote:

Pretty much all code code can be written position independent because branch displacements are 32 bit (there are short 8-bit displacements the assembler can use in some cases).

Or PC relative branches, jumps or jumps with return address

Quote:

The biggest change to the user programming model are that branching is simplified. There are no condition codes and b Conditional branching operations take one or two arguments (other than the target) depending on whether or not you're comparing two different values, or comparing a value to zero.

That's a part I have to read again ... I had condition code registers in almost all CPUs so I have to look how to work without them.

---

What I would like to have an a future CPU:

1. Byte handling
The Intel was good handling single bytes in it's registers, byte handling was (is?) still important and used more clock cycles on 68k than on x86.

2. DSP commands
I would like to have some DSP commands on a CPU, adding, multiplying 4 Bytes (RGBA) in a register with a mechanism to prevent overflows. The same goes for 16Bit values (sound).
Bit-Reversed Addressing Mode (for FFT) and Circular Addressing Mode (for ring buffers).

3. Register indirect Addressing Modes for easy access to arrays of structs
pre decrement / post increment with values of 0xffff or at least 0xff.


---

The lack of a super visor mode, the lack of traps/exceptions or a MMU are OK for a demo CPU but not for something used for a real world OS like Linux.

It would be nice if there where traps, a supervisor mode, and some MMU registers for address Offsets of User/Supervisor Code and Data.

@OneTimer1

I have a different machine (a much more portable one intended for embedding in applications as a low level script host) I'd written a long time ago that uses a unified register model, but still only has 16 of them. It was also very much a register to register load/store machine. It was faster in terms of raw MIPS than MC64K but equally, each instruction did "less" work.

As it stands, for this project I think keeping FPU and GPR registers separate still has merit. For one thing it means you can have 16 of each kind while keeping the 4 bit identifier. The set registers in use are determined by the operation in question. It will also be a lot easier for a JIT to perform register allocation in code from the existing set as an FPU register won't be used for integer operations and vice versa.

Quote:

Or PC relative branches, jumps or jumps with return address

Yes. You can use jmp and jsr, of course, and for things like function pointers and stuff it's essential. However, for regular function calls, bsr is the most efficient in MC64K.

Quote:

DSP commands

Without a JIT, doing explicit vectorisation in MC64K code is somewhat wasted effort since the fetch-decode part of the overall interpreter cycle takes the longest. However, what we do have is a relatively low latency way of invoking "native" operations on the host. This is organised into a set of 256 groups of 256 discrete operations that are invoked by a special "hcf" operation. We use these to provide things like basic file IO, memory allocation, display, audio and so forth. There is even one for dealing with 2D and 3D vector calculations and their corresponding homogeneous matrices.

We don't have "clock cycles" to measure time in, so the benchmarking that we do is measured relative to the simplest fast-path instruction (add.q r1, r0) which is assigned a value of 1.0. On this scale:

A bsr/rts pair takes around 2.0 units
An add.q r1, (r10) takes about 3.1 units
A hcf to an empty operation takes about 2.9 units.

In short, then, for the cost of about 1 non-fast-path virtual machine instruction you can invoke a host native operation. As an example, the benchmark tests a hand written vec3f normalisation (including the bsr/rts overhead) which clocks in at a whopping 35.5 units. The equivalent native operation accessed via a hcf call takes only 4.0, 2.9 of which is just the overhead.

Quote:

The lack of a super visor mode, the lack of traps/exceptions or a MMU are OK for a demo CPU but not for something used for a real world OS like Linux.

It's not intended for that purpose. It will never run an operating system in it's current form. Instead we are building a host application it embeds into that provides a fixed ABI for sound, graphics etc. The goal of the project, if it has one at all, is to have fun writing assembler primarily for oldschool demo effects and the like. We aim to make the virtual hardware somewhat reconfigurable too.

_________________
Doing stupid things for fun...

@DiscreetFX

It isn't funny even though you think it is.

@Karlos

Quote:

The 68000 has 16 integer registers, they just aren't general purpose. You can only do some limited arithmetic on address registers and you can't use data registers for addressing (except as indexes some addressing modes). There are good reasons for this in the hardware implementation followed by Motorola but there's basically no reason for the separation in a virtual machine... A seasoned 68000 programmer will...

As a 'seasoned 68000 programmer' myself, I find this project interesting. Sometimes I get frustrated with the limitations of 68k code and wish it could made more elegant and efficient.

However as a practicing 68000 programmer I need to work within those limitations, so coding for a 'sort of' 68k that works differently would be counterproductive. What I really need to do is get over the mindset of wishing for stuff I don't have instead of making the best of what I do have. Though some 68k code might not be very elegant (eg. certain byte operations), the effect on performance is generally minimal if properly handled.

Furthermore I have also limited myself to using only pure 68000 code (no 68020 or above), so many of my frustrations are self-imposed. I do this so owners of 'low end' Amigas won't be left out, and because using the the more advanced instructions of later CPUs feels like 'cheating'. I could just code for the Vampire or emulation and not have to worry about producing efficient code, but having to think of ways to make it more efficient on low-end machines helps the other machines too.

Quote:

The goal of the project, if it has one at all, is to have fun writing assembler primarily for oldschool demo effects and the like.

If that's all you want to do it's fine, but I suspect the audience will be very limited due to the differences between your 'MC64K' and 68K which makes it difficult to port code between them. An ISA that extends 68k to 64 bit while maintaining a good level of compatibility might be more useful. Doesn't have to be done right now though....

@Karlos

Cool you understood my MultiCore Amiga Thread!

@QBit

I hadn't read it. Now that I have, there's very little in common with it. MC64K isn't a 68000, it has absolutely no binary compatibility. It's also not a real CPU in that it doesn't have any of the necessary machinery around interrupts and the like. It's also not multicore and to go further, has optimisations that really only make sense in a single threaded model.

With a small design change, it would be possible to make it multicore and run a couple of interpreter instances each in their own C++ thread, but it likely requires removing some of the current optimisations, at least one of which would cost about 25% of the interpreter performance. Then you have all the fun of writing assembler with the added complexity of concurrency to deal with.

I'm not saying it's not doable or even that it's not doable without losing any significant per thread performance. What I am saying is that if it were done, it still wouldn't be what you were asking for.

_________________
Doing stupid things for fun...

@Karlos

Quote:

It's tongue-in-cheek. It's a 64-bit memory model and lacks a few things from the actual 68K, so 64K it is.

Yes, I see that. And 4 times as many bits as 64K can hold.

Quote:

The idea is that the machine is "inspired" by the 68000 from a programmer's perspective, in particular the assembler syntax, which uses broadly the same instruction names and type suffixes for the same operation types. It being a bytecode machine was purely for ease of implementation.

Any plans for expanding it to C compilation?

Quote:

Yes. It's in no way binary compatible and it isn't 100% assembler compatible either.

That was my impression.

Quote:

The 68000 has 16 integer registers, they just aren't general purpose. You can only do some limited arithmetic on address registers and you can't use data registers for addressing (except as indexes some addressing modes). There are good reasons for this in the hardware implementation followed by Motorola but there's basically no reason for the separation in a virtual machine. If anything, it just makes it more complicated. For this reason we opted for 16 general purpose registers that can be used in either context and adopted the convention that d0-d7 would alias r0-r7 and a0-a7 would alias r0-r15. We respect this in the fledgling ABI that we have with the host interpreter too, passing/returning pointers in r8 for example. In addition to a7, sp is also accepted as an alias for r15 and, like the 68000, the stack grows downwards.

These days the data and address separation tends to be seen as a limitation ISTR the 68080 also merging them with extra instructions but forget any details. However, I like the organisation of data and address registers, each to a purpose. Even if it limits each to 8 which is small now days.

But, with your a0-a7 aliases, do you mean r8-15? And r0 for return? That is, only if d0-d7 and a0-a7 is mapped to r0-r15, in that order.

I see you copied the a7 quirk with your sp. It's just I always thought a7 acting as sp was a but quirky. Since they hijacked a7 and used it for stack. Instead of having a proper sp register. It looked a bit hacky. In ASM sp was simply a mnemonic.

Quote:

Having 16 registers is nice from a bytecode perspective as register pairs can be readily packed into a byte and this is used for some register-to-register operations. Having decided on 16 General Purpose Registers (GPR from now on) it was only logical to go for 16 FPR in the FPU.

I can see how it would be.

Quote:

Depending on the mix of fast path to regular instructions I've had up to 550 MIPs out of it on older i7 mobile.

The fastest I have is a slower i5.

Regarding the packed register pair what order are they in?

Quote:

However, this asymmetry is a function of "little endian" register behaviour versus "big endian" memory. In a little endian machine, e.g. MC64K

I see what you mean. Yes, since in your example you used a byte pointer and added 1, it wouldn't make sense if it acted another way.

Quote:

Exactly the same behaviour in both cases. Another large divergence from 68000 is in the handling of branches. MC64K has only the most basic notion of a "status register" that's either running or halted on some exception type. There are no condition codes set by operations. If you want to branch because the word value in d0 is less than the word value in d1, you do so explicitly:

Given it was byte access big and little endian should be equal in this regard.

I was wondering how the branches differed. It's somewhat merged into one operation. So every operation would be like 68K address register where it doesn't affect any conditions.

Quote:

In summary, the likeness of MC64K to 68000 is the user programming model and syntax. It isn't necessarily intended to work anything like it internally.

Understandingly so.

Quote:

Well that's an interesting question. I suppose what you are really asking is, could an MC64K assembler emit x64 binary? It's definitely possible, in the same way that any language can be compiled down. I don't know for sure if all of the addressing modes would be a good fit "as-is" but you could hide most of that I suppose.

Well actually yes. There are things like simplified mnemonics for PPC codes. The 64K could act as an advanced mnemonic language for x86 binary but intended to simplify the programming model.

I never got into x86 ASM and have only really touched it on x86 emulators. But with things like AX/EAX/RAX specifying byte sizes aren't always obvious or easy to memorise (not that I've tried) it would read easier as x.b, x.l and x.q to me or use an register index like rx.s with x being index and s a size.

Quote:

As it stands, bytecode was a good fit because it allowed me to decouple the assembler from what it runs on. The intention is to implement some form of JIT for this in the future but that's not an area I have a great deal of expertise in. This will serve as a good excuse.

Since years I've theorised on my own CPU design. IIRC I was going to make a 256 bit CPU. Since a byte can specify sizes up to 256. So one byte can be size byte following a code byte. I didn't write anything down so that's about the only details I have.

@Hypex

Replying Out Of Order...

Quote:

But, with your a0-a7 aliases, do you mean r8-15? And r0 for return? That is, only if d0-d7 and a0-a7 is mapped to r0-r15, in that order.

The real GPR names are r0 - r15. The names d0 - d7 explicitly alias r0 - r7 and the names a0 - a7 explicitly alias r8 - r15. The name sp is an explicit alias for r15.


Quote:

I see you copied the a7 quirk with your sp. It's just I always thought a7 acting as sp was a but quirky. Since they hijacked a7 and used it for stack. Instead of having a proper sp register. It looked a bit hacky. In ASM sp was simply a mnemonic.

As for the stack pointer, I've always used a dedicated register for that in other virtual machine designs (even going so far to have different call stacks, register save stacks and parameter stacks). The reason I didn't do that here is because of the effective addressing model. In 68000 you can use all the same addressing modes on a7 as you can any other register. Supporting that in conjunction with a 17th register would have messed up the internals. And in any case, by making the registers truly general purpose, the loss of one of them to be "the stack" isn't so bad as there is reduced pressure on the remainder. Invariably, in my experience, imperative code tends to only need a handful of address pointers at any moment and has a greater need for available integer registers.

Quote:

But, with your a0-a7 aliases, do you mean r8-15? And r0 for return? That is, only if d0-d7 and a0-a7 is mapped to r0-r15, in that order.

ABI wise, I go for passing the first integer parameters in r0, r1, ... and the first pointer parameters in r8, r9... and the first floating point parameters in fp0, fp1, ...

Integer return is usually in r0, pointer return in r8 and floating point return in fp0.

This makes the ABI somewhat familiar to people using the 68000 aliases.

As an aside, many of the host functions return two values, for example r0, r1 (if r0 contains a value, r1 can contain an error/success code) or r8, r0 (if r8 contains a possibly null address, r0 can contain the error/success code).

Quote:

Regarding the packed register pair what order are they in?

The destination register number in the lower nybble, the source register number in the upper nybble. For example, the operation "add.q r5, r7" would have an encoding of 3 bytes:

{ fast_path byte } { add_q byte } { source_reg nybble : dest_reg nybble }

Last edited by Karlos on 23-Mar-2022 at 04:41 PM.

_________________
Doing stupid things for fun...

Not compatible enough and not moder enough.
No reasons to use it.
Amiga was from the day one 32 bit big endian computer.
Change to little endian changes everything.
It will be no longer source and binary compatible.
Amiga on x86/arm/risc-v etc little endian hardware should be just Amiga gui and graphics on top of unix.
It is only way forward and that have sense.