This is 88K-in-the-NeXT-cube? in view mode; [Up]
Date: Sun 11-Feb-1989 20:34:56 From: Unknown Subject: 88K in the NeXT cube? 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). >From: matt@nanovx.UUCP (Matt Brandt)
Date: Sun 14-Feb-1989 17:11:00 From: Unknown Subject: Re: 88K in the NeXT cube? 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 */ >From: lgl@blake.acs.washington.edu (Laurence G Lundblade)
Date: Sun 20-Feb-1989 03:47:39 From: Unknown Subject: Re: 88K in the NeXT cube? 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? >From: phaedra@blake.acs.washington.edu (J. Anderson)
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.