Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!hsdndev!cmcl2!kramden.acf.nyu.edu!brnstnd From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein) Newsgroups: comp.arch Subject: Re: What the compiler won't do you for you Message-ID: <16108:Mar822:57:0791@kramden.acf.nyu.edu> Date: 8 Mar 91 22:57:07 GMT References: <3061@charon.cwi.nl> <4267:Mar602:32:0591@kramden.acf.nyu.edu> Organization: IR Lines: 58 In article peter@ficc.ferranti.com (Peter da Silva) writes: > In article <4267:Mar602:32:0591@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > > At first, instead of learning five different assembly languages and > > figuring out how to write inlined assembly code under five different > > compilers, the programmer will copy five routines straight out of > > manuals. > How does this differ from copying 5 inline assembly examples straight out > of 5 manuals, except that under your plan it's less obvious that the code is > optimised for one particular compiler? It differs in three important ways. First, the code will always remain portable. In your world, the vendors promise to have those library routines always do the same thing; otherwise they will break correct code. In my world, there is no chance of this. Second, the extra code will remain useful, even if the vendors go out of business or the architectures die. In your world, someone might have written code under #ifdef Z80; now that code will be almost completely useless. In my world, the idioms are not hooked to one vendor or architecture, and will make the code faster under any compiler recognizing the same idiom. Third, the #ifdefs can be dispensed with entirely. In your world, there is no way to get rid of the #ifdefs, because each compiler will blow up on the unportable library routines written for the others. In my world, if the language specifies a pick-this-or-that control structure, you can just throw away the #ifdefs and the code will work on any machine. It will also be more resilient to changes in architecture or vendor support. > > as time goes by, idioms for a certain instruction can > > only become more standardized, > Right. Unless there is a definite conscious effort to do so, things in general > don't move in that direction. Just look at UNIX. Yes, let's look at UNIX. Within several years, most machines will support (for example) POSIX termio, and code written for that termio will be extremely portable. I think you're confusing the standardization of *all* system facilities with the standardization of *one* system facility. BSD will always be a very different system from System V, but their common base gradually grows larger and larger. Similarly, although compilers will always support many different idioms, more and more particular idioms will become standardized. A sufficiently standardized idiom can even be added to the language. > > Is there anyone else here who understands why suggestions like this are > > so pointless? I can't wait for the language designers to catch up and > > force everyone to provide an mp library. > But you think it's OK to wait for them to catch up and standardise a bunch > of poorly-defined idioms? No, I don't. That's why my proposal works with absolutely no standardization of the idioms. Whether the idioms gradually become more standard or not, they will have the three advantages I outlined above. ---Dan