[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal: immediate strings
From: |
Paul Eggert |
Subject: |
Re: Proposal: immediate strings |
Date: |
Tue, 22 May 2012 15:13:47 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 |
On 05/22/2012 01:51 PM, Miles Bader wrote:
> Dmitry Antipov <address@hidden> writes:
>> + This assumes that sizeof (EMACS_INT) is equal to sizeof (void * ). */
>
> Not a good assumption (especially given that it's easy to do it right)...
Agreed, especially since the assumption is false on x86
when configured --with-wide-int. Another comment:
#if __GNUC__ > 1 /* Any GCC still in use should support this. */
#define PACKED __attribute__((packed))
#else
#define PACKED
#endif
Shouldn't this also support lcc / MSVC / Sun Studio (#pragma pack(1)),
and IRIX cc (#pragma pack 1). Better yet, have 'configure' check
for the packing syntax. Or do these other compilers not support
the right kind of packing?
Come to think of it, why use packing at all?
Why not use a layout like the following
in struct Lisp_String?
union {
/* If IMMBIT is 1, use IMM; otherwise use DAT. */
struct {
unsigned immbit : 1;
unsigned size : 7;
unsigned gcmarkbit : 1;
unsigned size_byte : 7;
unsigned char data[STRING_IMM_MAX];
} PACKED imm;
struct {
unsigned immbit : 1;
EMACS_UINT size : BITS_PER_EMACS_INT - 1;
unsigned gcmarkbit : 1;
EMACS_UINT size_byte : BITS_PER_EMACS_INT - 1;
unsigned char *data;
} PACKED dat;
} u;
That way, we don't need to worry about "packed".
There are other possibilities too, I expect.
The idea is that "packed" is not simply a portability
problem, it's a performance issue, and we're better off
avoiding it if we can.
- Proposal: immediate strings, Dmitry Antipov, 2012/05/22
- Re: Proposal: immediate strings, Miles Bader, 2012/05/22
- Re: Proposal: immediate strings,
Paul Eggert <=
- Re: Proposal: immediate strings, Stefan Monnier, 2012/05/24
- Re: Proposal: immediate strings, Ken Raeburn, 2012/05/24
- Re: Proposal: immediate strings, Paul Eggert, 2012/05/24
- Re: Proposal: immediate strings, Stefan Monnier, 2012/05/24
- Re: Proposal: immediate strings, Paul Eggert, 2012/05/24
- Re: Proposal: immediate strings, Stefan Monnier, 2012/05/24
- Re: Proposal: immediate strings, Paul Eggert, 2012/05/24
- Re: Proposal: immediate strings, Dmitry Antipov, 2012/05/25
- Re: Proposal: immediate strings, Paul Eggert, 2012/05/25