Path: utzoo!utgpu!watserv1!watmath!att!att!dptg!ulysses!andante!mit-eddie!mintaka!olivea!samsung!uakari.primate.wisc.edu!sdd.hp.com!wuarchive!emory!hubcap!gatech!mcnc!uvaarpa!murdoch!astsun.astro.Virginia.EDU!gl8f
From: gl8f@astsun.astro.Virginia.EDU (Greg Lindahl)
Newsgroups: comp.lang.misc
Subject: Re: How to make a language downward-extensible?
Message-ID: <1990Oct18.195402.13187@murdoch.acc.Virginia.EDU>
Date: 18 Oct 90 19:54:02 GMT
References: <899:Oct800:50:3590@kramden.acf.nyu.edu> <1990Oct8.034201.2631@murdoch.acc.Virginia.EDU> <13549:Oct1800:31:5490@kramden.acf.nyu.edu>
Sender: news@murdoch.acc.Virginia.EDU
Organization: Department of Astronomy, University of Virginia
Lines: 29

In article <13549:Oct1800:31:5490@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:

>> the future F9X, and oddly enough Cray seems to have little trouble
>> writing a compiler which totally vectorizes my hydrodynamics code
>> which is written in portable fortran.
>
>Same for Convex---but since each compiler vendor gives the programmer a
>different way to indicate vectorization, the efficiency itself isn't
>portable.

My code doesn't need any vetorization directives. The efficiency is
portable.

>But the argument still makes sense. ``Some extensions, like very fast
>pythagorean sums, won't be standardized for a very, very long time.
>Does that mean the programmer shouldn't be able to write code that will
>take advantage of pythagorean sums when they're around? Does it mean
>that all such code must be unportable?''

This is how programmers were doing it many years ago:

1) Write a library interface for the sum.
2) Code a portable routine.
3) If necessary, write efficient machine-specific version.

This gives you portable code.

--
"Restraint, hell. I'm just too fucking busy." -- Bill Wisner