Re: Designing a calling convention for a Lisp->C compiler

On Jun 3, 9:05 am, Manuel <msim...@gmail.com> wrote:
> Hello group!
>
> I am building a Lisp to C compiler. I don't know very much about the
> lowlevel details of things like stdarg, so I it is rather unclear for
> me how to go about making this as efficient as possible.
>
> The requirements are similar to Common Lisp parameter passing:
>
> There are two groups of parameters, _positional_ and _named_
> parameters, and these are strictly separated (in contrast to Python,
> where the call site may determine what arguments to pass as positional
> and named arguments.)
>
> There may be zero or more _required_ positional arguments, zero or
> more _optional_ positional arguments, and any additional positional
> arguments may be collected by the called function into a "rest"
> parameter, a list.
>
> The named parameters are always optional. Additionally, the called
> function may collect _all_ named arguments into an "all-keys"
> parameter, a dictionary.
>
> One possible calling convention would be to pass the numbers of
> positional and named parameters as the first two arguments, followed
> by the positional arguments, followed by pairs of name/argument for
> the named parameters.
>
> lisp_obj *
> lisp_function(uint16 npos, uint16 nnamed, ...);
>
> A call like (some-function a b :name-1 c :name-2 d) is a call to a
> function called some-function with two positional arguments with the
> values a and b, and the named parameters name-1 and name-2 with the
> values c and d, respectively.
>
> The compiler would translate this call to something like this:
> some_function(2, 2, a, b, "name-1", c, "name-2", d);
>
> The function would then use stdarg to take the passed arguments apart,
> and assign them to local variables inside the function.
>
> What do you think?
>
> Thanks in advance for any help!


Don't forget to think about garbage collection. Conservative
collection implemented over C (like the Boehm collector) is fairly
risky, as C compiler changes can cause new, difficult-to-find bugs to
appear from nowhere. Precise collection needs correct access to
roots. There are various schemes, but you won't be able to reliably
find pointers on the C runtime stack. Gnu Common Lisp uses an array
as a stack. I've implemented an interpreter that maintains a linked
list of activation records as structs on the C runtime stack. The
collector knows how to traverse this list to find gc roots based on
type tags.

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