Unix optimized for SPARC?

[John Mashey]

In article <253 at iconsys.UUCP> ron at 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: <generic disclaimer, I speak for me only, etc>
UUCP: 	{ames,decwrl,prls,pyramid}!mips!mash  OR  mash at mips.com
DDD:  	408-991-0253 or 408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086