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