munck@linus.UUCP (Robert Munck) (07/28/88)
In article <9763@eddie.MIT.EDU> jbs@fenchurch.MIT.EDU (Jeff Siegal) writes: >In article <37014@linus.UUCP> munck@faron.UUCP (Robert Munck) writes: >>[...]assembly language will "fit" only >>the smallest, most toy-like, never-to-be-used-for-real prototypes. >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 probably as familiar with the source code of OS, releases 1 .. 21, as anyone. Sure, it was assembler in the early days. Remember, OS/360 was written in the early and mid sixties, before the "age of compilers." The OS (not counting linkers, utilities, etc.) was maybe as big as 500K lines of assembler. Pretty soon, however, the source listings in the microfiche started to look a bit strange. Labels like "L000213#", loading a register with the value it already contained, etc. 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 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? 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. After that, it's a long, slow slide to certain death (death: the time when fixing one bug introduces, on the average, 1+epsilon new bugs). There are a lot of personal computer products out there written in assembler and doing well; companies dependent on such products have, in effect, taken a very slow-acting poison. -- Bob Munck, MITRE Corporation -- ..!linus!munck.UUCP, munck@mitre-bedford.ARPA
sl144003@silver.bacs.indiana.edu (07/29/88)
/* Written 11:24 am Jul 28, 1988 by munck@linus in silver:comp.software-eng */ /* ---------- "Re: using (ugh! yetch!) assembler" ---------- */ In article <9763@eddie.MIT.EDU> jbs@fenchurch.MIT.EDU (Jeff Siegal) writes: >In article <37014@linus.UUCP> munck@faron.UUCP (Robert Munck) writes: >>[...]assembly language will "fit" only >>the smallest, most toy-like, never-to-be-used-for-real prototypes. >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 probably as familiar with the source code of OS, releases 1 .. 21, as anyone. Sure, it was assembler in the early days. Remember, OS/360 was written in the early and mid sixties, before the "age of compilers." The OS (not counting linkers, utilities, etc.) was maybe as big as 500K lines of assembler. Pretty soon, however, the source listings in the microfiche started to look a bit strange. Labels like "L000213#", loading a register with the value it already contained, etc. 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 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? 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. After that, it's a long, slow slide to certain death (death: the time when fixing one bug introduces, on the average, 1+epsilon new bugs). There are a lot of personal computer products out there written in assembler and doing well; companies dependent on such products have, in effect, taken a very slow-acting poison. -- Bob Munck, MITRE Corporation -- ..!linus!munck.UUCP, munck@mitre-bedford.ARPA /* End of text from silver:comp.software-eng */
elg@killer.DALLAS.TX.US (Eric Green) (07/29/88)
In message <37247@linus.UUCP>, munck@linus.UUCP (Robert Munck) says: >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. After that, >it's a long, slow slide to certain death (death: the time when fixing >one bug introduces, on the average, 1+epsilon new bugs). > >There are a lot of personal computer products out there written in >assembler and doing well; companies dependent on such products have, in >effect, taken a very slow-acting poison. Note that, until recently, it was impossible to have a commercial-quality product written in a high-level language on a personal computer. 8-bit microcomputers such as the Z-80, 6502, or 8088 are very difficult to generate reasonable code for. Microsloth(tm) took years to get their "C" compiler generating even reasonably efficient code, and it still could use a lot of improvement. However, from what I hear, Microsoft is saying that further optimization will require AI techniques and a more powerful machine than the 8088 (because of both the speed and memory requirements of such a compiler). It's easy for us, using high-powered minicomputers or 68000-based machines, to say "Using assembler is slow death". Heck, even a simplistic compiler for the 68000 can generate decent code (e.g. the Manx C68K compiler -- very small, very simple, does almost no optimizations, and the code is reasonable, though far from optimal). But the majority of the people in the PC world still are not so lucky.... -- Eric Lee Green ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg Snail Mail P.O. Box 92191 Lafayette, LA 70509 MISFORTUNE, n. The kind of fortune that never misses.
john@anasaz.UUCP (John Moore) (07/29/88)
In article <37247@linus.UUCP% munck@linus.UUCP (Robert Munck) writes: %In article <9763@eddie.MIT.EDU% jbs@fenchurch.MIT.EDU (Jeff Siegal) writes: % %%In article <37014@linus.UUCP% munck@faron.UUCP (Robert Munck) writes: %%%[...]assembly language will "fit" only %%%the smallest, most toy-like, never-to-be-used-for-real prototypes. If you ever make an airline or hotel reservation, or use a credit card and have an authorization check run on it, you are making use of very large systems written entirely in assembly language! These systems are based on IBM's TPF (previously ACP - Airline Control Program). They may contain millions of lines of applications code. Likewise, if you fly in an airplane at one of the airports with the older ARTS traffic control computers, you are again depending on a large assembly language system. None of this is to imply that assembly language is a good way to do applications! Just to show that some extremely large systems are done that way. -- John Moore (NJ7E) {decvax, ncar, ihnp4}!noao!nud!anasaz!john (602) 861-7607 (day or eve) {gatech, ames, rutgers}!ncar!... The opinions expressed here are obviously not mine, so they must be someone else's.
raveling@vaxb.isi.edu (Paul Raveling) (07/30/88)
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
hollombe@ttidca.TTI.COM (The Polymath) (08/03/88)
In article <1148@anasaz.UUCP> john@anasaz.UUCP (John Moore) writes: }None of this is to imply that assembly language is a good way to do }applications! Just to show that some extremely large systems are done }that way. Another example: Most of the code in the Space Shuttle's on board computers is written in assembler. I know because I once had to document a large chunk of it (the Initial Program Load (IPL) module). -- The Polymath (aka: Jerry Hollombe, hollombe@ttidca.tti.com) Illegitimati Nil Citicorp(+)TTI Carborundum 3100 Ocean Park Blvd. (213) 452-9191, x2483 Santa Monica, CA 90405 {csun|philabs|psivax}!ttidca!hollombe
henry@utzoo.uucp (Henry Spencer) (08/03/88)
In article <1148@anasaz.UUCP> john@anasaz.UUCP (John Moore) writes: >If you ever make an airline or hotel reservation, or use a credit card >and have an authorization check run on it, you are making use of very >large systems written entirely in assembly language! ... If I'm not mistaken, Sabre (American Airlines) for one is written in a PL/I variant and has been for many years. They got burned by the conversion to the 360 and swore that they would never again write in assembler. -- MSDOS is not dead, it just | Henry Spencer at U of Toronto Zoology smells that way. | uunet!mnetor!utzoo!henry henry@zoo.toronto.edu
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/03/88)
One of the claimed advantages of assembler is that you can't get
burned by changes in the compiler causing bad code. Unfortunately
assemblers do generate bad code, too, on occasion. One example was the
GMAP assembler for the GE600. Certain instructions mush be in odd
locations, such as RPD, and in some cases that was not forced. I think
it was if the RPD was the result of the expansion of a macro or
something, but it was 20+ years ago.
The Intel assembler for the 80386 still recognizes several bit
load/store instructions which have been removed from the chip. I doubt
that anyone outside of Intel ever used them, but unknown instructions
really should be flagged.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -mejohn@anasaz.UUCP (John Moore) (08/06/88)
In article <11719@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
%
% One of the claimed advantages of assembler is that you can't get
%burned by changes in the compiler causing bad code. Unfortunately
%assemblers do generate bad code, too, on occasion. One example was the
%GMAP assembler for the GE600. Certain instructions mush be in odd
%locations, such as RPD, and in some cases that was not forced. I think
%it was if the RPD was the result of the expansion of a macro or
%something, but it was 20+ years ago.
There was some sort of pseudo-op to force that, I think... (been about 17
years for me)
--
John Moore (NJ7E) {decvax, ncar, ihnp4}!noao!nud!anasaz!john
(602) 861-7607 (day or eve) {gatech, ames, rutgers}!ncar!...
The opinions expressed here are obviously not mine, so they must be
someone else's.leem@jplpro.JPL.NASA.GOV (Lee Mellinger) (08/19/88)
In article <3008@ttidca.TTI.COM> hollombe@ttidcb.tti.com (The Polymath) writes: |In article <1148@anasaz.UUCP> john@anasaz.UUCP (John Moore) writes: |}None of this is to imply that assembly language is a good way to do |}applications! Just to show that some extremely large systems are done |}that way. | |Another example: | |Most of the code in the Space Shuttle's on board computers is written in |assembler. I know because I once had to document a large chunk of it (the |Initial Program Load (IPL) module). | |The Polymath (aka: Jerry Hollombe, hollombe@ttidca.tti.com) Illegitimati Nil Not so according to Barbra Kolkhost, IBM Federal Systems Division. This organization is responsible for writing and maintaining the Space Shuttle onboard software for the four AP-101 computers (not the backup machine), and have been for the life of the project. The shuttle code is written on a mainframe computer in HAL/S and machine code is generated for the target machines (the AP-101's). HAL/S is a realtime high level language that resembles PL-1 and was written by Intermetrics specifically for the shuttle. It evolved from an earlier language that was used on the Apollo spacecraft. Lee -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- |Lee F. Mellinger Jet Propulsion Laboratory - NASA| |4800 Oak Grove Drive, Pasadena, CA 91109 818/393-0516 FTS 977-0516 | |-------------------------------------------------------------------------| |UUCP: {ames!cit-vax,psivax}!elroy!jpl-devvax!jplpro!leem | |ARPA: jplpro!leem!@cit-vax.ARPA -or- leem@jplpro.JPL.NASA.GOV | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
levine@eniac.seas.upenn.edu (Jonathan M. Levine) (08/20/88)
In article <2689@jpl-devvax.JPL.NASA.GOV> leem@jplpro.JPL.NASA.GOV (Lee Mellinger) writes: >In article <3008@ttidca.TTI.COM> hollombe@ttidcb.tti.com (The Polymath) writes: >|In article <1148@anasaz.UUCP> john@anasaz.UUCP (John Moore) writes: >|}None of this is to imply that assembly language is a good way to do >|}applications! Just to show that some extremely large systems are done >|}that way. >| >|Another example: >| >|Most of the code in the Space Shuttle's on board computers is written in >|assembler. I know because I once had to document a large chunk of it (the >|Initial Program Load (IPL) module). >| >Not so according to Barbra Kolkhost, IBM Federal Systems Division. >[...] The shuttle code >is written on a mainframe computer in HAL/S and machine code is >generated for the target machines (the AP-101's). The IPL module is essentially a bootstrap loader, and is probably written directly in assembly language to reduce the size of the generated code. In any case, it would not be out of character for IBM to write code in a high level language, but only distribute the generated assembler code (c.f. VP/SP, MVS, etc.) ------------------------------------------------------------------------------- From the e-desk of: Jonathan Levine "Not necessarily. I COULD University of Pennsylvania be arguing in my spare time." Mostly: levine@eniac.seas.upenn.edu Summer: visres.jlevine@crvax.sri.com
raveling@vaxb.isi.edu (Paul Raveling) (08/23/88)
In article <2689@jpl-devvax.JPL.NASA.GOV> leem@jplpro.JPL.NASA.GOV (Lee Mellinger) writes: > >...Shuttle onboard software for the four AP-101 computers (not the backup >machine), and have been for the life of the project. The shuttle code >is written on a mainframe computer in HAL/S and machine code ... I had an impression, but don't recall with certainty, that the backup computer's software was assembly language. This impression was from a software engineer who worked on it and moved from Rockwell to my group at FutureData late in 1980. Another avionics example is the B1-B Central Air Data Computer, which was about 50% assembly language, 50% PLM/86 when I worked on it. This, along with all the other avionics software I've seen, needed hand-optimized assembly code to meet its real time requirements. --------------------- Paul Raveling Raveling@vaxb.isi.edu