zdenko@csd4.milw.wisc.edu (Zdenko Tomasic) (02/12/89)
What would be required for the cube to host and run 88k RISC card? Mach should be able to handle 2 processors, right? One would ,of course, need new compilers or customize GNU stuff. What about NuBus? Could it handle 88k speed, perhaps with a lot of cacheing? I suppose "mainframe chips" should get a good workout without suffocating. 88k might just be a quick way to get a good performance of untuned NeXT specific stuff :-) Now, let's open discussion (with flames if necessary). -- ___________________________________________________________________ Zdenko Tomasic, UWM, Chem. Dept., P.O. Box 413, Milwaukee, WI 53201 UUCP: uwvax!uwmcsd1!uwmcsd4!zdenko ARPA: zdenko@csd4.milw.wisc.edu
mmeyer@mcdurb.Urbana.Gould.COM (02/15/89)
If my memory serves me correctly, Tektronix has a 88k NuBus card
available for the MacII. The Mac2 is running a 10MHz NuBus not the
25 MHz NuBus that the NeXT machine runs.
> Mach should be able to handle 2 processors, right?
Mach is able to handle two homogeneous processors very nicely. At CMU
they have Mach running on multi-processor Vaxen, and I think Encore
machines and Sequents.
Handling heterogeneous processors however, is a very different animal.
One possible approach would be to treat the 88k board as a remote
processor, and handle system calls on the 68030. This approach
(master-slave) is vaguely similar to Purdue's dual-processor Vax
(Goble 81). Mach would have to be able to discern between an 88k
executable and a 68k executable, requiring some changes to the 88k
loader to set flags. You would then want to map the 88k process'
memory into the NuBus address space and run the process on the 88k.
System calls/services would trap to the 68k running Mach.
Another approach would be to have two Mach kernel binaries (one 68k
version on main board, one 88k version on the NuBus board) as one
coherent operating system. This would be a challenge. Professor
Charles Shub at the University of Colorado at Colorado Springs as
done some work along this direction. You would need a way to load
kernel data in the same place for both binaries, and have the kernel
text be two separate entities. You need to worry about handling
synchronization, mutual exclusion and a host of other things over
the NuBus.
--morris
Morris Meyer mmeyer@urbana.mcd.mot.com uunet!uiucdcs!mcdurb!mmeyer
Motorola Microcomputer Division, Champaign-Urbana Design Center
1101 E. University, Urbana, Illinois 61801, USA.
My opinions are my own, and are not the opinions of my employer, or
any other organisation. I indicate my company only so that the reader
may account for any possible bias I may have towards our products.
=================== REFERENCES ===================
%A George Goble
%A Mike Marsh
%Z Purdue University
%T A Dual-Processor VAX 11/780
%D September 1981
%R Purdue University Technical Report, TR-EE 81-31
/* Written 2:35 pm Dec 23, 1988 by cdash@boulder.Colorado.EDU in mcdurb:comp.os.research */
/* ---------- "Heterogenous migration (details)" ---------- */
At about 7:30 this evening, we successfully migrated an active demonstraton
program from a sun to a microvax using an enhanced V version 6.0 distributed
operating system. Happy holidays.
operationally, it is run of the mill active migration (ala theimer & cheriton's
"preemptible remote execution" paper of a few years ago) only the two machines
have different architectures.
essentially, we have an executable that has two text segments, one data
segment, and what we call a mapping segment. The process sends a message to the
migration server requesting the migration. The migration server then uses the
information in the mapping segment to remap the data (including pointers to
data and code) to the destination environment. The activation history (usually
a stack in most environments) must be similarly mapped. Obviously, a process
control block is also created on the destination machine. I'll be presenting a
paper on it at the Computer Science conference this february, and hope to have
something in shape to submit to sigops by their deadline.
Actually, we can migrate at about source statement granularity. Since the
process originates the migration, the migration always takes place when the
process is at a particular point in the migration request code. The sequence
leading up to that point can vary, so we need to be reasonably general about
mapping stacked contexts.
charlie shub cdash@boulder.Colorado.EDU -or- ..!{ncar|nbires}!boulder!cdash
or even cdash@colospgs (BITNET)
Prof. Charles M. Shub
Computer Science Department
University of Colorado at Colorado Springs
Colorado Springs, CO 80933-7150
(719) 593 - 3492
/* End of text from mcdurb:comp.os.research */yap@me.utoronto.ca (Davin Yap) (02/20/89)
In article <66400001@mcdurb> mmeyer@mcdurb.Urbana.Gould.COM writes: > >If my memory serves me correctly, Tektronix has a 88k NuBus card >available for the MacII. The Mac2 is running a 10MHz NuBus not the >25 MHz NuBus that the NeXT machine runs. > >> Mach should be able to handle 2 processors, right? > >Mach is able to handle two homogeneous processors very nicely. At CMU >they have Mach running on multi-processor Vaxen, and I think Encore >machines and Sequents. > >Handling heterogeneous processors however, is a very different animal. > > --morris Ok. I haven't been reading this news group, so forgive me if I'm reiterating someone elses comments, but how about an 'Edge Inc.' coprocessor for the beast? I figure it should fit in the cube - even if it takes more than one slot - and it executes all? 68??? instructions in about two cycles (last I heard). Would this be too expensive? Is anyone listening in Arizona? Davin? -- Davin Yap, Dept. of Mech. Eng., U of Toronto, Toronto, CANADA, M5S 1A4 Work: (416)978-6443 ,Email addresses in order of fastest to slowest: (1) utme!yap@utorgpu.bitnet (2) yap@me.toronto.edu (3) uunet!utai!utme!yap