Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site harvard.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!macrakis
From: macrakis@harvard.UUCP (Stavros Macrakis)
Newsgroups: net.lang
Subject: Re: structured assembler
Message-ID: <697@harvard.UUCP>
Date: Mon, 10-Feb-86 12:30:57 EST
Article-I.D.: harvard.697
Posted: Mon Feb 10 12:30:57 1986
Date-Received: Wed, 12-Feb-86 07:41:57 EST
References: <350@3comvax.UUCP> <463@kontron.UUCP> <1078@mmintl.UUCP> <409@3comvax.UUCP>
Distribution: net
Organization: Aiken Comp. Lab., Harvard
Lines: 66
Summary: Assembler loses to high-level languages

> ... user-friendliness has become a big issue in the software world ...  a
> speedy program that takes less resources is much friendlier than the
> 'C' equivalent.

Sometimes speed and size matter, sometimes not.  Often other things
are more important, such as functionality, capacity, and time to
market.

>  Why not have an assembler with data structures?

It's called C.

> I agree that people time is very important, but not programmer time.  I
> don't see how it is beneficial to save a programmer a month's worth of
> work when the result is a program that costs the rest of the world that
> uses it a MUCH larger agregate time ...

The `world' may not be willing to wait the extra 6 months of
development time, and will probably not tolerate the additional bugs.
It depends on the market.  If you're selling the fastest program in a
category, you may want to write much of it in assembler.  If, on the
other hand, you want to be the first one out, or you're selling the
one with the most functionality, and you wouldn't be able to ship in
time if you wrote in assembler, you presumably write in a higher-level
language.

> The main benefit to using a high-level language is the fancy library
> routines that automatically get linked in and make your programs
> larger.  ... The other high-level features like if-then-else, etc.,
> are simple macros to a structured assembler, so that stuff is not
> lost.

An interesting perspective.  As for me, I'm rather fond of such
high-level language facilities as type checking, interface consistency
checking, sensible scoping rules, and so on, which have ZERO runtime
cost, as well as such facilities as machine independence, automatic
register allocation, ..., some of which cost a bit of machine
efficiency, others of which gain some (take a look at the output of
the PQCC compiler sometime and tell me you could have coded it up
better yourself).  Much of your argument, I suspect, would go away
with better compilers.

Your example of `optimizing' C programs by using static rather than
stack storage is peculiar.  As you say, your code precludes recursion
or reentrancy.  On our 780, it also runs at about the same speed as the
stack, but is 4 bytes longer in the caller, and 8 bytes longer in the
callee.  It has worse cache and paging behavior as well.  I don't see
the advantage.

Note also that static parameter areas require you to provide space for
the entire possible call tree, while stack parameters need only the
size of the longest path to the root of the call graph.  Alternatively,
you can overlap usage of the parameter areas.  This is extremely
error-prone.

It's interesting that you should attribute the difference in speed and
size between MS-DOS and the Mac OS to the language in which they are
written.  Without a comparison of the functionality, I don't see the
point.

Certainly there are cases where assembler can contribute efficiency.
In other cases, all it does is make development slower and more
expensive.  And machine efficiency is not the only measure of the
value of software.

	-s