emacs-devel
[Top][All Lists]
Advanced

[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.



reply via email to

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