Message-ID: <180@redwood.UUCP>
Date: Fri, 1-Mar-85 19:11:59 EST
Article-I.D.: redwood.180
Posted: Fri Mar  1 19:11:59 1985
Date-Received: Mon, 4-Mar-85 20:32:53 EST
References: <143@idmi-cc.UUCP> <810@sjuvax.UUCP> <56@daisy.UUCP> <287@cmu-cs-k.ARPA> <77@daisy.UUCP>
Organization: [Consultant], Foster City, CA
Lines: 65
Xref: watmath net.micro:9585 net.micro.pc:3435

David Schachter says in <77@daisy.UUCP>:
+---------------
| Large address spaces are convenient.  They are not essential.  Moreover, their
| convenience can rob you of the incentive to get maximum performance.  The
| Intel architecture is a dark cloud with a silver lining: the need to keep
| within the small address space frequently causes us to find solutions that are
| smaller and faster, helping us meet our performance goals.
+---------------

As much as I dislike the 8086 architecture (for more reasons than the
segment size), I must agree that David has a good point, though it will
certainly be counter-intuitive to those who have not "been there".

We found the same thing to be true many years ago in the PDP-8/PDP-11
wars -- by comparison to the PDP-8, the PDP-11 has "infinite" linear
address space (at least that was the feeling at the time), yet PDP-8
code was quite often faster and smaller. Why? Because -- and this has
NOT changed even today -- the PDP-8 prgrammers had to look at their
code over and over again, to get it to fit in the 128-word page (and
4096-word field) boundaries. In the process of re-reading, they saw
better ways to do things (i.e., algorithms, data structures), which
were BOTH smaller and faster (and in many cases more reliable).

A similar effect was noticed some years later when DEC first started
using BLISS-10 to code compilers and other system utilities on the
PDP-10.  People started complaining, "BLISS code is so BIG!", even
though the compiler generated reasonably good code? What was going on?

Two things: (1) by writing in BLISS instead of assembler, programmers
were able to conceive of bigger things, fancier code optimization in
the FORTRAN compiler for example, so they did them; and (2) the BLISS
code was more reliable (during development, at least), so the programmers
didn't have to do as much debugging and hence DIDN'T READ THEIR OWN
CODE as much. As a result, the usual re-writing that accompanies the
re-reading simply didn't happen! (I presented the latter point at a
DECUS meeting as "Warnock's Principle of Why BLISS Programs Are Big". ;-}
But I wasn't kidding all that much.)

We will see the same phenomenon today with "C" on PCs as programmers
move from assembler. (This is in addition to the problem that "C" on
most PCs generates fat code.) We have already seen it in UNIX. When
a program is re-read and tuned and massaged it gets better, and it
doesn't matter whether the reason it was looked at was that it didn't
fit a space or time constraint, or that it simply had a few bugs in it
(although the buggy program is also more likely to have bugs in the
shipped version!).  When it is simply hacked out and never looked at
again, it is huge and slow.

The very act of re-reading is "good" for program quality. The challenge
is to structure our organizations so that we ensure that programs are
read and re-read and that the resulting improvements are incorporated --
DESPITE the pressures to "ship it", even WITHOUT ugly machine architectures
squeezing us, WITHOUT funny address space glitches, WITHOUT defects to
force us to "de-bug" (remove the mistakes we put in) -- in short, to
ensure that we consciously exercise programming discipline even in a
hospitable environment (where, too often, we simply "flop"). Then our
productivity will be high and our customers happy.


Rob Warnock
Systems Architecture Consultant

UUCP:	{ihnp4,ucbvax!dual}!fortune!redwood!rpw3
DDD:	(415)572-2607
USPS:	510 Trinidad Lane, Foster City, CA  94404

Message-ID: <8989@brl-tgr.ARPA>
Date: Wed, 6-Mar-85 11:08:53 EST
Article-I.D.: brl-tgr.8989
Posted: Wed Mar  6 11:08:53 1985
Date-Received: Sat, 9-Mar-85 19:55:22 EST
Sender: news@brl-tgr.ARPA
Lines: 27

You bring up lots of good points.  I've been becoming greatly involved
with Ada, and, with the current state of the Ada compilers, I've gotten
into a mode of not considering code efficiency and considering more the
readability, modularity, maintainability, etc of the code and the application
of object-oriented programming design methodology.  However, if you turn
around and look at the size of the object code, on the Data General MV10000,
for example, I commonly see 150K+ and 300K+ executable images
being generated from my little 200 or 1000 line programs.  DEC Ada has
been quite a different story, with 15K EXE files poppng up from
similar code (altho I suspect something large is coming in at execution
since I commonly see 10K+ page faults during a run).  I haven't studied
the question in enough detail to give more than this cursory exam, and I
suspect that as the Ada compiler technology matures, we will find more
efficient code generation.  It will be very interesting to see what the
ALSYS 8086 and 68000 efforts generate.  It will also be interesting to
see what happens when compilers load only those parts of a package that
they need rather than the whole package; right now, it looks like the DG
loads all of TEXT_IO, and this has got to be a lot of code.

Anyway, we will see with time.  Ada is targeted to embedded
applications and processors, and my current idea of such a processor is
NOT a VAX 11/780 with 2G bytes of disk.  Ada is such
a neat language when you don't look at the code sizes that I hope this
problem can be overcome.

	Rick
-------

Message-ID: <8990@brl-tgr.ARPA>
Date: Wed, 6-Mar-85 11:09:00 EST
Article-I.D.: brl-tgr.8990
Posted: Wed Mar  6 11:09:00 1985
Date-Received: Sat, 9-Mar-85 19:55:48 EST
Sender: news@brl-tgr.ARPA
Lines: 16

By the way, there is an Ada Repository now on SIMTEL20 if anyone wants
to take a look at Ada source.  It's surprising how readable it can be even
if you don't know Ada -- writing in Ada is where the language knowledge comes
in.

The repository is in MICRO: (ADA.CRCLST is at this level>, and the
subdirectories MICRO: and MICRO: contain
software.  There is a mailing list that you can subscribe to by sending
a request to ADA-SW-REQUEST@SIMTEL20 if you want to be kept posted
on new submissions.  A large set of tools, the NOSC toolset, will be
added to the repository over the next few months, and this includes
things such as virtual terminal packages (ala the UNIX TERMCAP
perhaps), FORMS generators, spelling checkers, style checkers, etc.

	Rick
-------