) (04/30/88)
>dan writes >MIPS per processor. The real issue is parallelism, virtually unlimited >parallelism; and the transputer has it. > [DELETIONS] >I feel bad about chastising the people who site the lack of an MMU as a >liability. They seem the closest to understanding the things that are >really important! 'tis true, without an MMU 'virtual memory' is not >going to be feasible. The ABAQ is suppose to implement a greater goal, >_Virtual_Processors_. Each task doesn't get just its own memory to muck >about in, without worry; but its own processor (and anything on that >processor) to muck with. > [DELETIONS] > dan Natuerlich! welcomes the insight that parallel processing is indeed the way, I hope many more people would share that. A 68030 box is a dead end and probably not enough power past 1995 AD. A transputer is expandable hurray!. But but but. Limiting the OS to run as many processes as there are processor is no step forward. Even if each processor gets 1MB space (sounds about right for a personal computer) and we have four processors. Would we like to waste 1MB for my printer spooler, 1MB for the little iconized clock in the upper-left corner of my screen and so on ? Of course not. We wan't to have the processors multitasking as well. Process space is swapped into the processors local area executed swapped out etc. that needs at least one humongous MMU or lots of little per processor MMU. But from my (possible limited viewpoint) I don't see a way around a MMU. (*) And I don't see how a modified UNIX couldn't do the job as the governing OS as well. (**) I mean of course you can't compile plain vanilla BSDxy and hope that that would work instantly. I strongly believe that a vendor like Atari who comes out with an incompatible OS and no major backing (like the Defense Dept. or IBM (or is that the same ?) ) will even with super-duper superior hardware make no dent in the workstation/upscale-personal-computer market. If though the OS *IS* Unix (***) I see indeed a good possibility that something will move. In conclusion : Would someone like to tell me how process management/ communication under HELIOS will work ? Natuerlich! (*) Except if the transputer can generate the necessary bus errors itself to implement VM completely in software. Or by my oversight the chip already has some MMU capabilities. (**) To keep the machine hopping I'd envision one processor dedicated to OS use only, communication via message passing... (***) Ooops I wrote Unix instead of Un*x, what nasty things might possibly happen to me now ? -------------------------------------------------------------- Loveletters & Hatemail to : wallman@yalecs Files to : WALLMANN@CTSTATEU (Bitnet) Talk to : wallman@yale-zoo-suned.arpa --------------------------------------------------------------
braner@batcomputer.tn.cornell.edu (braner) (05/04/88)
[] The transputer is built to support, right in the _microcode_, multiple processes per CPU, and interprocess communication both inside the same CPU and between neighboring CPUs. The _hardware_ takes care of time-slicing between low-priority (user) processes, synchronizing communicating processes, preempting low-priority processes for high-priority wake-ups (e.g. a message sent to a system process), etc. And all with _very_ low overhead. I agree that limiting the number of concurrent processes to the number of CPUs (currently low, say 4 for a starter machine --- wish I had such a starter now...) is not a viable solution. And I agree that an MMU would be nice. BUT: many people multitask on one lousy 68000 (e.g., Amiga (shish!) or even the ST w/RTX). The main problem, as I see it, is that if one process, say the program you are developing, bombs, the whole system goes down. That's where 4 transputers w/1Meg each are good enough: 1 for you DA's, one for your compiler system, 1 for your background uploads, and still one left for your crash-prone experimental program. If the latter crashes, you reboot just that one transputer. Helios is NOT Unix. Unix is NOT designed for a multiprocessor personal machine, either. To quote a Helios document (by N.H. Garnett, Perihelion Software): "That the transputer is in need of an operating system is self evident... Most existing microprocessor OS's cannot support multi-processor hardware, even where they support multi-tasking. Unix is too large, its model of processes does not correspond to that of the transputer, and it remains essentially a uni- processor OS..." Helios is supposed to be a general OS for a network of transputers, not just for the ABAQ. Whether they did a good job of it, and whether it will take off, I have no idea. I wish somebody else was marketing it rather than uncle Jack... - Moshe Braner PS: still looking for a used 520ST system.
hase@netmbx.UUCP (Hartmut Semken) (05/06/88)
In article <28201@yale-celray.yale.UUCP> wallman-george@CS.Yale.EDU (Natuerlich!) writes: >But but but. Limiting the OS to run as many processes >as there are processor is no step forward. Even if each processor gets The Transputer processors are able to run multiple processes on one processor. He does the multitasking in hardware (!). The idea is: one T414 runs an operating system and some applications. TWO of them will run the same thing (almost) twice as fast (if there are any asynchronous processes to be spread over the network). >1MB space (sounds about right for a personal computer) and we have four >processors. Would we like to waste 1MB for my printer spooler, Whith multitasking you print in backround. You need no "Spooler". >I mean of course you can't compile plain vanilla BSDxy and hope that >that would work instantly. Right. There is no support for virtual memory (or MMU or the like). T's are _different_. Nothing like the old stuff. >I strongly believe that a vendor like Atari who comes out with an >incompatible OS and no major backing (like the Defense Dept. or IBM >(or is that the same ?) ) will even with super-duper superior hardware ^^ almost... >make no dent in the workstation/upscale-personal-computer market. Hmm, Perihelion (the people, who made not just Helios but the ABAQ as well) intends HELIOS to become THE operating system for T's. It runs even on a PC with a TEK4/8 or Inboard B004 (seen in Hannover). >Natuerlich! Of course! hase -- Hartmut Semken, Lupsteiner Weg 67, 1000 Berlin 37 hase@netmbx.UUCP I think, you may be right in what I think you're thinking. (Douglas Adams)
) (05/07/88)
In article <4679@batcomputer.tn.cornell.edu> braner@tcgould.tn.cornell.edu (braner) writes: >[Lots of interesting stuff about the transputer] > Thanks for some information about the transputer, I would be most happy if the following points could be cleared up too. Well if there is an OS, will there be a copy for every processor, will it be in shared (slooow) memory or will there be a processor running os code exclusively passing results to the other transputers. (all of the above methods sound not tooo great to say the least). Same for shared resources like graphics, I/O and stuff. How ? I had actually expected that the system would run more like this, A table with processes that are to be run. Lots of processors ( say 4 in the beginning, (- stolen from M.B.-)) grabbing processes that need to be run, swapping in the process space from disk (*) and executing those merrily. If we have 1MB per processor, we don't -quite- have Virtual Memory, but something inbetween, and it sounds quite Unix-like. Arguably it might not be the perfect thing to do for the transputer, neg- lecting maybe some hardware niceties. Natuerlich! (*) poor overworked HD -------------------------------------------------------------- Loveletters & Hatemail to : wallman@yalecs Files to : WALLMANN@CTSTATEU (Bitnet) Talk to : wallman@yale-zoo-suned.arpa --------------------------------------------------------------
david@bdt.UUCP (David Beckemeyer) (05/07/88)
In article <4679@batcomputer.tn.cornell.edu> braner@tcgould.tn.cornell.edu (braner) writes: >Helios is NOT Unix. Unix is NOT designed for a multiprocessor personal >machine, either. To quote a Helios document (by N.H. Garnett, Perihelion >Software): I'm sure a lot of people already know this, but for those that don't. There are multi-processor hacks of UNIX in development, even by some pretty major companies. Unix isn't designed for a multi-CPU system but it has been hacked to run on multi-CPU systems by basically dividing the kernel up and letting parts run concurrently. Some vendors have gone with "message passing". I know of at least one company putting in major efforts to get a multi-CPU version of BSD UNIX to run faster. -- David Beckemeyer | "To understand ranch lingo all yuh Beckemeyer Development Tools | have to do is to know in advance what 478 Santa Clara Ave, Oakland, CA 94610 | the other feller means an' then pay UUCP: ...!ihnp4!hoptoad!bdt!david | no attention to what he says"
hase@netmbx.UUCP (Hartmut Semken) (05/09/88)
In article <28623@yale-celray.yale.UUCP> wallman-george@CS.YALE.EDU (Natuerlich!) writes: >Well if there is an OS, will there be a copy for every processor, will it >be in shared (slooow) memory or will there be a processor running os code No. I wonder if there is some literature about the T's there in USA; we have the c't, a magazine writng a lot about them. T's are different. All resources are completely local (memory, I/O ..) and the T communicates over a serials line (with "DMA" and 5/10/20 Megabit per second). All shared devices (hard disk) are local to one transputer (call it a "server" or whatever you like). >exclusively passing results to the other transputers. (all of the above >methods sound not tooo great to say the least). Thats it! Think object-oriented: procedures for an objekt are residing in the transputer, messages between the objects are passed through the links. The T's have no support for virtual memory; I do'nt know who needs it. My OS/9 or RTOS systems have no VM and I like them for not wasting processor time in system-code... >Same for shared resources like graphics, I/O and stuff. How ? Like above. Nothing is "shared", everything is local (!). out of time hase -- Hartmut Semken, Lupsteiner Weg 67, 1000 Berlin 37 hase@netmbx.UUCP I think, you may be right in what I think you're thinking. (Douglas Adams)
fred@pnet01.cts.com (Fred Brooks) (05/11/88)
hase@netmbx.UUCP (Hartmut Semken) writes: >In article <28623@yale-celray.yale.UUCP> wallman-george@CS.YALE.EDU (Natuerlich!) writes: >>Well if there is an OS, will there be a copy for every processor, will it >>be in shared (slooow) memory or will there be a processor running os code >No. I wonder if there is some literature about the T's there in USA; we >have the c't, a magazine writng a lot about them. >T's are different. All resources are completely local (memory, I/O ..) >and the T communicates over a serials line (with "DMA" and 5/10/20 >Megabit per second). All shared devices (hard disk) are local to one >transputer (call it a "server" or whatever you like). >>exclusively passing results to the other transputers. (all of the above >>methods sound not tooo great to say the least). >Thats it! Think object-oriented: procedures for an objekt are residing >in the transputer, messages between the objects are passed through the >links. The T's have no support for virtual memory; I do'nt know who >needs it. My OS/9 or RTOS systems have no VM and I like them for not >wasting processor time in system-code... >>Same for shared resources like graphics, I/O and stuff. How ? >Like above. Nothing is "shared", everything is local (!). > >out of time >hase >-- >Hartmut Semken, Lupsteiner Weg 67, 1000 Berlin 37 hase@netmbx.UUCP >I think, you may be right in what I think you're thinking. (Douglas Adams) For info about transputers read the book 'PRINCIPLES OF PARALLEL AND MULTIPROCESSING" by Desrochers from McGraw Hill. UUCP: {cbosgd hplabs!hp-sdd sdcsvax nosc}!crash!pnet01!fred ARPA: crash!pnet01!fred@nosc.mil INET: fred@pnet01.cts.com
zs04+@andrew.cmu.edu (Zachary T. Smith) (03/17/89)
Anybody got any idea what ever happened to that xputer-based box Atari was gonna put out? I don't read ST magazines so this may seem a stupid question. Zach Smith (zs04@andrew.cmu.edu)