Path: utzoo!utgpu!watmath!clyde!att!westmark!mole-end!mat
From: mat@mole-end.UUCP (Mark A Terribile)
Newsgroups: comp.lang.c
Subject: Re: Assembly or ....ok
Summary: The value of doing it right in the first place
Message-ID: <123@mole-end.UUCP>
Date: 18 Dec 88 21:20:16 GMT
References: <11915@cup.portal.com> <207600012@s.cs.uiuc.edu> <8215@ihlpl.ATT.COM>
Organization: mole-end--private system.  admin: mole-end!newtnews
Lines: 45

> > ... and they write *everything* in assembler. One of their products is
> > FlightSimulator (what MicroSoft puts name on ...). The object code for it
> > is far more than 1K long, and no compiler every matched it for speed or
> > compactness. ...  There is *no* way they could have been done in a
> > high-level language - the abuse of the machine features is amazing. ...
>  ...
> What is really extraordinary is that SubLogic's FS and FS-II have been
> ported to so many other machines besides the PClones. ... All these micros
> have features to "abuse" (love that term), but they're all different. ...
> I guess the projected sales of FS allowed them to throw enough bodies at
> the job to get it done.  Of course if the original ... source was well laid
> out and documented, porting ... is a lot easier than writing from scratch.
> But you have to discard the old "abuses" and come up with new ones.

Bear in mind something else:

	If the code is well structured at every level, with a minimum of hooks
from place to place, intelligible data structures (NOT an oxymoron even in
assembler) and a CLEAR, WELL-DEFINED PURPOSE for every section of code,
recoding from scratch to match the original design is a reasonable task.  One
of the critical parts of a project like that is understanding both the target
machine and the information that must be represented in the data structures
so that they can be used efficiently (whether by compiler-quality code or by
``abuses'') by ALL the code that must deal with them.  If the ugliness can
be pushed down into modules designed for speed, and the overall control is
seperated from the low-level control that must deal with the grunge, it's no
longer an impossible task.

	This, by the way, is NOT restricted to assembler: one of the grave
weaknesses that I have seen in many ``not-yet-expert'' programmers is the
inability to see how the data structures will affect the code that must use
them, and it's as much a problem in C or in Pascal.  In fact, it's worse in
Pascal.  That language's crippled expression syntax and data access
capabilities make it impossible to write reasonable code unless you get the
data structures perfect--an impossibility in code to which major new
``features'' must be added over time, along with new operations on the data
structures.

	Perhaps the biggest help I know to meeting the ``CLEAR, WELL-DEFINED
PURPOSE'' criterion is to write the code as if I would have to write a
manual page that would be tested for both clarity and correctness.
-- 

(This man's opinions are his own.)
From mole-end				Mark Terribile