Article View: comp.arch
Article #10576Re: Compilers, architecture, efficiency, and HR
From: Michael S. Pereckas
Date: Fri, 03 May 1991 19:58
Date: Fri, 03 May 1991 19:58
47 lines
2789 bytes
2789 bytes
In <11813@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>I have not specified a language, but a frame on which to hang a language.
>Unlike the present languages, this frame does not declare certain operations,
>such as + - * / & | ~ ^ ** << >> as THE primitive operators, but allows free
>extension of the notion of primitive operator. If a user wishes to use [) as
>an operator symbol, there is no bar to this. If the user wishes to deliberately
>override types, likewise. If the user wishes to define an operation in a maner
>using assembler instructions, transfer on overflow, etc., which cannot be
>conveniently done with the present "portable" primitives, go ahead.
Sounds vaguely (buzzword alert) object oriented to me. Except that
you not only don't want to pay the usual performance penalty of OO
languages, you want a speed boost over plain C or whatever. And you
don't want to write any assembly (although another user might)?
(I'm assuming that this is a modified C. If you like Ada better,
replace `C' with `Ada' in the following text...)
What if you could define new operations
example:
@ is defined here as some complicated function of two variables
using either C or assembler
later on you get to write stuff like this:
x = y @ z
The code for the @ operation is automagically inlined.
Appropriate ifdefs would let you include in the source file several
versions of the @ code, perhaps in portable C and two different
assembly languages.
You (H. Rubin) would like (I think) to be able to write several
different but equivalent versions in portable C, and have the compiler
automagically select the one it can produce the best code for. This
sounds like it could be hard. Perhaps you could include some test
examples, and the compiler could compile each version and benchmark
it?
Am I getting close?
--
< Michael Pereckas <> m-pereckas@uiuc.edu <> Just another student... >
"This desoldering braid doesn't work. What's this cheap stuff made
of, anyway?" "I don't know, looks like solder to me."
Technical Details
Message-ID:
<1991May3.195856.13671@ux1.cso.uiuc.edu>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!mp.cs.niu.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!msp33327References:
<1991Apr29.155945.29907@rice.edu> <41279@genrad.UUCP> <282002D1.EA1@tct.com> <11813@mentor.cc.purdue.edu>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!mp.cs.niu.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!msp33327 From: msp33327@uxa.cso.uiuc.edu (Michael S. Pereckas) Newsgroups: comp.arch Subject: Re: Compilers, architecture, efficiency, and HR Message-ID: <1991May3.195856.13671@ux1.cso.uiuc.edu> Date: 3 May 91 19:58:56 GMT References: <1991Apr29.155945.29907@rice.edu> <41279@genrad.UUCP> <282002D1.EA1@tct.com> <11813@mentor.cc.purdue.edu> Sender: usenet@ux1.cso.uiuc.edu (News) Organization: University of Illinois at Urbana Lines: 47