Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!ncar!tank!uxc!uxc.cso.uiuc.edu!m.cs.uiuc.edu!s.cs.uiuc.edu!carroll
From: carroll@s.cs.uiuc.edu
Newsgroups: comp.lang.c
Subject: Re: Assembly or ....ok
Message-ID: <207600012@s.cs.uiuc.edu>
Date: 6 Dec 88 20:49:00 GMT
References: <11915@cup.portal.com>
Lines: 25
Nf-ID: #R:cup.portal.com:11915:s.cs.uiuc.edu:207600012:000:1556
Nf-From: s.cs.uiuc.edu!carroll    Dec  6 14:49:00 1988


/* Written 10:02 pm  Dec  5, 1988 by stachour@umn-cs.CS.UMN.EDU in s.cs.uiuc.edu:comp.lang.c */
One of the important parameters is the "size of the program".
When I was working at IBM in the early 1970's, we had an
outstanding "bet" as to whether anyone could outdo the PL/S compiler
on a "non-trivial" program (defined as one that took more than
1K bytes of 360-assembler to write).  We had a number of challenges.
We never lost. (...)
/* End of text from s.cs.uiuc.edu:comp.lang.c */

Fascinating. I worked at SubLogic for a summer, and they write *everything*
in assembler. One of their products is FlightSimulator (what MicroSoft puts
their name on and sells as if they wrote it). The object code for it is
far more than 1K long, and no compiler every matched it for speed or
compactness. In fact, one of the reasons for the success of the company is
that the speed critical routines (such as the 3D-2D perspective transforms)
worked so fast. There is *no* way they could have been done in a high-level
language - the abuse of the machine features is amazing. I personally have
written assembly programs for the 3b2 that were re-writes of C code (part
of a class I TA'd), and we generally got a 3-10 times speed up. We had
challenges in class too, and the assembler whipped the compiler every time,
for code much longer than 1K.

Alan M. Carroll          "How many danger signs did you ignore?
carroll@s.cs.uiuc.edu     How many times had you heard it all before?" - AP&EW
CS Grad / U of Ill @ Urbana    ...{ucbvax,pur-ee,convex}!s.cs.uiuc.edu!carroll