[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Benchmarking temporary Lisp objects [Was: Re: [RFC] temporary Lisp_S

From: Paul Eggert
Subject: Re: Benchmarking temporary Lisp objects [Was: Re: [RFC] temporary Lisp_Strings]
Date: Wed, 03 Sep 2014 09:42:29 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0

Dmitry Antipov wrote:

1) Function-scoped version using alloca (assuming statement expressions):
2) Block-scoped version using implicit stack allocation (assuming
statement expressions):
3) Block-scoped version assuming no statement expression but compound
If we have 2), why we need 1) at all? 2) in a top-level function scope
is an equivalent to 1), isn't it?

Correct. We'd need (1) e.g. to build up a list in a loop, and have the list survive until function exit. But on further thought this is probably a dangerous feature, since it'll be too tempting to write unbounded loops. So let's not do (1).

In 3), how we can be sure that Lisp_Cons is properly aligned on stack?

For GCC, we can define struct Lisp_Cons via 'struct __attribute__ ((aligned (GCALIGNMENT))) Lisp_Cons { ... };'. For compilers that don't support this syntax we can align the struct by hand, by using a character-array compound literal that's a bit too large, aligning the resulting pointer by hand, and then using the aligned pointer.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]