Re: Why do we still assemble?

hbaker@netcom.com (Henry G. Baker)
Thu, 14 Apr 1994 16:18:45 GMT

          From comp.compilers

Related articles
[26 earlier articles]
Re: Why do we still assemble? ok@cs.rmit.oz.au (1994-04-13)
Re: Why do we still assemble? rfg@netcom.com (1994-04-13)
Re: Why do we still assemble? rfg@netcom.com (1994-04-13)
Re: Why do we still assemble? zstern@adobe.com (1994-04-13)
Re: Why do we still assemble? mps@dent.uchicago.edu (1994-04-14)
Re: Why do we still assemble? bill@amber.ssd.csd.harris.com (1994-04-14)
Re: Why do we still assemble? hbaker@netcom.com (1994-04-14)
Re: Why do we still assemble? djohnson@arnold.ucsd.edu (1994-04-15)
Re: Why do we still assemble? philw@tempel.research.att.com (1994-04-15)
Re: Why do we still assemble? pardo@cs.washington.edu (1994-04-15)
Re: Why do we still assemble? wirzeniu@cc.helsinki.fi (Lars Wirzenius) (1994-04-16)
Re: Why do we still assemble? hbaker@netcom.com (1994-04-16)
Re: Why do we still assemble? hrubin@b.stat.purdue.edu (1994-04-17)
[1 later articles]
| List of all articles for this month |
Newsgroups: comp.compilers
From: hbaker@netcom.com (Henry G. Baker)
Keywords: assembler, design
Organization: Compilers Central
References: 94-04-075 94-04-096
Date: Thu, 14 Apr 1994 16:18:45 GMT

zstern@adobe.com (Zalman Stern) writes:
>I still end up using gcc for certain things for the ability to write
>inline assembly. This is an incredibly valuable tool and should not be
>left out of the compiler, even if you don't emit assembly. (Which implies
>that you may have to wire an assembler into the compiler.) I'd also like
>to see more tools which support the idea that producing assembly is a
>cooperative process involving the programmer. A process involving
>translation steps where the programmer can provide more information and
>guide the decisions the tools must make. The goal here is not so much to
>make writing the code faster than writing hand optimized assembly, but to
>improve correctness and portability. To be useful, the added hints
>probably have to eventually be fed back so they come in with the
>high-level source code.


I think that what you're looking for is a notion that has been called
'reflective' programming, in which you get sometimes get 'beneath the
surface' of the abstraction for some important purpose. People in the
Lisp world have done and thought about this a long time, both because it
was possible [Lisp has EVAL :-)] and sometimes necessary [some Lisp
implementations can be slow :-(].


The basic idea is to preserve the higher-level protocol -- e.g., the
syntactic mechanism for calling a standard subroutine -- but then to be
able to tailor the _implementation_ of that protocol for a particular
situation -- e.g., you know more about these particular arguments than the
compiler can possibly figure out.


Object-oriented systems, and especially the earliest Smalltalks, were very
interested in this 'infinite regress of abstraction and implementation'.
Unfortunately, the current OO systems seem to be stuck at a single level,
and don't recognize that the idea generalizes.


The joker in 'reflective' schemes is to try to prove that the tailored
implementation actually implements the higher-level abstraction. After
all, the whole point of abstraction is to be able to rely on the high
level idea, so that you don't have to look at every level to prove that
the system works. Unfortunately, the very times you need to use
reflection, you are by definition in the realm where the system will not
be capable of understanding your implementation code.


Of course, greater power means greater ability to do both good and bad.
Therefore, only people who have been certified as Professionally Competent
Programmers by the SEI will be allowed to use tools as powerful as this.
;-) ;-)
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.