• Please review our updated Terms and Rules here

Multiprocessing

NeXT

NeXT

Veteran Member
Joined
Oct 22, 2008
Messages
8,151
Location
Kamloops, BC, Canada
I got a few spare minutes on the weekend to test a 9500's 180mhz MP card in an 8600 to confirm that the machine will still chime and that got me thinking about what the heck (beyond Photoshop) actually took any advantage to multiprocessing under the classic MacOS 8.x.
My interpretation from Apple was that the OS is mostly single-threaded and multiprocessing is stapled on. Multiprocessing can occur but tasks are pre-emptively assigned. That's a lot of hoops for developers to consider, so presumably multiprocessing in the classic environment was never really a serious option anyone used, aside from Photoshop?
 
Reading some Wikis on it, and theoretically multiprocessing was available starting in System 7.5.3 with the Multiprocessing Services library. Probably the Daystar code Kossow was referring to.

As for apps that took advantage of it other than Photoshop, I would guess 3D modeling and video editing software such as Premiere and especially AVID. MacOS 8.6, I think, probably made the biggest difference, as it started to finally implement a microkernel, multi-tasking, and multi-threading originally developed for the ill-fated Copland.

MacOS 8.6 through MacOS 9 (and even after OS X was formally introduced) probably saw a lot of otherwise mundane apps and even games take advantage of multi-processors after support was implemented more closely at the OS level.
 
I did see that. 8.5/8.6 seems to ship major multiprocessing improvements in the nanokernel. I just see it however as hooks because if the software doesn't care about it they won't get used. I might have a copy of FormZ somewhere that might support it but Premiere I'm sure all my copies from that era are too old to recognize the extra support and Media100 wants a ton of dongles I still can't locate.
 
Not really relevant, I guess, but the Linux kernel code to try to support SMP on the pre-G4-era multiprocessor Macs is really interesting reading. The TL;DR I came away from it with is the hardware is a little bit broken when it comes to some details like interrupt steering; they did manage to get Linux to "work", but it was never entirely stable nor is it fully symmetrical.
 
BeOS did a really good job, but hit a roadblock on machines with 300 MHz or faster CPUs. I don't remember why it wouldn't work.
 
PowerPC BeOS is a strange animal because as written it *wasn't* symmetric; the dual processor 603e BeBox is built out of CPUs that lack the cache coherency mechanisms to even *do* SMP. (BeOS worked around this by statically assigning threads to specific CPUs and having some oddities when came to any shared memory structures.) Given that I imagine that the short-lived Mac version probably wasn't bothered much by the quirks in the Mac's 604 multiprocessor implementation.

It's easy to not give Intel credit for much, but the Intel MPS specification/slash/APIC architecture was pretty advanced thinking for the time. The 604 Macs do at least have cache coherency, but I believe that a single CPU has to be the "master" for all hardware/interrupt handling. Theoretically the Intel APIC architecture makes it completely agnostic how many CPUs you spread it across.
 
There're a couple chaps over at 68k MLA who have Quad 604s in a DaystarGenesis MP, and they've said BeOS absolutely flies on it.

@ClassicHasClass I think you're right. In the same thread for the Daystar, someone mentioned that the 603s weren't designed for MPs, so Be used some custom hardware inbetween to get it to work.
 
Many years ago I would swear I found an actual explanation for the claims about the BeBox being “incapable” of true SMP, but I spent (wasted) a little time trying to find the details again. Seems like most of these details are kind of lost to history, but from what I could find it actually looks like the truth might be more nuanced? Here’s an application note for the 603e that goes into some crunchy details.


It’s confusing reading, but basically the 603 only supports a subset of the “MESI” (modified, exclusive, shared, invalid) cache coherency protocol, IE, it’s missing the “shared” part. This doesn’t preclude having multiple CPUs on the bus, but it does effectively mean that any not-read-only shared memory has to use a semaphore system to ensure coherency… and it looks like there are knock-on effects from this that could result in expensive instruction traps and emulation if you tried to make it “invisible”.

There was briefly an attempt to get Linux SMP working on the BeBox according to some kernel notes in 2.1-pre, but it was apparently a dead end, and the NetBSD people also never got the second CPU to do anything but run a trivial thread running the blinkenlights on the front of the box. In an old mailing list thread there was a claim that the only way you could get the “fake” cache coherence to emulate true SMP required disabling the L2 cache controlled by the MPC105 chipset (IE, it messes with snooping otherwise), and there are notes in the PPC603 datasheet that say that the MEI snooping that *is* present is single-ported and therefore expensive/slow all on its own so… yeah.

The long and short of it seems to be that the BeBox “worked”, and if you wrote your OS with its oddities in mind it worked fine, but it’s a hack and if you can afford CPUs that can do it right you should use them instead.
 
... FWIW, the block diagram of the BeBox I could track down just shows the CPUs sitting as peers on the MPC105's bus and doesn't mention any special glue whatsoever to try to patch over anything, so I would assume the Motorola/NXP application note describing the software workaround is exactly what they did.

Also, did a little more digging into the MPC105 chipset, and regarding that mailing list thread I guess what it actually was referring to is *if* you're doing multiprocessing with the 105 you have to use the signals that would otherwise be cache control for the second CPU, so, yeah, the BeBox didn't actually have L2 cache. Which I guess explains why it was often described as "unbearably slow", especially the 66mhz version, compared to the Macintoshes BeOS was ported to run on.
 
Last edited:
Oh, that part I remember (no L2). Be's technical documentation and FAQs were full of "but we don't have to emulate anything, so it's OK!" And, well, my 133MHz BeBox is sprightly enough in BeOS, so (but the 66ers certainly suffered more for sure). But that's a custom machine running a custom OS tailormade for it, naturally.
 
I've actually only seen a BeBox in the flesh once; ironically perhaps it belonged to a NetBSD developer (he used to bring all kinds of weird stuff into the office) so I *didn't* get to see it run BeOS.
 
I have too. To this day and nearly a decade later I will continue to give it relentless amounts of crap for struggling to spin a shaded teapot in a window at 15fps.
 
You must log in or register to reply here.
Back
Top