Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!bfmny0!tneff From: tneff@bfmny0.UU.NET (Tom Neff) Newsgroups: comp.lang.c Subject: Re: swap(x,y) Message-ID: <14706@bfmny0.UU.NET> Date: 20 Sep 89 15:15:35 GMT References: <8350@boring.cwi.nl> <14479@haddock.ima.isc.com> <1545@l.cc.purdue.edu> <10897@smoke.BRL.MIL> <604@rwthbs.UUCP> <4151@buengc.BU.EDU> <714@philmtl.philips.ca> Reply-To: tneff@bfmny0.UU.NET (Tom Neff) Organization: ^ Lines: 23 Summary: Expires: Sender: Followup-To: In article <714@philmtl.philips.ca> ray@philmtl.philips.ca (Raymond Dunn) writes: >This sounds dangerously like the arguments made by Herman Rubin that 'C' >should provide facilities to access all the functionality of the machine >architecture in some direct way. > >Since when was that the goal of *any* language other than assemblers? Examples do exist. PL/M-86 and BLISS come to mind. Every so often someone at a big computer company decides that assembler is too dangerous for systems programmers to use (I don't necessarily disagree) and comes up with a higher level language that has to-the-metal facilities built in. These are seldom portable however! To the extent that C strives for portability such things shouldn't be built in. However I would enjoy using specific implementations that offered optional bare-machine extensions for systems and driver work. The "#pragma builtin" approach is usually good enough. -- 'We have luck only with women -- \\\ Tom Neff not spacecraft!' *-((O tneff@bfmny0.UU.NET -- R. Kremnev, builder of FOBOS \\\ uunet!bfmny0!tneff (UUCP)