rhg@cpsolv.CPS.COM (Richard H. Gumpertz) (09/03/90)
What are the advantages and disadvantages of the AMD 29000 as the processor for a Unix workstation? Are there any products out there using the 29K? If not, why not? Is there something about the architecture that makes people avoid it? I have not been regularly reading comp.arch for a while so I apologize if this brings up issues already discussed. Feel free to reply specifically to me by e-mail. -- ========================================================================== | Richard H. Gumpertz rhg@CPS.COM (913) 642-1777 or (816) 891-3561 | | Computer Problem Solving, 8905 Mohawk Lane, Leawood, Kansas 66206-1749 | ==========================================================================
mslater@cup.portal.com (Michael Z Slater) (09/05/90)
>What are the advantages and disadvantages of the AMD 29000 as the processor >for a Unix workstation? Are there any products out there using the 29K? If >not, why not? Is there something about the architecture that makes people >avoid it? The disadvantage of the 29000 for Unix workstations is that there is no Unix port! This has nothing to do with the architecture, but is a marketing decision that AMD made a couple years ago. With SPARC and MIPS looking very strong in the Unix arena, and with the importance of building a base of third-party software for Unix workstations, AMD decided to focus all their efforts on { embedded applications. I think it was a wise choice. Does anyone know of any real architectural reasons why the 29K Unix port was never completed? Michael Slater, Microprocessor Report mslater@cup.portal.com
rpw3@rigden.wpd.sgi.com (Rob Warnock) (09/06/90)
In article <33558@cup.portal.com> mslater@cup.portal.com (Michael Z Slater) writes: +--------------- | >What are the advantages and disadvantages of the AMD 29000 as the processor | >for a Unix workstation? Are there any products out there using the 29K? If | >not, why not? Is there something about the architecture that makes people | >avoid it? | The disadvantage of the 29000 for Unix workstations is that there is no | Unix port! +--------------- Weeelll... that's not quite true. In point of fact, there were *two* Unix ports to the 29k, a S5R3 done by UniSoft under contract from AMD, and a 4.3bsd done by three consultants to AMD [I was one of them]. The hardware environment for both was AMD's "PCEB/29k" card plugged into a PC clone. [The Unix root & swap partitions were MS-DOS files.] Both ports progressed at least to the point where you could: $ ed foo.c ...type a bit... $ cat foo.c main () { printf("Hello, world!\n"); } $ cc -O -o foo foo.c $ foo Hello, world! $ Neither was "finished" to the point that anyone would call it production software. As far as I know, both are still available, in one form or another, from AMD. In the S5R3 case, additional arrangements must be made with UniSoft. The 4.3 port is available from AMD under the usual "show me your Unix source license" arrangement for BSD tapes. [The last contact I had was Daniel Mann <danm@cancun.amd.com>.] +--------------- | This has nothing to do with the architecture, but is a marketing decision | that AMD made a couple years ago. +--------------- Correct. *After* both ports had reach the state described above. +--------------- | With SPARC and MIPS looking very strong in the Unix arena, and with the | importance of building a base of third-party software for Unix workstations, | AMD decided to focus all their efforts on embedded applications. +--------------- Correct again. [There came a period of time when one hesitated to speak "the U word" too loudly... ;-} ;-} ] +--------------- | I think it was a wise choice. +--------------- [No comment.] +--------------- | Does anyone know of any real architectural reasons why the 29K Unix port | was never completed? +--------------- Quite the contrary -- the 29k is a *dandy* Unix engine! The light-weight interrupt mechanism, together with the software-defined stack, made it possible to make interrupts and system calls *very* efficient. By "cutting" to stack to the kernel "upage" stack but continuing to use the current register window set, only a very few registers needed to be saved/restored for an interrupt or system call. A typical "trivial" system call, say a non-optimized "getppid()", took about four microseconds total. Only when a full process context switch was needed (e.g., reschedule) did all the registers have to be saved/restored. The "two stacks" (normal "large object" memory stack and register-window backing-store stack) did offer some challenges, but it was tractable enough. The integral MMU -- actually a software-managed TLB -- allows one to play the usual Unix VM games. In the 4.3 port, we sort of emulated VAX paging, just to make the port easy, but with some added wrinkles. For example, since TLB reloads are explicit, you can easily synthesize "referenced" and "dirty" bits in the (virtual) MMU, by taking notes during TLB reload traps. Finally, the light-weight interrupt mechanism fit hand in glove with one of my favorite schemes: two-level interrupt service (about which I have spoken here at great length in times past). This permits efficient "pseudo DMA", as well as allowing "real time" functions to co-exist with Unix. So, as you said above, AMD's de-emphasis of 29k Unix had "nothing to do with the architecture"... -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311
phil@brahms.amd.com (Phil Ngai) (09/07/90)
In article <33558@cup.portal.com> mslater@cup.portal.com (Michael Z Slater) writes: |The disadvantage of the 29000 for Unix workstations is that there is no |Unix port! | |This has nothing to do with the architecture, but is a marketing decision |that AMD made a couple years ago. With SPARC and MIPS looking very strong |in the Unix arena, and with the importance of building a base of third-party |software for Unix workstations, AMD decided to focus all their efforts on { |embedded applications. I think it was a wise choice. | |Does anyone know of any real architectural reasons why the 29K Unix port was |never completed? I don't speak for AMD but I also think it was a wise marketing decision for AMD to stop chasing Unix, and that's what it really is, a constant chase. We had the beginning of a System V port, but it was 5.2. At the time, we were looking at big bucks for a 5.3 port, we already knew that 5.4 would be coming out and I also knew about the beginning of OSF. We also had the beginning of a BSD port but it was clear that enormous manpower would be needed to support it and that SPARC was probably going to own the Unix world anyway. If we could have just paid 1/4 of a million dollars to start a Unix port and let it grow on its own I'm sure we would have done that but it was clear that playing in the Unix game takes multi-mega bucks and it did not seem economically prudent to fund it. We even had a working DOS emulator which ran Lotus 123, but again, we would only have lost money at it. We are looking at embedded controller stuff and anyone who has a kernel with TCP that would be interested in a relationship with us should get in touch. -- Phil Ngai, phil@amd.com {uunet,decwrl,ucbvax}!amdcad!phil