Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!exodus!exodus-bb!khb From: khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) Newsgroups: comp.arch Subject: Re: What the compiler won't do you for you Message-ID: Date: 1 Mar 91 02:48:24 GMT References: <8728@exodus.Eng.Sun.COM> <13578:Feb2705:46:4391@kramden.acf.nyu.edu> <8787@exodus.Eng.Sun.COM> <24280:Feb2802:55:4991@kramden.acf.nyu.edu> Sender: news@exodus.Eng.Sun.COM Organization: Sun MegaSystems Lines: 26 In-reply-to: brnstnd@kramden.acf.nyu.edu's message of 28 Feb 91 02:55:49 GMT In article <24280:Feb2802:55:4991@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: ... If David opens his eyes he will see that what I am proposing will ALWAYS improve the portability of efficient code. But because this requires a bit of work on the compiler-writer's part, his eyes will remain closed. ... I question whose eyes are closed here. Exactly how many compiler writers do you expect to conform to your new ad hoc standard ? In what timeframe ? If you rely exclusively on the kindness of compilter writers, you will have zero portability. Methods which start with class libraries (modules etc.), are completely portable. Performance can be dialed in over time, and if need be compilers altered. Portability is maximal; as even old systems can provide the required functionality. This is precisely why languages features such as modules and operator overloading were put into ISO DIS 1539 Fortran. -- ---------------------------------------------------------------- Keith H. Bierman kbierman@Eng.Sun.COM | khb@chiba.Eng.Sun.COM SMI 2550 Garcia 12-33 | (415 336 2648) Mountain View, CA 94043