OpenBSD on Motorola 88000 processors
18 points by calvin
18 points by calvin
I was an admin of the 88K based Data General Aviion line, later travelling around the country installing our software on them. The article only mentions the workstations but we had fridge sized servers with hundreds of terminals attached to them, and the first commercial RAID array in Australia (also the size of a fridge). They ran DG/UX which IMO was the best OS nobody had ever heard of in the day.
They were great machines, it’s a shame Moto dropped the 88K and DG eventually went out of business, but this was around the time of the rise of Wintel in the server room. I miss the diversity of operating systems and ideas.
Those disk arrays led to the Clariion and were absorbed by EMC^2 which is now Dell.
I heard DG/UX had good SMP and NUMA code in its x86 form.
Yes, the Clariion brand came later but we used them too, those systems were bulletproof. My memory is that 88K DG/UX had the best SMP of all the contemporary machines I used. I don’t know about x86 but I imagine the story was similar.
It just felt like a system that didn’t get in the way of things. It helped that it shipped with many of the GNU goodies, so I didn’t have to build them myself!
I have a friend who's a fan of that era of CPU's, and she tends to say "the worst mistake any product can make is relying on Motorola".
This article very indirectly points at the 88000 being a "Harvard" architecture CPU, rather than von Neumann - data and instructions were said to be totally separate, maybe even in different address spaces, I don't remember or maybe it wasn't made clear. One of the machines touched on in the article has two of the 88200 CMMU chips - one for data, one for instructions, which I read as very indirectly referencing Harvard architecture.
It's not that uncommon, or really all that different from modern architectures. The CMMU, as I understand it, couples a cache and MMU. Most modern CPUs have seperate d-cache and i-cache, as well as separate d-TLB and i-TLB. The difference is that the d-TLB and i-TLB in processors isn't manually managed, and both refer to the same set of page tables. Architectures like SPARC where the TLBs are software managed (rather than hardware page-table walking), could in theory have instructions and data treated as separate address spaces too.
Even on 32-bit x86, by taking advantage of code and data segment selectors you could have entirely separate address spaces for them.