[Top][All Lists]

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

Re: Proposal: immediate strings

From: Dmitry Antipov
Subject: Re: Proposal: immediate strings
Date: Tue, 29 May 2012 10:55:34 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1

On 05/24/2012 09:17 AM, Stefan Monnier wrote:

+#if __GNUC__>  1 /* Any GCC still in use should support this.  */
+#define PACKED __attribute__((packed))
+#define PACKED

Let's not use "packed" structures: too much trouble.

To avoid using 'packed' attribute and speedup an inefficient access to 
field, it's possible to use 'ptrdiff_t X : BITS_PER_PTRDIFF_T - 2'
bitfields - it's still wide enough to hold the values up to STRING_BYTES_BOUND.

Actually, we can allocate all the pure strings as "immediate strings"
(within the limits of imm.nbytes, of course), in which case we'd have
strings with more bytes than STRING_IMM_MAX, so while this assertion may
have been useful for debugging, we'll want to get rid of it.

I'm not sure it's worth making string code even more complicated with this.

Is that really 100% reliable?  Why not use the `intervals' field with
a 0xdeadbeef pointer instead?

Better solutions are welcome, never seen a crash with this; 'intervals'
field can't be used because NEXT_FREE_LISP_STRING (X) = Y will overwrite


Attachment: immstr.patch
Description: Text document

reply via email to

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