🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #10576

Re: Compilers, architecture, efficiency, and HR

#10576
From: Michael S. Pereckas
Date: Fri, 03 May 1991 19:58
47 lines
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!msp33327
References: <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