|Designing a calling convention for a Lisp->C compiler firstname.lastname@example.org (Manuel) (2010-06-03)|
|Re: Designing a calling convention for a Lisp->C compiler email@example.com (Marc van Lieshout) (2010-06-03)|
|Re: Designing a calling convention for a Lisp->C compiler firstname.lastname@example.org (russell kym horsell) (2010-06-04)|
|Re: Designing a calling convention for a Lisp->C compiler email@example.com (russell kym horsell) (2010-06-06)|
|Re: Designing a calling convention for a Lisp->C compiler firstname.lastname@example.org (BGB / cr88192) (2010-06-06)|
|Re: Designing a calling convention for a Lisp->C compiler email@example.com (Robbert Haarman) (2010-06-07)|
|Re: Designing a calling convention for a Lisp->C compiler firstname.lastname@example.org (Gene) (2010-06-06)|
|Date:||Sun, 6 Jun 2010 21:42:32 -0700 (PDT)|
|Keywords:||Lisp, code, translator|
|Posted-Date:||09 Jun 2010 19:02:26 EDT|
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
Return to the
Search the comp.compilers archives again.