Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!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: <6521:Feb2621:31:1491@kramden.acf.nyu.edu> Date: 26 Feb 91 21:31:14 GMT References: <10278@dog.ee.lbl.gov> <22605:Feb2608:04:5391@kramden.acf.nyu.edu> <8658@exodus.Eng.Sun.COM> Organization: IR Lines: 50 In article <8658@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David Chase) writes: > There's one problem with this: finite resources Look, Dave. Say you have a chip with 100 instructions, of which you use 90 in your compiler output. Pick one of the ten left: DREM, perhaps. How long would it take you to write a DREM function in portable C? So you write it just *one* way, and get your optimizer to understand that *one* way, and document that *one* way. How long does this take? An hour, perhaps, depending on the structure of your compiler. Can you spare 10 hours to make your compiler vastly more useful? > Another difficulty with the scheme that you describe is that you > really don't want people to be writing their code in strange little > idioms because that will engage some magic widget in the optimizer. > It's portable, but weird. That doesn't help readability or > debuggability, and it may not be portable into the future. Maybe you didn't understand what I said. By definition, everything done here is portable. If your compiler understands to be DREM, and doesn't work the same on another machine, then your compiler is simply incorrect. Programmers need to write efficient code that *will* be portable into the future, and my scheme is designed to allow this. As for maintainability... If the programmer *needs* Hamming weights, then he's going to write the code for it anyway. Adding an equivalent section of code for a different machine won't hurt the maintainability of the original. In fact, I think a pick-this-or-that construct would *help* maintainability, as it would let the programmer display his original, comprehensible code along with each transformed version. Do you have some religious argument against ``strange little idioms''? Well, it's the compiler writer's fault---your fault---if the idioms are strange. What's important to me is that they be portable. If you want to cure the ``strangeness,'' publish a standard for what you consider to be the right idiom, as I suggested before. > If you must (and some people must), > then use something based on subroutine calls. That's fine. ``If you write the following routine: int sumones(x) int x; { int a; int b; } then our optimizer will convert any call to sumones() into a CX instruction. You may only change the names sumones, x, a, and b; you must use exactly the order of instructions shown here, or our optimizer will not recognize the routine.'' This is all I'm asking for. Surely your compiler can do fixed pattern-matching without trouble? Is this such a ``weird little hack''? ---Dan Brought to you by Super Global Mega Corp .com