From: Chip Salzenberg <[EMAIL PROTECTED]>
   Date: Tue, 14 Jun 2005 00:04:54 +0200

   . . . you probably want to read it, if only because it will point you
   to AN UPDATED PDD.  Really.

Great!  Pardon the typing; it's hard when my head is spinning . . .

   FWIW, there is one thing that jumps out at me:

   It looks to me like the "Required features are missing:" items are
mostly things that would require the compiler for a given language to
generate code for each particular case.  There may be partial exceptions
for different languages, but defaulting in particular is almost
certainly going to involve conditional evaluation of application code
(e.g. it does in Lisp).

   So, IMHO, it seems more versatile to have these opcodes operate on
one arg/return at a time, instead of monolithically on the whole list:

        set_arg <index>, <flags>, <val>
        set_return <index>, <flags>, <reg>
        <reg> = get_param <index>, <flags>
        <reg> = get_result <index>, <flags>

where <index> can be an Ireg or a constant.  This makes it easier to
extend <flags>.  It also leaves room for such things as:

        flatten_arg <index>, <flags>, <Preg>
        foldup_return <index>, <flags>, <Preg>
        <reg> = foldup <index>          ## same; need another for returns?

rather than encoding these in <flags>.  (With the objection that
flatten_arg in the middle of the list screws up indexing for the rest of
the args.)

   To ignore a parameter, simply don't fetch it.  To ignore a return,
simply don't supply a register for it.

   One still needs something equivalent to argc (but probably only one),
in order to find out what needed defaulting.  To see if whether or not
the Nth argument was supplied [1], just compare N to argc.

   I would also argue that the generated PIR should be in charge of
signalling language-specific "too few/many" args errors.  (The language
may be required to do so in any case.)

   If we wanted to be really radical (is my head still spinning?), we
could promote call frames to first-class objects.  That way, compilers
could easily overlap the assembly of nested calls, as for a stack
machine.  If frames were implemented as array-like PMCs, then C<push>
would be a natural way to add the next arg, but it's not clear to me how
to provide separate indexing cleanly for calls and returns.  (Use the
sign of the index?  Yuck.)  In any case, I'm sure something like this
has been done before, but I'm not enough of a compiler/architecture geek
to know.

   If I've gone too far out on a limb [2], then I apologize; I'll let my
head slow down a bit before I post again.  ;-}

                                        -- Bob Rogers
                                           http://rgrjr.dyndns.org/

[1]  Common Lisp allows a "supplied-p-parameter" variable to be bound
     for optional and keyword arguments; see
     http://www.lispworks.com/documentation/HyperSpec/Body/03_da.htm for
     details.

[2]  Is GMP going too far out on a libm?  Oh, it must be past time for
     bed . . .

Reply via email to