SMP support for 680[34]0 ?

[Romain Dolbeau]

Hello,

Am I correct in my belief that there's currently no support for
shared-memory multiprocessing in any of the 68k port?
And that there is in fact no supported systems with an SMP option?
(conflating symmetric multiprocessing & the shared memory paradigm as
they are now more or less synonymous).

The only port that mentions SMP seems to be luna68k (for the Luna-II),
and more as a rumor than a fact.

I can only find traces of a couple of 68040 SMP systems (from Arix and
Concurrent Computer Corp), but very light on details, though some
probably shipped to customers. Proprietary OS, unclear as to the level
of support (processes, threads, ...).
They also appear in a press article mentioning issues with Motorola's
SMP implementation in the 68040 and the need to disable write-back in
the internal caches, which isn't reassuring.

For the '030, it seems it was mostly non-shared memory (so
distributed) implementations, mostly in the scientific literature.

Does anyone knows about SMP 680[34]0 boxes supporting a UNIX(-like) OS ?

I've read the 68040UM a lot recently (for the
<https://github.com/rdolbeau/QuadraFPGA>), and thinking about building
a dual-68040 box with a FPGA supplying all the I/O, but I'm not sure
about being able to properly support something like the NetBSD kernel.
I'm wondering whether anyone has thoughts about SMP/68k from a kernel
point of view.

Cordially,

[Izumi Tsutsui]

Post by Romain Dolbeau
Am I correct in my belief that there's currently no support for
shared-memory multiprocessing in any of the 68k port?

AFAIK you are correct.

Post by Romain Dolbeau
And that there is in fact no supported systems with an SMP option?

(Also AFAIK) no supported SMP m68k systems.

Post by Romain Dolbeau
The only port that mentions SMP seems to be luna68k (for the Luna-II),
and more as a rumor than a fact.

Actually LUNA-II seems to have a socket for the optional
(secondary?) processor around 68040 on its motherboard,
https://twitter.com/tsutsuii/status/356427858018701312
but I have seen no article about such actual hardware options.

Post by Romain Dolbeau
Does anyone knows about SMP 680[34]0 boxes supporting a UNIX(-like) OS ?

No idea.

Anyway, if there is ~no real hardware, I'm afraid very
few people (developers) are interested in SMP support
(that is too complex).

---
Izumi Tsutsui

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Romain Dolbeau]

Post by Izumi Tsutsui
Actually LUNA-II seems to have a socket for the optional
(secondary?) processor around 68040 on its motherboard,
https://twitter.com/tsutsuii/status/356427858018701312
but I have seen no article about such actual hardware options.

Oh, nice setup. I'm guessing no schematics or any other information on
what signals are connected to the socket(s)?
One of my (many) questions is which signals can safely be bussed, and
which needs to be point-to-point between the CPU and the arbiter (or
the rest of the hardware, such as interrupts).

Post by Izumi Tsutsui
Anyway, if there is ~no real hardware, I'm afraid very
few people (developers) are interested in SMP support
(that is too complex).

Assuming hardware could be made to work (working atomic TAS/CAS/CAS2,
coherency maintained, probably by forcing everything to write-through
at first to simplify the arbiter), how complex?
I would think a lot of the support is 'common', and a port would only
need some machine-specific primitives for synchronization, etc., but I
haven't really looked so I could be way off base...
Is there some document/reference explaining what's needed to add SMP
to a port? Just so I know how crazy this idea really is :-)

Thanks & cordially,

[Izumi Tsutsui]

Post by Romain Dolbeau
Assuming hardware could be made to work (working atomic TAS/CAS/CAS2,
coherency maintained, probably by forcing everything to write-through
at first to simplify the arbiter), how complex?

Well, maybe I should say it "boring and non-motivated work"
rather than "complex".

Post by Romain Dolbeau
I would think a lot of the support is 'common', and a port would only
need some machine-specific primitives for synchronization, etc., but I
haven't really looked so I could be way off base...
Is there some document/reference explaining what's needed to add SMP
to a port? Just so I know how crazy this idea really is :-)

Of course the MI (machine independent) part of NetBSD has enough SMP
support, but I'm afraid many sources in the m68k MD (machine dependent)
part like src/sys/arch/m68k/m68k/pmap_motorola.c and
src/sys/arch/[MACHINE]/[MACHINE]/pmap_bootstrap.c etc. assumed
there was no SMP support.

If qemu supports "real" SMP support it might be an interesting work
to implement it, but I wonder if qemu (and other emulators) will
implement critical race conditions and data/instruction caches
where most complex part of SMP support.

Thanks,
---
Izumi Tsutsui

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Romain Dolbeau]

Post by Izumi Tsutsui
Well, maybe I should say it "boring and non-motivated work"
rather than "complex".

I wonder if that's better or worse :-)

Post by Izumi Tsutsui
Of course the MI (machine independent) part of NetBSD has enough SMP
support, but I'm afraid many sources in the m68k MD (machine dependent)
part like src/sys/arch/m68k/m68k/pmap_motorola.c and
src/sys/arch/[MACHINE]/[MACHINE]/pmap_bootstrap.c etc. assumed
there was no SMP support.

Figures. I would have to have a first step of supporting my design UP to
get the machine-specific bootstrap. Then figure out how to move from
that to hopefully MP someday.

I'm planning to ignore cache issues at first, by disabling caches entirely
(good bye, performance!) - including having a physical switch to assert
/CDIS in case that's needed for early work.
No cache, no cache coherency, no problems :-)

Post by Izumi Tsutsui
If qemu supports "real" SMP support it might be an interesting work
to implement it, but I wonder if qemu (and other emulators) will
implement critical race conditions and data/instruction caches
where most complex part of SMP support

SMP support for m68k in QEmu would be awesome, in particular if
it supports multithreading on the host the way the Arrm or RISC-V
version do. Much faster build! Even in the non-multithreaded way
(looking at you, SPARC) it would be nice to have... on the way to
multithreaded ;-) Unfortunately, I don't think it's there? I didn't
look at the new virt68k machine, I must confess.

I don't think simulating cache issues in QEmu is important. Caches
can be ignored (/CDIS, cache control register, or bits in the page
maps) at first, Then figure out how to claw back some performance.
IMHO the SW sould be sorted out first so that it works in an 'ideal'
hardware environment. Then the real hardware issues can be
addressed.

SMP on the 68k and caches won't play nice anyway:

- the 68020 doesn't have data cache (but 68551 are impossible to
find and awkward to use, so not considering that), so that one's easy
- the 68030 has no snooping ability at all, so shared pages will
likely need to be cache-inhibited (which in a modern OS is akin
to all pages! unless one can figure out if a given process doesn't
have threads so the private pages could be cached?)
- the 68040 has snooping (update or invalidate), but doesn't
broadcast writes that hit in L1D. UM says to set shared pages to
write-through instead of write-back. Write-back might work with
snoop-invalidate? Not likely (see '060) but might be the most
interesting to play with.
- the 68060 is similar to the 68040, minus snoop-update. They still
recommend write-through for shared pages.

Cordially,