🚀 go-pugleaf

In article <3600018@iuvax> viking@iuvax.cs.indiana.edu writes:
>With the lack of DMA disk storage and graphics support, can A/UX on a Mac II
>operate well when multiple tasks are running and disk swaps are taking place?
>Doesn't everything grind to a halt until the disk access is completed, since
>the CPU is the disk controller?

This is kind of the wrong way to look at things. Consider: a DMA unit is a
second processor that basically has one instruction: BlockMove(). You
would think that the DMA unit could move data around while the CPU is
computing, giving you a theoretical factor of 2 speed up. But it just
isn't so. In order to move data around, you have to move it over the data
bus. The data bus gets just as loaded whether you are using a DMA
controller to move the data or using the main CPU. (Because the 68020 has
an instruction cache, the loop that moves the data stays in the cache, so
all use of the bus is useful data movement.) When the DMA unit is pushing
data around, the 68020 is locked out, unable to get any operands from
memory, unable to get the next instruction to do. (sure, it could finish a
multiply, already in progress, but there aren't many of them in a typical
instruction mix.)

Conclusion: a DMA unit doesn't help much as long as you only have one data
bus in the computer.

There is a big problem though: A/UX and the Mac operating system support a
type of read operation called asynchronous read: the disk gets a command
to transfer data, and the computer goes off and does something else until
the disk generates a hardware interrupt to signify that the data is here.
(Most programs just do a read(), and wait until the data is there, but
under A/UX, there is always something else to run while we are waiting for
the read to complete: the A/UX operating system takes care of it.)

The problem: most mac programs don't use asynch reads. Most Mac disk
benchmarks don't check that the disk driver author actually supports
Asynch reads. Since noone asked for it, most of the existing disk drivers
just make asynchronous reads wait, just the same as if they were ordinary
synchronous reads. (I asked one driver manufacturer why his drives don't
run any faster asynchronously, and he said that noone asked for it and he
had other things to write, so he took the easy way out and just branched
to his synchronous code if the program does try to do asynchronous i/o.)

Under the Macintosh Operating system
The situation is further confused because Apple removed Asynchronous file
Open()s. The Asynchronous bit, in the Open call only, is used to tell a
MFS (64k ROM flat file system) from an HFS (128K and more recent ROM:
hierarchical file system.)

Summary: Don't expect the presence or absence of DMA to be important. What
is important is:
1.) the bus bandwidth (Mac II nuBus, versus Sun VME bus)
2.) whether the disk driver authors correctly support asynchronous reads
and writes.

--- David Phillip Oster            --A Sun 3/60 makes a poor Macintosh II.
Arpa: oster@dewey.soe.berkeley.edu --A Macintosh II makes a poor Sun 3/60.
Uucp: {uwvax,decvax,ihnp4}!ucbvax!oster%dewey.soe.berkeley.edu