Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!pacbell.com!ucsd!ucrmath!koufax!rhyde
From: rhyde@koufax.ucr.edu (randy hyde)
Newsgroups: comp.sys.apple2
Subject: Re: HLLs vs. Assembly
Message-ID: <13275@ucrmath.ucr.edu>
Date: 4 Apr 91 00:01:24 GMT
References: <13156@ucrmath.ucr.edu> <1991Mar30.080418.16299@ee.ualberta.ca> <13202@ucrmath.ucr.edu> <15682@smoke.brl.mil>
Sender: news@ucrmath.ucr.edu
Reply-To: rhyde@koufax.ucr.edu (randy hyde)
Lines: 25

>>>
Thus, system overhead, at least on our UNIX systems, is close to negligible...
<<<

How did you come up with this?  Have you actually rewritten the kernel in
assembly and compared the difference?  Warm fuzzy feelings about it don't
count.

Now, perhaps, what you really mean to say is "Gee, we write all of our apps
in "C" and we write them in a sloppy fashion (i.e., slow).  They eat up so
much CPU time that the overhead of the O/S pales in comparison."

I could buy that.  However, it's not a good argument for writing OSes in
C.  Some of us *do* write very high performance software in assembly and don't
need boat anchors like UNIX slowing us down!

BTW, I recently rewrote a MINIX-based SCSI device driver in assembly
(the original
code was in C).  It actually took fewer lines of code (NS32532) and ran about
an order of magnitude faster.  While this is not an entire O/S, I suspect the
process manager would fare much better in assembly.  The memory manager
probably
would be better in assembly (warm fuzzy, I wouldn't bet anything on it).  The
file manager probably wouldn't gain much in assembly over C assuming the device
drivers were written in assembly.