Path: utzoo!attcan!uunet!wyse!mips!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.unix.wizards Subject: Re: Unix optimized for SPARC? Message-ID: <2482@winchester.mips.COM> Date: 1 Jul 88 01:30:52 GMT References: <253@iconsys.UUCP> Reply-To: mash@winchester.UUCP (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 55 In article <253@iconsys.UUCP> ron@iconsys.UUCP (Ron Holt) writes: > >Recently, there has been fear expressed that evil AT&T and Sun will >some how optimize future versions of Unix for SPARC. Considering the >portability of Unix being one of its best known traits, wouldn't this >be rather difficult to do? I wouldn't consider BSD optimized for the >VAX nor SVR3 optimized for the 3B2 even though these machines were >used as the porting bases for their respective Unix variants. Of course, >there are very machine specific sections of the Unix kernel, the VM code >being a good example, but other than that, how could Unix be optimized >for SPARC? From outside, there are two issues: a) The marketing one: some of the Sun sales/marketing materials we've seen have explicitly said "standard UNIX would be optimized for SPARC", including Bernie LaCroute's page in the SunTechnology magaizine of January or February. At least some Sun engineers expressed mystification to me as to what this was about, given that they needed to support SunOS on at least 2 other architectures :-) b) There are certainly restructurings of the kernel that might be more conducive to SPARC (of which the SunOS crew is certainly aware). I can think of ways to restructure the kernel to help performance on SPARC. Depending on how they were done, they could either be neutral with regard to other OSs, or slightly negative; one would assume that people will not make changes that damage 68K or 386 performance. There are 2 instantly obvious changes: a) [SPARC-specific]: macro-ize or otherwise restructure the kernel to lessen the dynamic depth of function calls. When I've watched kernels go, they quite often end up 10-12 deep inside the kernel, plus 3-5 deep (fairly quickly) in the user program. This of course is the reverese of the directionthat the kernel has been going, i.e., with more layers and indirects for cleaner structuring. b) [not SPARC-specific, but relevant]: handle the u_area differently. The kernel's habit of mapping the u_area into the same kernel-virtual address causes painful problems in context-switching for virtual address+virtual tag machines of some kinds, i.e. you need to flush cache pages on each context switch. This is NOT specific to SPARC [the 3/2xx has the same issue], but is relevant, since: a) THe faster the machine gets, the larger hit you take from cache-flushing activities and resulting misses. b) Most other RISC machine don't use the kind of virtual-virtual caches that current SPARC implementations do, so they don't have the problem; hence any overhead introduced to solve this problem may get in the road. (I don't think this is a big issue, as UNIX needs to get restructured carefully to handle different flavors of cache and MMU design better anyway.) -- -john mashey DISCLAIMER:UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086