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: [email protected]             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol