nather@utastro.UUCP (Ed Nather) (07/23/88)
In article <474@m3.mfci.UUCP>, colwell@mfci.UUCP (Robert Colwell) writes: > Hell, there are still > people who think assembly language programming is better; how would > you prove to them they're wrong? I know of no programmer who thinks assembly language is better for all kinds of programs, nor do I know a good one who feels it is *never* better for *any* job. Until I can buy a compiler -- for any language -- than can generate code that runs as fast as I can write by hand, I will use assembly language where speed is essential. You will, indeed, have a hard time proving to me that I'm wrong in using the tool that best fits the requirements of the job. -- Ed Nather Astronomy Dept, U of Texas @ Austin {backbones}!{noao,ut-sally}!utastro!nather nather@astro.as.utexas.edu
colwell@mfci.UUCP (Robert Colwell) (07/24/88)
In article <2926@utastro.UUCP> nather@utastro.UUCP (Ed Nather) writes: >In article <474@m3.mfci.UUCP>, colwell@mfci.UUCP (Robert Colwell) writes: >> Hell, there are still >> people who think assembly language programming is better; how would >> you prove to them they're wrong? > >I know of no programmer who thinks assembly language is better for all >kinds of programs, nor do I know a good one who feels it is *never* >better for *any* job. Until I can buy a compiler -- for any language -- >than can generate code that runs as fast as I can write by hand, I will >use assembly language where speed is essential. You will, indeed, have >a hard time proving to me that I'm wrong in using the tool that best >fits the requirements of the job. Just because you don't know any doesn't mean they don't exist. Look back about four years ago in all the standard trade rags and you'll find a letters-to-the-editor war waged on this basis. Directly equivalent to the "go-tos suck" war in CACM several months back. Anyway, that ain't what I'm talking about. I'm trying to draw what seems to me to be a direct analogy. OK, it won't work on you if you don't know any assembly language religious fanatics (and I grant there aren't many left.) What I'm saying is that no reasonable proof can be offered to cause someone to switch away from the tools they're using, and I think the same phenomenon applies to programming environments in the large. Heck, for all I know, your situation might be a case in point. Suppose you go to your boss (pretend you're in a commercial situation to make this cleaner) and tell him "hey, I can meet the target specs you asked for by coding in C over a period of 2 months, but I can exceed them by 15% by coding some of it in assembler (and it'll take a little longer)". Your job might be to get the initial prototype running, but his is to make sure he ends up with a product that he can maintain, extend, and understand, because you, the programmer, are statistically likely to leave within 2 or 3 years. So he may tell you to punt the extra performance. The issue here is on what grounds, and in what terms, the two of you can discuss which path to take. It's not as simple as "hand assembly code is faster than compiled code". Bob Colwell mfci!colwell@uunet.uucp Multiflow Computer 175 N. Main St. Branford, CT 06405 203-488-6090
seanf@sco.COM (Sean Fagan) (07/25/88)
In article <2926@utastro.UUCP> nather@utastro.UUCP (Ed Nather) writes: >In article <474@m3.mfci.UUCP>, colwell@mfci.UUCP (Robert Colwell) writes: >> Hell, there are still >> people who think assembly language programming is better; how would >> you prove to them they're wrong? > >Until I can buy a compiler [stuff deleted arbitrarily] >than can generate code that runs as fast as I can write by hand, I will >use assembly language where speed is essential. I used to work on a CDC 170 state mainframe, and got to be pretty good at writing assembly language programs for it (natural skill [blush] plus a very simple but powerful instruction set made for fun programming). A friend and superior (Marc Furon; I knew him before I started working with him) was *very* good with it, definitely one of the better COMPASS programmers around. He maintained, I believe him (hey, I trust the guy's opinion), that the FORTRAN compiler could generate better code than he could, sometimes. 'Course, the MSC 5.x compiler will also generate better code than I will, at times (other times, it's so *stupid* 8-)). Compiler technology is getting *very* good, and will, for a time, continue to improve. I think if you wait a few years (or decades), then we will probably have a compiler that won't need the noalias keyword: it will be able to figure it out from comprehensive code analysis and a good understanding of the machine. Fun thought, ain't it? -- Sean Eric Fagan | "An Amdahl mainframe is lots faster than a Vax 750." seanf@sco.UUCP | -- Charles Simmons (chuck@amdahl.uts.amdahl.com) (408) 458-1422 | Any opinions expressed are my own, not my employers'.
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (07/25/88)
I wrote a C program to generate Mandelbrot data a year or so ago, and
was able to improve performance over the original implementation as
follows:
method improvement %
================================================================
improved algorithm in C 600
recoded innermost loop in
assembler (11 instructions) 140
I fear that the assembler jock would have done the innermost loop
first, said "look how much better assembler is than C," and gone on.
Obviously the Xenix/286 compiler doesn't generate optimal 80287 code,
but I never would have been willing to spend time on the algorithm if
changes took an hour of typing to enter.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -memunck@linus.UUCP (Robert Munck) (07/26/88)
In article <2926@utastro.UUCP> nather@utastro.UUCP (Ed Nather) writes: >I know of no programmer who thinks assembly language is better for all >kinds of programs, nor do I know a good one who feels it is *never* >better for *any* job. Until I can buy a compiler -- for any language -- >than can generate code that runs as fast as I can write by hand, I will >use assembly language where speed is essential. You will, indeed, have >a hard time proving to me that I'm wrong in using the tool that best >fits the requirements of the job. Given real world system sizes, budgets, deadlines, and MAINTENANCE constraints as your "requirements," assembly language will "fit" only the smallest, most toy-like, never-to-be-used-for-real prototypes. If I've got two years and five people to write a system that takes 100,000 lines of Ada or 500,000 lines of assembly code to express (an extremely conservative expansion factor), I have to write it in Ada; the assembly version would never be finished. Note that an Ada program that works is by definition faster than an assembly language program that doesn't. (Done as a military procurment, the Ada version would take 100 people ten years to do; the assembly version would be quietly cancelled in the fifteenth year of development). Of course, we can't "prove" anything in this field; "de gustibus non est dispundandum" only tells us that Gus is still in the West. However, my twenty years of writing code, many anecdotes, and one substantial, well- run experiment tell me this: Given equal amounts of "brain-power" put into the effort, a group of HOL programmers will build a SMALLER, FASTER system than a group of assembly language programmers. Reason: the HOL team can put more thought into efficient data structures and algorithms, while the assembly language group burns up their brains doing register assignment, optimizing five-instruction loops, and generally doing things that compilers are BETTER THAN HUMANS at doing. Don't even think about debugging, maintenance, and enhancement over a long life-cycle. Sure, sometimes the timing requirements are so tight that the HOL version doesn't make it. In that case, instrument the heck out of the HOL, find out which ten statements it's spending 30% of the time executing, and re-write those in assembler. Keep doing this until you meet the timing specs. Almost certainly, you'll have re-written less than 5% of the code. Next year, when you move to a faster CPU, throw away the assembly. -- Bob Munck, MITRE <munck@mitre-bedford.arpa>
henry@utzoo.uucp (Henry Spencer) (07/26/88)
In article <37014@linus.UUCP> munck@faron.UUCP (Robert Munck) writes: >...(Done as a military procurment, the Ada version would >take 100 people ten years to do; the assembly version would be quietly >cancelled in the fifteenth year of development). Done as a commercial job in C, of course, two people could do it in a year! :-) :-) >Sure, sometimes the timing requirements are so tight that the HOL version >doesn't make it. In that case, instrument the heck out of the HOL, find >out which ten statements it's spending 30% of the time executing, and >re-write those in assembler. Keep doing this until you meet the timing >specs. Almost certainly, you'll have re-written less than 5% of the code. An alternative strategy is to re-think the HOL code instead. Doing this repeatedly yields remarkable results. It's remarkable how little thought goes into the first version of most code, even when good people are doing it. C News (see the Collyer&Spencer paper in the Winter 87 Usenix) picked up an order of magnitude in performance this way without a line of assembler. Of course, we profiled it to find out which parts of it actually deserved all this attention; lengthy re-thinking of non-critical code is a silly waste of effort. -- MSDOS is not dead, it just | Henry Spencer at U of Toronto Zoology smells that way. | uunet!mnetor!utzoo!henry henry@zoo.toronto.edu
jbs@fenchurch.MIT.EDU (Jeff Siegal) (07/26/88)
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 I've got two years and five people to write a system that takes >100,000 lines of Ada or 500,000 lines of assembly code to express (an >extremely conservative expansion factor), I have to write it in Ada; >the assembly version would never be finished. 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. 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). All this isn't to say that I think assembly should be used for large programs (I don't). Only that it is possible. Jeff Siegal
nather@utastro.UUCP (Ed Nather) (07/27/88)
In article <37014@linus.UUCP>, munck@linus.UUCP (Robert Munck) writes: > In article <2926@utastro.UUCP> nather@utastro.UUCP (Ed Nather) writes: > >I know of no programmer who thinks assembly language is better for all > >kinds of programs, nor do I know a good one who feels it is *never* > >better for *any* job. > > Given real world system sizes, budgets, deadlines, and MAINTENANCE > constraints as your "requirements," assembly language will "fit" only > the smallest, most toy-like, never-to-be-used-for-real prototypes. > If I've got two years and five people to write a system that takes > 100,000 lines of Ada [...] > Our models of what constitutes a program are clearly very different. Given two years and five people to write 100,000 lines of Ada, I'd find some other profession. I'm astounded that it can be done at all, and I would *never* propose it be written in assembler. This difference in models may explain a lot of our differences of opinion. As an alternative chore, consider this: I'm writing a real-time data acquisition program (in C) that runs on an IBM PC clone (because it is cheap, not because it is fast) that must have an animated, non-blinking graphical display of data as they arrive. My first cut (in C) had a display so slow I wouldn't ever use it myself, so I re-wrote the display driver in assembler, achieving a speedup of over 50 times (*not* 50%) because I could put everything into the ugly Intel register set and never reference memory in the display loop anywhere -- a luxury the C compiler did not have. > Sure, sometimes the timing requirements are so tight that the HOL version > doesn't make it. In that case, instrument the heck out of the HOL, find > out which ten statements it's spending 30% of the time executing, and > re-write those in assembler. Keep doing this until you meet the timing > specs. Almost certainly, you'll have re-written less than 5% of the code. That's what I did -- except I didn't need to instrument anything, I could see what was too slow just by watching the display. So where do we disagree? If you believe I advocated assembly language for all jobs, please re-read what I wrote. -- Ed Nather Astronomy Dept, U of Texas @ Austin {backbones}!{noao,ut-sally}!utastro!nather nather@astro.as.utexas.edu
lindsay@k.gp.cs.cmu.edu (Donald Lindsay) (07/27/88)
This whole "debate" is silly. Didn't anyone ever hear of portability? As for the question of performance gains: this is partly: the quality of optimizing compilers (Improving) the occasional inappropriateness of a language's semantics (usually only matters to OS people and such) I've seen some big wins from recoding into assembler. I've seen bigger wins from switching compilers, and even bigger wins from rethinking the algorithm. The biggest wins come from rethinking the problem. Yes, I can give examples. -- Don lindsay@k.gp.cs.cmu.edu CMU Computer Science
jlg@beta.lanl.gov (Jim Giles) (07/28/88)
In article <2442@pt.cs.cmu.edu>, lindsay@k.gp.cs.cmu.edu (Donald Lindsay) writes: > I've seen some big wins from recoding into assembler. I've seen bigger > wins from switching compilers, and even bigger wins from rethinking > the algorithm. The biggest wins come from rethinking the problem. > Yes, I can give examples. I've never seen switching compilers do better than recoding in assembly. I guess it could happen if you have a bad programmer do your assembly code. The fact is, a good starting point for an assembly version of ANY code is the output of some good compiler. Using this technique, you can always do AT LEAST as good as the best compiler you have. There are only two good reasons for using assembler. If you have either of these, you probably should consider assembler. 1) Your 'high-level' language doesn't have some feature that the hardware does. This includes test-and-set instructions for semaphores, vector mask instructions, etc.. If you need to use these features to get your job done, there is not alternative to assembly code. 2) Your code is VERY time or space critical. If you've go only so many clocks, of only so much memory for the code, assembly may be your only chance. Other than this, stick to your high-level languages. Portability may no be important to you now, but later you MAY discover that you want to move the code. J. Giles
gillies@p.cs.uiuc.edu (07/28/88)
In article jbs@fenchurch.mit.edu.UUCP (Jeff Siegel) 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. > >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). Do you realize you have hung yourself by proclaiming OS/360 as a triumph of assembly language? "The Mythical Man Month" is not a gothic romance -- it is a horror story. OS/360 had over 50,000 UNFIXABLE documented bugs, partly because fixing some bugs would introduce even more bugs (buggy code relied on buggy code). I suspect some bugs were not fixable because of the difficulty of modifying the assembly code. If you want to cite a SUCCESSFUL system that uses assembly language, how about the No 1. ESS switching system from AT&T (3 million lines)? AT&T once offered me a job working on that system. They had 10 scientists just STUDYING THE FEASIBILITY of making modifications to the assembly code! Don Gillies, Dept. of Computer Science, University of Illinois 1304 W. Springfield, Urbana, Ill 61801 ARPA: gillies@cs.uiuc.edu UUCP: {uunet,ihnp4,harvard}!uiucdcs!gillies
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
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (07/29/88)
In article <20894@beta.lanl.gov> jlg@beta.lanl.gov (Jim Giles) writes: | I've never seen switching compilers do better than recoding in assembly. | I guess it could happen if you have a bad programmer do your assembly code. How about a large program? A good C compiler will find common subexpressions, partial results, etc. Even a good assembly programmer won't rescan the whole program after every change to see if any common subexpressions can be eliminated. In the same vein, I once had a program which was a little too large and slow. I changed many of the procedures to macros, and generated the code inline. This allowed the (VAX-11) C compiler to find more common stuff, dead loops, etc, and produce code which was about 20% faster, and could still be converted back to procedures by removing one include statement. Unfortunately the program stayed about the same size, but I lived with it. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
bzs@bu-cs.BU.EDU (Barry Shein) (07/29/88)
>I know of no programmer who thinks assembly language is better for all >kinds of programs, nor do I know a good one who feels it is *never* >better for *any* job. Until I can buy a compiler -- for any language -- >than can generate code that runs as fast as I can write by hand, I will >use assembly language where speed is essential. You will, indeed, have >a hard time proving to me that I'm wrong in using the tool that best >fits the requirements of the job. > >-- >Ed Nather Sure Ed, I agree, sometimes a routine or three ought to be written in assembler, everyone seems to be saying the same basic thing, what's the problem here exactly? One problem you have to acknowledge is that it's a hell of a lot easier to turn out HLL programmers than assembler programmers of any value (fortunately, given the above you don't need too many.) And the world needs a lot of programmers, more than they need a few tightly coded routines. To a great extent (except in the most extreme cases) speed has become mostly an economic issue (one major exception being the PC market where the customer hardware base is relatively fixed in speed and, lo and behold, you find a lot of machine level code bummers getting top dollar in that biz.) The problem is not straightforward coding of typical things, like loops or integer arithmetic or character manipulation, that's easy enough. The problem is almost everything else, getting a student to learn enough about writing floating point in assembler, I/O operations and exception handling, data structure discipline (in assembler it much more closely resembles an arbitrary, self-imposed discipline), recursively callable code, re-entrant code etc. In HLL's most of that is handled fairly naturally, floating pt and integer are more or less the same with no long exegeses about normalization etc. Sure, numerical analysis can be a real problem in either case, but that's a different issue entirely, nothing about writing an algorithm in assembler particularly tells me that the loop I just wrote will turn the numbers into cream cheese by the time it exits, nor HLLs. What is unfortunate is the loss of assembler programming from a lot of curricula as, at least, an exercise in what the hell a computer really is. Too many kids I run into view a computer as a box which interprets Pascal or C code (etc.) Their mental model is broken so they have a lot of trouble turning out reasonable code (eg. they have little idea why screaming down an incrementing pointer is a lot faster than doing an array lookup on each turn of a loop, and should usually be coded as such on the first pass in most straightforward routines, particularly search routines, at best they rote memorize such hints.) The problem is a crowded curricula, mostly. -Barry Shein, Boston University
bzs@bu-cs.BU.EDU (Barry Shein) (07/29/88)
The other funny thing that gets lost in these arguments is that I repeatedly have the experience of speeding up other people's code dramatically w/o resorting to assembler. For example I just made available a bunch of changes to a Postscript interpreter for X11 which speeds it up quite a bit, all by rethinking some of the C code after monitoring it and looking at the places it spent most of its time on a bunch of test examples. Basically the problems were that it called some routines as much as a few hundred thousand times for even relatively simple images. Some serious open-coding, register decls, changing array refs in loops to equivalent but faster pointer stepping etc and it sped up a lot. Sure, I could have gone another step and seen if some routines might have been better coded in assembler, it occurred to me although it also seemed there were more HLL changes to do if I really wanted to continue. The guy was a good coder, he just seemed far more concerned with getting it right than raw speed which certainly made sense at that point in devpt, routines I open-coded (eg) were easy decisions as hindsight, now that I could view a lot of that code as stabilized. And I FTP'd the whole mess to another architecture (Sun/68020->Encore/32332), typed 'make', and it ran faster over there also a few minutes later. -Barry Shein, Boston University
jesup@cbmvax.UUCP (Randell Jesup) (07/29/88)
In article <2948@utastro.UUCP> nather@utastro.UUCP (Ed Nather) writes: >In article <37014@linus.UUCP>, munck@linus.UUCP (Robert Munck) writes: >> If I've got two years and five people to write a system that takes >> 100,000 lines of Ada [...] >Our models of what constitutes a program are clearly very different. Given >two years and five people to write 100,000 lines of Ada, I'd find some other >profession. I'm astounded that it can be done at all, and I would *never* >propose it be written in assembler. How about 8-10 months, 4 people, and 40-50,000 lines of Ada? It can be done, I've seen it (it was even a government contract). And that was while supporting the prototype written in a couple of months in C by 2 people. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
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.
jlg@beta.lanl.gov (Jim Giles) (07/29/88)
In article <11674@steinmetz.ge.com>, davidsen@steinmetz.ge.com (William E. Davidsen Jr) writes: > How about a large program? A good C compiler will find common > subexpressions, partial results, etc. Even a good assembly programmer > won't rescan the whole program after every change to see if any common > subexpressions can be eliminated. You didn't listen. I recommended keeping the high-level code and making mods and improvements there. Only AFTER you have a working 'final' version, and it's still too slow/big, do you convert to assembly. Converting to assembly is done by taking the compiler OUTPUT (which is machine code) and disassembling. Now you can apply modifications to this code to make it faster/smaller. Clearly you can never do worse than your best compiler did. Also, most C compilers do a miserable job at common subexpression analysis, strength reduction, etc.. A critical part of your code should be rewritten in several different languages - then you keep the one that produces the best code. Of course, this assumes that you can mix languages on the host machine. But, if you can't do that, you probably don't have ANY good compilers (or other tools) on that machine anyway (so you're stuck with assembly for all critical code). If the performance and size of a code is important, many languages should be tried - including assembler. If only portability is important, by all means stick to one portable language. Of course, this still doesn't address the issue of machine features that the 'high-level' language doesn't support. J. Giles
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
munck@linus.UUCP (Robert Munck) (07/30/88)
In article <20921@beta.lanl.gov> jlg@beta.lanl.gov (Jim Giles) writes: >In article <11674@steinmetz.ge.com>, davidsen@steinmetz.ge.com (William E. Davidsen Jr) writes: >> How about a large program? A good C compiler will find common >> subexpressions, partial results, etc. ... > >Also, most C compilers do a miserable job at common subexpression >analysis, strength reduction, etc.. A critical part of your code >should be rewritten in several different languages - then you keep >the one that produces the best code. Of course, this assumes that >you can mix languages on the host machine. ... Mixing languages is not a terrific idea if your program is to be maintained and enhanced over the years. Languages change, too, and trying to keep up with diverging languages... Anyway, what's all this discussion of C? I don't consider C to be a high-level language; it's more of an assembler with a powerful but obscure set of macros. C is probably the only computer language that's older than most of the programmers using it. (FORTRAN and COBOL are even older, sure, but most of their users are getting even greyer.) Let's not confuse C with real HOLs like Modula-2 and Ada. -- Bob Munck, MITRE -- ..!linus!munck.UUCP, munck@mitre-bedford.ARPA
firth@sei.cmu.edu (Robert Firth) (08/01/88)
In article <2959@utastro.UUCP> nather@utastro.UUCP (Ed Nather) writes: >Gad, I forgot! Unix Lucky man. Wish I could.
hjm@cernvax.UUCP (hjm) (08/01/88)
Newsgroups: comp.arch Subject: Re: using (ugh! yetch!) assembler Summary: Expires: References: <6341@bloom-beacon.MIT.EDU> <60859@sun.uucp> <474@m3.mfci.UUCP> <37014@linus.UUCP> <2948@utastro.UUCP> <4365@cbmvax.UUCP> Sender: Reply-To: hjm@cernvax.UUCP () Followup-To: Distribution: Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland Keywords: If one considers a computing system to be a conglomeration of software and hardware all the way from the application program right down to the physical hardware, then one can move from the most portable and least machine-specific part (the program written in an HLL) to the least portable and most machine- specific part (the hardware), defining portability in terms of the effort required to move that part to a different environment. As this progression is made (from portable to non-portable), the performance of each level increases: some things are in hardware because it goes quicker like that. (If the performance does not increase, then the loss of portability is not worth it and neither is the cost.) Again, the well-known engineering tradeoff rears its head again: portability v. performance; speed v. ease of implementation. So, put it hardware, put it in firmware, put it in assembler or put it in an HLL. Do whatever is right in your system, given the inevitable trade-offs that cannot be avoided, because there is *no* single correct solution for but use them well. Horses for courses, not dogma. Hubert Matthews
jlg@beta.lanl.gov (Jim Giles) (08/02/88)
In article <2960@utastro.UUCP>, nather@utastro.UUCP (Ed Nather) writes: > A programmer designs a program based on the tools -- the instruction set > or the defined, allowable operations in the HLL. I have seen many cases > where programming the initial version in C or in (forgive me) Fortran > leads to a manner of design that precludes an approach that fits the > underlying hardware better. It works, but because the HLL does not map > well into the underlying operations, it can be much less efficient. I agree with what you say here. If the high level language you have doesn't match the underlying machine very well - by all means use assembler. As I stated before, one of the major reasons for using assembler is to use machine features that the HLL doesn't support (well - or at all). My previous posting was in response to someone that claimed that using a better compiler could beat assembly code! It is obvious that you can always AT LEAST tie the best compiler you have - just use the compiler generated code as your starting point for assembly recoding. J. Giles P.S. You needn't apologize for using Fortran. Fortran outperforms C on quite a few things. I certainly use Fortran whenever I need to do numerical work. At least when I want it done quickly, correctly, and readably.
igb@cs.bham.ac.uk (Ian G Batten <BattenIG>) (08/02/88)
In article <2959@utastro.UUCP> nather@utastro.UUCP (Ed Nather) writes: > In article <2442@pt.cs.cmu.edu>, lindsay@k.gp.cs.cmu.edu (Donald Lindsay) writes: > > This whole "debate" is silly. Didn't anyone ever hear of portability? > > > > Gad, I forgot! Unix, the portable OS, was written in C with *no* assembly > code -- have I got the story right? I don't think you have --- the kernel was recoded in C but the early stuff was in pdp7 assembler. I have a feeling that the widespread use of C in the kernel was to do with the port to the Interdata 8/32, but I may be wrong. Modern Unix kernels still have some assembler in them, I think. I dimly recall reading that the 4.2bsd on a VAX kernel had of the order of 1000 lines of the stuff. [Gosh, that was hedged with maybes!] -- ian INTERNET: BattenIG%cs.bham.ac.uk@cunyvm.cuny.edu JANET: BattenIG@uk.ac.bham.cs BITNET: BattenIG%cs.bham.ac.uk@ukacrl.bitnet UUCP: ...!mcvax!bhamcs!BattenIG
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/02/88)
In article <37406@linus.UUCP> munck@faron.UUCP (Robert Munck) writes: | Mixing languages is not a terrific idea if your program is to be | maintained and enhanced over the years. Languages change, too, and | trying to keep up with diverging languages... A few words on that... One way to preserve portability is to get the whole program working in C, and identify the problem areas. Then the assembler output of C can be massaged by hand for efficiency. By always starting with compiler output you avoid having the C source and the assembler source out of phase to the point where the C won't work anymore. I know this is clumsy, that's why I recommend it. It will make you think before spending a lot of time trying to make small gains in performance, as opposed to rethinking the whole algorithm. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/02/88)
I think the whole question of HLL vs assembler is moot, since the
economics have changed and it doesn't make sense to use assembler *for
most things* anymore.
In 1970 a reasonable computer cost around $1.5 million, and a
reasonable programmer with a little experience cost about $8k. Today a
workstation costs $10-20k and a slightly experienced programmer cost
$30-50k (depending on location, etc). This makes programmer time a lot
more expensive in relation to the machine on which the program runs, and
makes productivity more important.
Another factor is program size. There were no really large programs in
the "old days," because there were no machines which could run them.
Anyone who used to program in 64k (or even 1mb) machines using hundreds
of overlays knows that the largest programs 20 years ago were very small
compared to the programs of today. When you get to millions of lines of
code, you probably couldn't debug a program in assembler before it was
obsolete.
I realize that there are still special cases, most of which involve
thrying to push some hardware to the absolute limits of its performance,
but in general the cost of large programs is assembler, and the cost of
porting them to a new machine in a few years, makes assembler the last
choice of languages for business, and lack of resources makes it
unattractive for research.
Before replying please read carefully. I am not claiming that
assembler is completely obsolete, only that it is a poor choice in most
cases, due to time and/or money needed.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -memerlyn@intelob (Randal L. Schwartz @ Stonehenge) (08/02/88)
In article <2959@utastro.UUCP>, nather@utastro (Ed Nather) writes: | In article <2442@pt.cs.cmu.edu>, lindsay@k.gp.cs.cmu.edu (Donald Lindsay) writes: | > This whole "debate" is silly. Didn't anyone ever hear of portability? | > | | Gad, I forgot! Unix, the portable OS, was written in C with *no* assembly | code -- have I got the story right? Maybe I'm missing the sarcasm, if any (I don't see a smiley face). But, just to set the record straight (which probably 15 other people are typing in at this very moment to do as well... "USENET: where every innocent question is answered simultaneously by 15 others, generating 225 followups, ad infinitum...")... UN*X is *mostly* C, with some low-level interface routines (interrupt, boot, and memory management sorta stuff) in the assembler of the target machine. Of course, by the time it goes through the compiler, it's *all* assembly code :-). -- Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 on contract to BiiN Technical Publications (for now :-), Hillsboro, Oregon <merlyn@intelob.intel.com> or ...!tektronix!ogcvax!omepd!intelob!merlyn Standard disclaimer: I *am* my employer!
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
amos@taux02.UUCP (Amos Shapir) (08/03/88)
In article <37406@linus.UUCP> munck@faron.UUCP (Robert Munck) writes: >C is probably the only computer language that's >older than most of the programmers using it. 1978 was the year C was issued officially (that's when the White Book was published; before that, C was used by a few hundred people at most). That means most programmers are younger than 10 - I know I'm old, but not *that* old! :-) -- Amos Shapir amos@nsc.com National Semiconductor (Israel) 6 Maskit st. P.O.B. 3007, Herzlia 46104, Israel Tel. +972 52 522261 34 48 E / 32 10 N (My other cpu is a NS32532)
cik@l.cc.purdue.edu (Herman Rubin) (08/03/88)
In article <11699@steinmetz.ge.com>, davidsen@steinmetz.ge.com (William E. Davidsen Jr) writes: > In article <37406@linus.UUCP> munck@faron.UUCP (Robert Munck) writes: > | Mixing languages is not a terrific idea if your program is to be > | maintained and enhanced over the years. Languages change, too, and > | trying to keep up with diverging languages... > A few words on that... One way to preserve portability is to get the > whole program working in C, and identify the problem areas. Then the > assembler output of C can be massaged by hand for efficiency. By always > starting with compiler output you avoid having the C source and the > assembler source out of phase to the point where the C won't work > anymore. > > I know this is clumsy, that's why I recommend it. It will make you > think before spending a lot of time trying to make small gains in > performance, as opposed to rethinking the whole algorithm. But what do you recommend if your languages (C, FORTRAN, etc.) are incapable of doing even a remotely reasonable job with the program? I can provide relatively simple examples of programs which can be handled in a reasonably portable manner, but for which C does not have the concepts needed at all. These are not esoteric concepts; anyone who understands that machine words are composed of bits in a structured manner, and that the bits of a structure can be used in any manner compatible with the structure, can understand them. Another problem is the fact that what one can do with a single instruction on one machine takes many on another. An example is to round a double precision number to the nearest integer. If you think this is unimportant, every trigonometric and exponential subroutine, or a subroutine computing elliptic functions, etc., uses this or something similar. On some machines, this should be a moderately lengthy series of instructions. On others, there is a machine instruction which does precisely this. Now many (all that I have seen, but I have been told that there are ones which do not have this problem) C compilers will not allow asm instructions to use the compiler's knowledge of which registers are assigned to which variables. C cannot do the job. The present assemblers have the disadvantage that they are atrociously difficult to read and write. This is not necessary; COMPASS for the CDC6x00 and its descendents were easier, but not easy enough, and CAL on the CRAY easier still, but more can be done. I wonder how difficult it would be to use an overloaded operator weakly typed assembler. Some think that C is this; maybe it was intended as a replacement for such an object, but it fails badly. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)
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" -mepardo@june.cs.washington.edu (David Keppel) (08/04/88)
In article <37406@linus.UUCP> munck@faron.UUCP (Robert Munck) writes: >C is probably the only computer language that's >older than most of the programmers using it. C is 1970's. Fortran and LISP both predate 1960. I don't. ;-D on ( But then we all know Fortran isn't a language :-) Pardo
ok@quintus.uucp (Richard A. O'Keefe) (08/04/88)
In article <856@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >Another problem is the fact that what one can do with a single instruction >on one machine takes many on another. An example is to round a double >precision number to the nearest integer. If you think this is unimportant, >every trigonometric and exponential subroutine, or a subroutine computing >elliptic functions, etc., uses this or something similar. On some machines, >this should be a moderately lengthy series of instructions. On others, there >is a machine instruction which does precisely this. Now many (all that I have >seen, but I have been told that there are ones which do not have this problem) >C compilers will not allow asm instructions to use the compiler's knowledge of >which registers are assigned to which variables. I am sympathetic to Rubin's position, but I can't quite tell which side he is arguing on here. Let's replace his example by a still humbler one: integer multiplication. I have to include the operation of integer multiplication in assembly code generated by a "smart" macro processor. MUL doesn't quite take the non-portability prize; I think DIV does that. But even MUL is a subroutine call on some machines (not always obeying the protocol used elsewhere), an instruction on some, a sequence of 20-40 instructions on others. It is a relief to turn to C (pathetic though a language which doesn't report overflows may be) and not have to worry about that[*]. The situation with floating-point is worse. Once you start porting generated assembly code between machines with 32/16/11/8 general registers and varying numbers and arrangements of floating-point registers, it pretty soon occurs to you that it doesn't matter whether the compiler will "allow asm instructions to use the compiler's knowledge of which registers are assigned to which variables" or not, it's not going to port _nohow_. If you want to mingle small chunks of assembly code with C code, I'm convinced that asm("..") is obsolete: /usr/lib/inline is so much better (e.g. you can switch from C implementations of such functions to inline assembly code without changing your source, and better still, change _back_). A trap for asm("...") users: some C compilers switch off optimisation in a function if you use asm(), even if all you did was plant a label or comment. [*] I have seriously considered writing C routines to do integer *, /, %, and calling them from the generated assembly code. What was that about using assembly code to get access to machine instructions?
mash@mips.COM (John Mashey) (08/04/88)
In article <33@taux02.UUCP> amos@taux02.UUCP (Amos Shapir) writes: >In article <37406@linus.UUCP> munck@faron.UUCP (Robert Munck) writes: >>C is probably the only computer language that's >>older than most of the programmers using it. >1978 was the year C was issued officially (that's when the White >Book was published; before that, C was used by a few hundred people at most). >That means most programmers are younger than 10 - I know I'm old, >but not *that* old! :-) 1) 1978: I have a 1973 C reference manual.... 2) "a few hundred people at most": a non-fact. By early 1978, there were 500+ UNIX installations OUTSIDE Bell, and more (I think) inside; in those days there was certainly at least one person per machine that used C :-) "a few hundred at most": maybe this was true in 1974. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
smryan@garth.UUCP (Steven Ryan) (08/05/88)
> I wonder how difficult it >would be to use an overloaded operator weakly typed assembler. Some think that >C is this; maybe it was intended as a replacement for such an object, but it >fails badly. Compass macros can implement something akin to overloaded operators and typed operands, although the 8-character limitation is difficult. On the 205 assembler, Meta, our project had procs (=macros) to do things like WHILE P,EQ,TRUE while p do IF [T_EXP,L,EXP_OPCD],EQ,O_RADD if t_exp[l].exp_opcd=o_rad THEN then GFIELD T_EXP,L,EXP_OP1,L l:=t_exp[l].exp_opcd ELSE else CALL XYZ,[L,IN],[P,OUT] xyz(l in,p out) IFEND ifend WHILEND whileend
sedwards@esunix.UUCP (Scott Edwards) (08/05/88)
From article <11701@steinmetz.ge.com>, by davidsen@steinmetz.ge.com (William E. Davidsen Jr): > > I think the whole question of HLL vs assembler is moot, since the > economics have changed and it doesn't make sense to use assembler *for > most things* anymore. I agree. But I still think programming in assembler was ALOT more *FUN*, especially if the machine had a nice instruction set (Univac 1100, NS32K come to mind). Now after that statement this is going to sound real strange, but I think that the problem with the current HLL's is that they are not high enough, I would like a HLL that knows about trees, linked lists, etc. and how to deal with them, so I don't have to code all of the normal operations (insert, delete, etc) on them every time I use one. I've got to go, guess I'll have to save the rest. hmmm ... going to need to wear that asbestos suit tomorrow. -Scott
daveb@geac.UUCP (David Collier-Brown) (08/05/88)
From article <856@l.cc.purdue.edu>, by cik@l.cc.purdue.edu (Herman Rubin): > But what do you recommend if your languages (C, FORTRAN, etc.) are > incapable of doing even a remotely reasonable job with the program? >... Now many (all that I have > seen, but I have been told that there are ones which do not have this problem) > C compilers will not allow asm instructions to use the compiler's knowledge of > which registers are assigned to which variables. There are two problems here: expressive power of the language and quality of the compiler/embedded-assembler interface. Problem 1: Language. Get a better language. No smileys here, its a serious suggestion. C may be my favorite language, but I won't claim it is either modern or consistently well-implemented. Use FORTRAN for numerical problems if C gets in the way, C for structure-shuffling if FORTRAN gets in the way. Use Ada or C++ if the non-extensibility of either gets in the way. Problem 2: Compilers. Get a good one, for whatever language you buy. Make sure it will use the machine's standard[1] call interface if one exists, so you can mix languages. An anecdote: I once used an Ada[2] cross-compiler, back when Ada was **real** new and implementations tended to be weak. When I had to generate an in-line trap, I discovered I could state it all in the HLL. One declaration of a bit pattern (which was the instruction), one package definition to define the interface to it and umpty-dozen pragmas to say put it in-line parameter A must be in register An and An+1 parameter B must be in register R1 Net result? It generated almost "perfect" code for the trap, without any register-moves or call-return linkages. This is extensible to modeling almost any machine instruction[3], and one can always re-write the package to turn it into a different instruction (or sequence of instructions) if you have to port it. --OR-- You can try to invalidate the problem, and make the compiler generate optimal code. Yes, I said MAKE. Another anecdote: last year, I had to speed up a critical inner loop in a very large system written in Pascal. The compiler **would not** accept a declaration for the construct that was needed (a pointer to an array greater than its normal maximum size). It was initially done by allocating the array in the non-pascal startup code and using inline assembler to access it. It was ***slow***. When I looked at the code generated, inlining had only saved me the call-return instruction pair, not the required register/stack setup for the call. So I wrote out the addressing expression in Pascal, as arithmetic. The code it generate was one instruction "poorer" than the optimum, because it moved the result from the general registers to the address registers at the end. This was 6 instructions better than the inline assembler, and 8 better than out-of line instructions. (The move occurred as a result of my using an explicit union: if the language understood casts, it might have disappeared too). Result? We got our speedup, even though Pascal "knew" it wasn't supposed to be that helpful. So don't dispair, you can get out of almost any problem in Confuser Science: you just have to go back to first principles and attack the meta-problem. --dave (no cute statement today) c-b [1] Including de-facto ones, if the hardware one is yucky... [2] Ada is a trademark of the U.S. Gov't (Ada Joint Project Office) [3] This is generally a super-non-portable idea, though. -- David Collier-Brown. |{yunexus,utgpu}!geac!daveb Geac Computers Ltd., | Computer science loses its 350 Steelcase Road, | memory, if not its mind, Markham, Ontario. | every six months.
henry@utzoo.uucp (Henry Spencer) (08/06/88)
In article <363@james.cs.bham.ac.uk> igb@cs.bham.ac.uk (Ian G Batten <BattenIG>) writes: >I don't think you have --- the kernel was recoded in C but the early >stuff was in pdp7 assembler. I have a feeling that the widespread use >of C in the kernel was to do with the port to the Interdata 8/32, but I >may be wrong... You are, I'm afraid. The kernel was (mostly) recoded in C long before the idea of porting Unix to another machine came up. It took the utilities a while to catch up; the V5 ed was still in assembler, while the V6 one was in C. There has always been a modest lump of assembler around to handle details of the low-level interface to the hardware -- e.g. interrupt vectors and specialized instructions -- that the C compiler can't cope with. (Plus some that is there as runtime support for C itself, since kernel builds don't usually include the C library where that stuff normally lives.) This is manageable enough that nobody has ever tried really hard to eliminate it, although it could probably be reduced in size if one really tried. -- MSDOS is not dead, it just | Henry Spencer at U of Toronto Zoology smells that way. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
john@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.rmg@mips.COM (Richard M. Geiger) (08/06/88)
In article <933@esunix.UUCP> sedwards@esunix.UUCP (Scott Edwards) writes: >Now after that statement this is going to sound real strange, but I >think that the problem with the current HLL's is that they are not >high enough, I would like a HLL that knows about trees, linked lists, >etc. and how to deal with them, so I don't have to code all of the >normal operations (insert, delete, etc) on them every time I use one. If you find yourself recoding these things a lot, why not do it once in a good set of library functions and then use those? While there may very well be a lack of these things in any of the "most standard" libraries, this seems to stuff that belongs in library functions, not the language. -- - Rich Geiger {ames,decwrl,pyramid}!mips!rmg or rmg@mips.com Disclaimer: It's all a joke MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086 (408) 720-1700 x308 [Day Job] (408) 739-7911 [home]
seeger@beach.cis.ufl.edu (Charles Seeger) (08/07/88)
In article <933@esunix.UUCP> sedwards@esunix.UUCP (Scott Edwards) writes: >Now after that statement this is going to sound real strange, but I >think that the problem with the current HLL's is that they are not >high enough, I would like a HLL that knows about trees, linked lists, >etc. and how to deal with them, so I don't have to code all of the >normal operations (insert, delete, etc) on them every time I use one. Sounds like a call for C++, or some equivalent language. But, methinks, C++ will be the one that gains ascendency. True, it's as low level as C, and it's really HIGH level stuff will be in libraries that don't exist yet, but it's ability to allow code reuse via *multiple* inheritance (new in the latest AT&T cfront release, 2.0) is very powerful. Yet, the language is still relatively small. IMHO, it just needs exception handling (which appears to be gaining some acceptance), parallel programming constructs (perhaps as in Occam/CSP) and some optional tricks for SW Eng. But, does this discussion belong in comp.arch? Cheers Chuck
ralphw@ius3.ius.cs.cmu.edu (Ralph Hyre) (08/08/88)
In article <933@esunix.UUCP> sedwards@esunix.UUCP (Scott Edwards) writes: >[I] ...think that the problem with the current HLL's is that they are not >high enough, I would like a HLL that knows about trees, linked lists, >etc. and how to deal with them, so I don't have to code all of the >normal operations (insert, delete, etc) on them every time I use one. I believe that this level of support exists already, although it's widely scattered. Typically, these routines only have to be written once, then put in the library and documented. Understanding the calling conventions is usually the hardest part. The CLU language, for example, makes it easy enough to write new operations in terms of already existing ones. Recent implementations of the Scheme dialect of Lisp have provisions for extending the syntax of the language. Languages with inheritance (Smalltalk-80) usually don't even require re-writing routines for new data types. -- - Ralph W. Hyre, Jr. Internet: ralphw@ius2.cs.cmu.edu Phone:(412)268-{2847,3275} CMU-{BUGS,DARK} Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA
smryan@garth.UUCP (Steven Ryan) (08/08/88)
>If you find yourself recoding these things a lot, why not do it >once in a good set of library functions and then use those? The problem is not libraries but too few languages supporting parameterised modes.
hjm@cernvax.UUCP (hjm) (08/08/88)
(I apologise if you've seen this posting before, but rn and vi junked it up last time and I'm not sure what was happening...) If one considers a computing system to be a conglomeration of software and hardware all the way from the application program right down to the physical hardware, then one can move from the most portable and least machine-specific part (the program written in an HLL) to the least portable and most machine- specific part (the hardware), defining portability in terms of the effort required to move that part to a different environment. As this progression is made (from portable to non-portable), the performance of each level increases: some things are in hardware because it goes quicker like that. (If the performance does not increase, then the loss of portability is not worth it and neither is the cost.) Again, the well-known engineering tradeoff rears its head again: portability v. performance; speed v. ease of implementation. So, put it hardware, put it in firmware, put it in assembler or put it in an HLL. Do whatever is right in your system, given the inevitable trade-offs that cannot be avoided, because there is *no* single correct solution for all systems. Use whatever tools are necessary for you to meet your specs., but use them well. Horses for courses, not dogma. Hubert Matthews
suitti@haddock.ISC.COM (Steve Uitti) (08/09/88)
In article <933@esunix.UUCP> sedwards@esunix.UUCP (Scott Edwards)writes: >...but I think that the problem with the current HLL's [higher >level languages] is that they are not high enough, I would like a HLL >that knows about trees, linked lists, etc. and how to deal with them, >so I don't have to code all of the normal operations (insert, delete, >etc) on them every time I use one. C, like almost every other language ever invented, is also extensible. Old code can be reused in terms of libraries. Libraries can extend the capabilities. For example, "qsort" adds convient internal sorting. I'm a library fan. I try to put anything that remotely looks like a package into a library form, and try to reuse it whenever I can. There are several problems with libraries in the UNIX/C environment within the universe as we know it. 1) Local libraries tend not to get distributed (and worse, they tend not to get distributed with local code). 2) The documentation for code tends to get seperated from the original source (the only copy is often put into /usr/man, which is thrown out on each machine/OS upgrade), and does not get distributed with the source. 3) People are often unwilling to distribute code in source form, and every machine in the universe has a unique object code format and environment. Distributers cannot afford to own or have access to every instance of this mess, and it is expensive to keep porting the code. 4) Some programers think that for a program to be portable, it must use only libraries available on the distribution. Thus the only supported libraries tend to be those distributed commercially in source form (dbVista, for example), and those distributed with operating systems. 5) Libraries lack proper "for internal use" and global semantics. Basically, if you have two source files, which want to access a common (for example, state) variable, the varible must be global. If the library does not actually want to export this varible to the caller's environment, that's tough. This is mainly why "dbm" is all one file. There are, however a couple routines from "dbm" that my programs never use. The linker will not leave this dead code out, because the source is all one file. Back to HLL vs Assemblers "The problem with C is that it has these convenient optimizations always available." It was an interesting quote. It doesn't say that C does not provide high enough level semantics, it says that the lower level semantics tend to get in the way. C provides all the higher levelness (and more) of Fortran. There are poor Fortran compilers (is there a good UNIX Fortran? - maybe DEC's VMS fortran as ported to Ultrix...), just as there are poor C compilers. There are also some pretty good C compilers. I like having those convenient optimizations available. Code is never quick enough (or small enough, or...). Whatever the final result is, it is a compromise with factors such as how often it will be run, how much time is available to beat on it, etc. Generally, a reasonable approach tends to be one that uses the available tools for analysis (a brain, a profiler, etc.), then looks for improvement from the highest level of abstraction to the lowest. Thus, start with the algorythm (if this is changed, this other thing won't have to be called so often), then with the language in use (the compiler will do better with a "do { } while();" here than a "for (;;);" loop here, perhaps due to the number of tests per loop...), then the code produced (see what the compiler did for this routine, take out half of the subroutine call overhead, then remove a few redundant instructions...). Back when people tended to use assembler for the whole project, it was tougher to do the first couple of steps. Also, profilers tended to not exist or were real primitive (you could sample the PC now and again & see where it happened to be on some systems, watch blinking lights on the front panel on others). More recently, profilers can tell you how much time is spent in a routine with how much of that is spent in service to other particular proceedures. Better information is better. On the other hand, when people wrote stuff in assembler, it tended to be real small. Real small means fast startup time, even (especially?) on demand paged systems. I personally can't stand an editor that takes up more than about 100K bytes. Unfortuntely, multi megabyte applications seem to be the current trend. Even my favorite, C, can generate a 7K program for "hello world" on some systems (printf calls in most of stdio...). Lisp, and lots of new languages often start at a megabyte... There are still a few people out there who believed the original idea that libraries can make a language (even assembler) extensible. There are still a few people out there who "do it" with assembler for real applications. The people get real good results, even today. In fact, the only time one can fail is when one gives up. I remember CP/M days when 8080 assembly tended to be more portable than anything else, for various reasons. On the other hand, Mac applications, even written in C, tend not to be very portable to other architectures (or vice versa). There are no absolute truths. Stephen Uitti.
eric@snark.UUCP (Eric S. Raymond) (08/09/88)
In article <933@esunix.uucp>, sedwards@esunix.UUCP (Scott Edwards) writes: > I think that the problem with the current HLL's is that they are not > high enough, I would like a HLL that knows about trees, linked lists, > etc. and how to deal with them, so I don't have to code all of the > normal operations (insert, delete, etc) on them every time I use one. This is one reason the big trend in recent HLL design has been towards languages with lots of facilities for encapsulation of higher-level constructs (like trees, linked lists, etc.). The expectation is that standard libraries for all this stuff will evolve and spread, freeing programmers from constant re-invention of the wheel. The prehistory of this trend goes back to the Simula languages developed in Scandinavia in the mid-nineteen-sixties. But the most influential of the first generation of such languages was undoubtedly Xerox PARC's Smalltalk, first described in '72 and in active development through 1980. Smalltalk pointed the way and established 'object-oriented' programming as a serious alternative to traditional paradigms, but depended too much on a special and relatively rich environment to make a great impact on commercial programming. After 1980 the impetus moved to second-generation languages that set the new object-oriented style in a more accessible context. These could attract the kind of money and talent that would never see Smalltalk; and that wider base could support standard library development in a way credible to people who might have to bet projects on the quality and portability of those libraries. In the case of one of these languages, C++, the process is well along already. Keith Gorlen's OOPS libraries are of said to be of good quality (I haven't used them yet, so can't testify personally) and are publicly available for free. They are, I gather, already starting to be thought of as part of the `standard' C++ environment. And C++ is rapidly penetrating all of C's traditional turf, helped along by AT&T's actions (they've made it clear that the next major UNIX release will include C++), but even more by its *inaction* (the fact that AT&T has not tried to assert any proprietary lock on the language and has encouraged third-party developers to wrrite independent compilers to the design). Then, of course, there's ADA. There are many goal similarities between C++ and ADA; both were designed to graft object-oriented concepts onto an earlier generation of familiar conventional languages. It is thus very interesting to compare the encouraging early successes of the `bottom-up' approach of C++ and the UNIX technical culture in promulgating this new kind of programming with the massive failures and slippages in the DOD's imposed-from-above ADAization program. Part of the problem can be attributed to the fact that, right now, ADA doesn't *have* a technical culture; its constituency was created by fiat rather than enthusiasm. Part of the problem is simply that ADA is overdesigned, too big and complex for most programmers to get a good mental model of. One might say that it suffers from PL/1 disease; except that, unlike PL/1, there may be a good small language screaming to be let out from inside it. ADA's long-term prospects are not good; C and C++, between them, have already captured most of the human energy and interest that night have given it a real future. It remains to be seen if, unlike King Canute, DOD can actually induce the tide to roll back...
aglew@urbsdc.Urbana.Gould.COM (08/09/88)
..> suitti@haddock.isc.com, on extensibility of C via libraries ..> and problems with libraries in UNIX: > > There are several problems with libraries in the >UNIX/C environment within the universe as we know it. 1) Local >libraries tend not to get distributed (and worse, they tend not to get >distributed with local code). This is a problem that I begin to get interested in. I call it the "environment extract/insert" problem. IE. if I write code, a function or a utility program, I want to be able to give it to you in one package - including all of the library routines, etc. that my code depends on. This is the "environment extract" problem: we need tools to go and pick out the library routines and header files you will need to get my code running, and package them up. It's made a bit more interesting when some of the dependencies are on public domain stuff, and some on commercial stuff: you can package up the PD stuff, but not the stuff that requires a licence. Conversely, when you receive a package that contains an environment, extracted as above, you may already have a more up-to-date version of the environment. We need insert tools that will determine what parts of the environment have already been installed, and do not need to be. This is complicated by dependencies on old version functionality, as well as the fact that revisions in libraries do not always preserve filenames. What tools exist to do this? In conventional C environments? In more sophisticated environments? Andy "Krazy" Glew. Gould CSD-Urbana. 1101 E. University, Urbana, IL 61801 aglew@gould.com - preferred, if you have MX records aglew@xenurus.gould.com - if you don't ...!ihnp4!uiucuxc!ccvaxa!aglew - paths may still be the only way My opinions are my own, and are not the opinions of my employer, or any other organisation. I indicate my company only so that the reader may account for any possible bias I may have towards our products.
seibel@cgl.ucsf.edu (George Seibel) (08/10/88)
In article <2704@winchester.mips.COM> mash@winchester.UUCP (John Mashey) writes: |In article <33@taux02.UUCP> amos@taux02.UUCP (Amos Shapir) writes: |>In article <37406@linus.UUCP> munck@faron.UUCP (Robert Munck) writes: |>>C is probably the only computer language that's |>>older than most of the programmers using it. | |>1978 was the year C was issued officially (that's when the White |>Book was published; before that, C was used by a few hundred people at most). |>That means most programmers are younger than 10 - I know I'm old, |>but not *that* old! :-) | |1) 1978: I have a 1973 C reference manual.... OH! So most C programmers are under *fifteen*... well, that explains the skateboards.
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