RE: Race in MSCP (ra/rx) driver

[Mark Pizzolato - Info Comm <Mark%infocomm.com@localhost>]

On Wednesday, August 26, 2020 at 12:56 PM, Johnny Billquist wrote:
> A very small nitpick, but anyway...
> 
> On 2020-08-26 21:13, Mark Pizzolato - Info Comm wrote:
> 
> > Covering that case is absolutely a good idea, but in practice, real
> > hardware had microprocessors implementing the nuts and bolts of both
> > the CPU interactions and the rest of the job of the MSCP device.
> > These microprocessors essentially always were slower than the
> > processor they were connected to, with a good number of microprocessor
> > instructions just to fetch and interpret the info in the command that
> > needs to be processed, so even if data access had no mechanical delays
> > the interpretive overhead could never be very close to 0.
> 
> Not entirely true. Many controllers were designed long after the processors
> they were connected to, and made use of way more modern hardware that
> was much faster. Not to mention that some of them even had multiple
> processors to deal with interfacing to the main CPU, and dealing with the
> actual external device.

They might be faster on a per instruction basis, BUT none would be so fast 
that they could receive a command, probe some arbitrary amount of memory 
and produce useful results (usually back in memory) before the system CPU
started executing the next instruction.

> The DELUA ethernet controller, for example, have a 68000 processor on it.
> Definitely faster than most PDP-11s it might have been attached to.
> Possibly faster than some of the VAXen as well.
> 
> The TMSCP controller for the Unibus have an 80186. Similar story there.
> 
> The UDA-50 MSCP controller is build out of AMD 2901 bitslices, and I would
> suspect it was pretty fast compared to most CPUs it was attached to as well...
> The list can be made longer...

All true, but none could possible perform all the necessary steps to 
interpret->process->saveresults->interrupt BEFORE the system CPU started to 
interpret the next instruction.

- Mark