Re: New pmap module for m68k

> On Nov 13, 2025, at 1:05=E2=80=AFAM, Romain Dolbeau =
<[email protected]> wrote:
>=20
> * MC68030
> - a pure shared bus is severely impaired by the bus arbitration
> mechanism. The '030 doesn't request the bus, it uses it unless someone
> else owns it. So one would basically need to round-robin between the
> '030s, compromising latency. Of course one can isolate '030 from one
> another on independent buses, but it requires a lot more hardware.
> Though if the design requires interfacing with 3V3 devices, the level
> shifters could also be used to isolate signals.
> - the data caches don't play well with one another, so any potentially
> shared page has to be marked as non-cacheable, severely impairing
> performances

I agree, the 68030 is not a practical CPU for such an endeavor.

> * MC68040
> - bus arbitration is saner, and in theory could be done with just an
> external arbiter (for CPUs and DMA devices). The documentation for
> external arbiters is unfortunately errata'ed to "broken beyond repair,
> don't look at it", which isn't helpful
> * the data caches don't play well with one another even with snooping,
> so so any potentially shared page has to be set to write-through
> rather than write-back, impairing performances

Yah, I spent a little time looking at the 68040=E2=80=99s arbitration =
and cache coherency protocols for another project (I have a series of =
68k home-brews in the works), but I haven=E2=80=99t spent much time =
working out all the details, even for my simple use case.

> * MC68060
> - AFAICT, SMP should be implementable with no major downside (other
> than all the unimplemented instructions in the '060, like CAS2)

Well, the major downside of 68060s is that they=E2=80=99re pretty hard =
to come by, comparatively.

> I'm not entirely sure which core can be emulated in QEmu ; I know the
> '040 can but I don't think the '060 is there?

Qemu models the 68040 only, and not 100% accurately.

> If anyone wanted to look at SMP support in NetBSD/virt68k, the best
> bet would likely be the MC68040 as caches and arbiters won't be an
> issue (I'm assuming it's a functional model, not a RTL-accurate one),

It is a functional model.  Adding dual-CPU support to it should not be =
terribly difficult if the goal is to prep software.

-- thorpej