Xref: utzoo comp.arch:5825 comp.software-eng:718
Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!ames!elroy!mahendo!wlbr!scgvaxd!trwrb!aero!venera.isi.edu!raveling
From: raveling@vaxb.isi.edu (Paul Raveling)
Newsgroups: comp.arch,comp.software-eng
Subject: Re: using (ugh!  yetch!) assembler
Message-ID: <5999@venera.isi.edu>
Date: 29 Jul 88 18:49:49 GMT
References: <60859@sun.uucp> <474@m3.mfci.UUCP> <2926@utastro.UUCP> <37014@linus.UUCP> <9763@eddie.MIT.EDU> <37247@linus.UUCP>
Sender: news@venera.isi.edu
Reply-To: raveling@vaxb.isi.edu (Paul Raveling)
Organization: USC-Information Sciences Institute
Lines: 79

In article <37247@linus.UUCP> munck@linus.UUCP (Robert Munck) writes:
>In article <9763@eddie.MIT.EDU> jbs@fenchurch.MIT.EDU (Jeff Siegal) writes:
>
>>This just isn't true.  There are an aweful lot of real live products,
>>and BIG ones, that have been built in assembly language.  Have you
>>read _The_Mythical_Man-Month_?  5000 man-years it did take, but OS/360
>>was a whole bunch of assembly code (millions of lines, minimum) that
>>has probably made IBM billions.
>
>Nah. Some of you may not have been born yet then, but I was one of the
>first non-IBMers to sysgen OS/360 rel 1 (PCP) in 1966 or so, and

	Me too.

>probably as familiar with the source code of OS, releases 1 .. 21, as anyone

	Once I was, but I wanted to forget them as fast as possible.

> ...  It was, of
>course, "disassemblies" of the output of the legendary BSL compiler (Basic
>Systems Language, later PL/0).  By Release 14 (that great release; I
>think Yale is STILL running it), all new modules were BSL.

	I don't recall noticing those features, but maybe that explains
	why so much of that code was so awful.  On the other hand,
	those comments the code generator stuck on the right side
	of instructions would be the envy of both our natural language
	synthesis group and someone else's compiler group.  Maybe
	we tended to work in different parts of OS/360.
	
	The first code I can guarantee wasn't hand-coded assembly
	language was the PL/S that began creeping in around Release 18
	(plus or minus epsilon).  It was such a curiosity that I
	immediately looked at some and spotted a bug within 5 minutes.

	An exception would be compilers such as FORTRAN H, which
	used a lot of FORTRAN.

>>I write a 25000 line assembly program (for a class) about 4 years ago
>>that was well organized, documented, etc.  I have no doubt that it
>>could be modified and maintained today (or 10 years from now).
>
>How about moved to another CPU?

	Portability is the biggest argument for avoiding assembly.
	It IS feasible to write well-documented, easily maintainable
	assembly code.  Anyone with a performance-critical application
	should consider it; in my experience it takes around 20%
	more time to write in a decent assembly language than in
	a decent higher level language, and the code runs about
	3 times faster... Unless the high level language is LISP -
	then the speed ratio is about an order of magnitude.

	A notable exception is a crummy machine language, such as
	Intel's 8*86's.  Over my 8 years of having to deal with these
	atrocities, it probably took at least twice as much time to
	produce "good machine language code" as it did to produce
	equivalent C.  (The 8*86 architecture doesn't really allow producing
	"good machine language code" by comparison with most other
	hardware architectures.)

>Yeah, sure, it's possible to write
>organized, maintainable assembly code (though the concepts of
>"maintenance" and "documentation" at universities are VERY different
>from the commercial and military worlds.)  Real-world schedule and
>funding pressures make it very unlikely that it would stay organized,
>documented, and maintainable for very long after release.

	In my experience in all three worlds, the best documentation
	has tended to be found in the commercial world.  The most
	documentation was in the MIL-spec world, but the requirement
	was for so much of it that it was a miracle if a substantial
	part matched the actual system.  The university world, or
	at least the part whose software I've seen lately, produces
	minimal documentation, and what exists is of little use.


---------------------
Paul Raveling
Raveling@vaxb.isi.edu