To:	bscholl AT eznet DOT net
Cc:	Gremlin AT f20 DOT n396 DOT z1 DOT fidonet DOT org, opendos AT delorie DOT com
Subject:	Re: source code
Message-ID:	<19970921.154807.6423.0.editor@juno.com>
References:	<Pine DOT LNX DOT 3 DOT 95 DOT 970921144313 DOT 30507C-100000 AT shell1 DOT eznet DOT net>
From:	editor AT juno DOT com (Bruce Morgen)
Date:	Sun, 21 Sep 1997 15:49:27 EDT

On Sun, 21 Sep 1997 14:48:07 -0400 (EDT) Ben Schollnick
<bscholl AT eznet DOT net> writes:
>
>>        For something like OS, isn't ASM a *good* thing?  I know very 
>little 
>> about assembly, but isn't it the language that can best access the 
>computer 
>> directly?  I thought you would want that in an OS...?
>
>The nice thing about assembly is that it forces the programmer to
>concentrate on what is the *GOAL*, and the quickest "path" to the 
>goal.
>
>The disadvantage is that it is hard to mantain.
>
>Most high level programming languages (these days) can convert code to
>assembly/machine language to roughly the same degree of optimization.  
>(IE
>Borland pascal / Borland C++ will run roughly the same speed with THE 
>SAME
>ALGORTHIUM)....
>
>So, if you can optimize the algorithiu, sure it'll be slightly slower 
>than
>assembly (maybe by 5%? depending on application), but it'll be easier 
>to keep upgraded...
>
Properly commented assembler isn't 
hard to maintain at all *if* the 
maintainer is an adept assembler 
jockey.  Moreover, although the 
speed advantage of assembler isn't 
worth much with 386 and newer CPUs, 
the *code size* advantage is still 
considerable, and this is important 
for managing the disk and RAM 
footprints of the two resident DOS 
modules.  I wrote quite a few 
utilities back in the CP/M era, and 
most of them wound up being 
effectively upgraded/maintained by 
other people -- conversely, I often 
fixed/improved other people's work 
in assembler without undue 
difficulty given adequate commenting 
and a non-spaghetti coding style.

On the other side of the coin, I've 
seen *ludicrous* results from some 
assembler-to-C++ conversions.  I 
consulted for a network company that 
had its control utilility translated 
into C++ and a bunch of command line 
options added -- the tool went from 
32K to 222K in a single rev.!  This 
is no big deal for the general 386+ 
PC marketplace, but for folks using 
slow CPUs or in situations where 
disk space is tight its bad news.

- Raw text -