Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: NetBSD/vax vm for github testing



I should probably clarify this a bit more. *Officially* PDP-11s never had multiprocessor systems. However, they did exist, and DEC used them internally. But none were out by customers, except for a field trial. And RSX do support multiprocessor machines, even though none officially existed.

But it becomes a hard problem with simulations, since the code in RSX is also assuming that all CPUs are executing all the time, and simulation normally don't do that to the level required. Bursty behavior becomes a real problem in this context. On a single-cpu machine, that is very much a non-problem.

  Johnny

On 2025-01-11 15:51, Johnny Billquist wrote:
On 2025-01-11 15:29, John Klos wrote:
I wrote multiprocessor support for NetBSD/vax many years ago; but not many vax machines can have multiple CPUs. It did work on VAX8250, which was just over one VUPS (which is extremely slow today). Also, emulating multiprocessor support in general using a multiprocessor machine is extremely difficult, since you need to synchronise the CPUs so that they emulate
at exactly the same speed. -- Ragge

Just curious: why would multiple CPUs need to emulate at exactly the same speed? I've read about multiprocessor VAXen running different CPUs, and I've run different CPUs on other architectures (Celery and Pentium II with i386, SPARC and HyperSPARC on, well, sparc).

Were the people running different CPUs in a VAX doing something different?

BTW - someone modified SIMH to run multiple CPUs, but only supported OpenVMS. The author had no interest in NetBSD.

https://oboguev.net/vax_mp/

Maybe half an answer. On the PDP-11 (which I know, didn't have MP), RSX is the only OS supporting multiprocessors. And there, there is the mechanism for waking up another CPU when work needs to be done on a specific CPU, and it is expected to respond within a certain time, or else the system will panic, assuming that the other CPU lost it somewhere.

Back in the day when the code was written, this is spinning in a right loop polling that the other CPU responded. And that tight loop is done for a certain number of iterations. Now, on a fast emulation, that loops spins through in no time, and a thread dealing with another CPU might not at all be able to respond in time unless there is a little bit of lockstep synchronization between the two threads/CPUs. So, within some "reasonable" limits, the different CPUs need to run at some matching speeds, and also bursts. Since simulation happens in userspace, you get exposed to user process context switching and thread execution. So one CPU on such a simulated system might run for a time quanta before another CPU does a similar burst, which can be very non- functional to MP operations and mechanisms on the simulated system, which assumes that all CPUs are progressing at the same time.

   Johnny


--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol



Home | Main Index | Thread Index | Old Index