Newsgroups: comp.os.mach Path: utzoo!utgpu!watserv1!watdragon!rose!ccplumb From: ccplumb@rose.uwaterloo.ca (Colin Plumb) Subject: Re: Bytes in Mach 3.0? Message-ID: <1991Feb18.033855.4864@watdragon.waterloo.edu> Sender: daemon@watdragon.waterloo.edu (Owner of Many System Processes) Organization: University of Waterloo References: <2981@fai.UUCP> <1991Feb13.170901@ibmpa.awdpa.ibm.com> <1991Feb14.220240.26795@ico.isc.com> <62753@bbn.BBN.COM> <1991Feb15.214231.21348@watmath.waterloo.edu> Date: Mon, 18 Feb 1991 03:38:55 GMT Lines: 37 >> In article <1991Feb14.220240.26795@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: >>> My confusion stems from the understanding that the Mach 3.0 kernel >>> is supposed to be the "micro-kernel" version, and the belief that a 240 Kb >>> kernel cannot reasonably be labeled "micro". I must agree. For all the VM functionality in Mach, I'll allow it 128 K but wish for less. Something is seriously wrong with 240K. gamiddle@watmath.waterloo.edu (Guy Middleton) wrote: >I don't think it is all that small. 4.3bsd on a VAX has text of similar size: > >text data bss dec hex >229784 166320 90048 486152 76b08 > >Note that it is probably more fair to compare 386 with VAX binaries than with >SPARC, MIPS or HP-PA, since RISC code tends to occupy more space. Another VAX, same site, different configuration:: text data bss dec hex 220608 82548 66860 370016 5a560 4.3BSD on an HP 9000/236 (68010): text data bss dec hex 246752 27392 54152 328296 50268 The larger test size is probably due to debugging code; the system is a bit flaky... We need the old utzoo, which was constrained to 64K split I&D. For comparison, a system V release 4 /unix on a 68030: text data bss dec hex 702704 117252 313936 1133892 114d44 Ouch! -- -Colin