NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/sys/amiga/hardware/14511

Text File | 1992-08-25 | 3.7 KB | 72 lines

Newsgroups: comp.sys.amiga.hardware
Path: sparky!uunet!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!eagle!bach.lerc.nasa.gov!fsset
From: [e-mail] (Scott Townsend)
Subject: Crazy Multiprocessing Idea
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: bach.lerc.nasa.gov
Organization: NASA Lewis Research Center [Cleveland, Ohio]
Distribution: na
Date: Tue, 25 Aug 1992 17:26:59 GMT
Lines: 59

Warning -- half-baked idea below.  I welcome you're comments.

Though I'm not a 'power' Amiga user, there have been times when I could
use some significant amounts of extra capability.  Doing system coding for
a parallel processor here at work gave me an idea that _might_ be applicable
to the Amiga.  I'm curious what others out there think, who may have more
experience with apps that might want multiprocessing power (say ray-traced
animations, etc)

The basic scheme is to have one or more processor boards with local memory
sitting on the Zorro bus (_not_ coprocessor bus)  Maybe a 68040 with 4+ megs
of RAM which sits in the Zorro memory space.  There should also be at least
one interrupt from a slave processor to the host (i.e. the 68030 in an
A3000) and an interrupt going back the other way.  So we've got the normal
Amiga CPU being used as a host or front-end processor to one or more
slave processors with local memory, and a method to signal between them.

Next, for software.  The host would set up each slave with the standard Exec
style library vectors (address 4 would be mapped special on the slaves).
These vectors would jump to a simple routine which sent an interrupt to the
host along with the parameters required for whatever library call was being
made.  The host, upon fielding the interrupt, would signal a standard
process to actually execute the call.  Upon completion, this front-end
process would send the results back to the respective slave with an interrupt
which would let the vectored library routine in the slave pick up the
return value(s) and return to the slave application.  Essentially a remote
procedure call from the slave to the host.

I've implemented something like this for a parallel machine here at work.
The individual 88000 processors do the number crunching and use an SGI UNIX
box (via an RPC like mechanism) for file & device I/O.

What I like about this scheme for the Amiga is that it could work without
having to change any Commodore system software or application software (*).
Anything which requires synchronization between processes/tasks is handled
by the front-end process.  (this might become a choke-point, depending upon
the application(s) running on the slave(s))  Note that you might need to
perform some special cache management for the processors to see each others
updates, but that should be able to remain hidden within the RPC scheme.

(*) only applications which access system resources strictly through standard
    library routines would work.  But the applications I can imagine really
    needing multiprocessing would normally have a 'background' processing
    mode which simply sat reading data, crunching, and then writing results.

While not as slick as having a symmetric multiprocessing Exec, I think this
approach is quite doable.  What I don't know is how many applications out there
would actually benefit from it.  I would imagine animation work would be
helped quite a bit, but I haven't done much.

So what do you think?

(I know this isn't a unique idea, but I haven't seen it tossed-around in this
 group so I thought I'd bring it up)


--
Scott Townsend,  Sverdrup Technology Inc.  NASA Lewis Research Center Group
[e-mail]