Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!mimsy!chris
From: chris@mimsy.umd.edu (Chris Torek)
Newsgroups: comp.arch
Subject: Re: Are RISC programs bigger than CISC? (Summary)
Message-ID: <21913@mimsy.umd.edu>
Date: 18 Jan 90 20:38:52 GMT
References: <1747@petsd.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 28

In article <1747@petsd.UUCP> joe@petsd.UUCP (Joe Orost) quotes
june.cs.washington.edu!noah:
>We found that the Ultrix kernel on our DECStation 3100s is almost three
>times bigger than on our MicroVAX IIIs.

On my 3100 the kernel is ~1 MB.  The Ultrix kernel on cmvax (a 6210
here) is also ~1 MB.  The 6210 kernel is compiled with larger tables;
a smaller machine might have a .8 or .9 MB Ultrix kernel.  Do not be
fooled by `ls -l /vmunix': the MIPS binaries have an incredible amount
of data stored in symbol tables, for debugging.

(Among other things, the MIPS does not use a frame pointer, so in
order to do stack tracing, the symbol table includes a `virtual frame
pointer' as an offset from the stack pointer, along with `virtual
register save masks' so that the debugger can figure out which registers
to `restore' when moving up through the call stack.)

The Ultrix kernel is ~1 MB mainly through sloppiness: I rewrote one
driver (the QDSS driver), maintaining complete backwards compatibility,
and cut it down to about 1/3 its original compiled size.  Most of the
code is not that bad, but I would guess that it could be reduced at
least 30% by rewrites.  (But which would DEC rather have: a `same'
kernel, with the bugs moved around a bit, that was 30% smaller, or
a `more functional' kernel, with new bugs, that was larger?  Smaller
does not sell well.  VMS compatibility sells.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris