🚀 go-pugleaf

According to hrubin@pop.stat.purdue.edu (Herman Rubin):
>In article <282002D1.EA1@tct.com>, chip@tct.com (Chip Salzenberg) writes:
>> Give us a spec, and we'll have something to discuss.  Why spend all
>> this time yammering about a hypothetical compiler, when that same
>> effort expended in spec-writing could produce a REAL IMPLEMENTATION?
>
>I have several times responded to this type of posting in email, and
>have not even received clarification of my questions.

Rubin-san has not E-Mailed me on this subject -- but no matter; he
chooses to carry on his correspondence in comp.arch.

>1.  I am not quite sure what you mean by a specification.

A detailed and precise description of the desired compiler features
and input format.  It would tell me what I need to know to write a
HROL (Herman Rubin Oriented Language) compiler.

Let me give a tiny example.

    To define a binary operator <op> to be supported by a machine
    instruction <inst>, code the following:

        OPERATOR "<op>" ;
           { BINARY | UNARY } ;
           PRECEDENCE { AFTER | BEFORE | SAME } <other-op> ;
           ARGUMENT 1 (<type>, ...) [ IN ("reg1",...) ] ;
           [ ARGUMENT 2 (<type>, ...) [ IN ("reg2",...) ] ; ]
           INSTRUCTION "<inst> ARG1,ARG2" ;
           RESULT (<type>) IN ("reg") ;

Of course, this tiny example doesn't address indirection, or processor
addressing modes, etc, etc.  But it does give the flavor of what I mean
by "specification".

Got the picture yet?
-- 
Brand X Industries Sentient and Semi-Sentient Being Resources Department:
        Because Sometimes, "Human" Just Isn't Good Enough [tm]
     Chip Salzenberg         <chip@tct.com>, <uunet!pdn!tct!chip>