Bob Rogers wrote:

   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>

If somehow possible, I'd really like to avoid indirect register addressing. The register allocator can't track the involved register because the effect can happen at runtime. See also the C<setp_ind> opcode and the comment there.

 It also leaves room for such things as:

        flatten_arg <index>, <flags>, <Preg>

While it's not coded yet, it could be something like:

  .get_params "(0x8)", $P5, $P6, $P7

and you'll get the first 3 values from the passed in array.

        foldup_return <index>, <flags>, <Preg>

  .set_returns "(0x10,0x10,0x10)", $P5, $P6, $P7
  # mark 3 pmcs as being returned as array

The array will actually not be created except the caller awaits one.

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

Yep - that's still doable, but not in the middle, which looks insane to me anyway.

   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.

The proposal has argcI, argcP, ...

   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.)

I expect that we end up with some context error/warning flags that cover various mismatches of argument passing. Please note: the old conventions didn't really specify what should happen for an args/params mismatch.

It was more a "don't do that then or check it yourself".

   If we wanted to be really radical (is my head still spinning?), we
could promote call frames to first-class objects.

Let's postpone this a bit.

[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.

Could you please translate this to PIR or some such ;-)

leo

Reply via email to