Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.std.c > #1367

Re: Structure Packing.

Path csiph.com!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail
From Walter Banks <walter@bytecraft.com>
Newsgroups comp.std.c
Subject Re: Structure Packing.
Date Tue, 12 Jun 2012 11:51:58 -0400
Organization Aioe.org NNTP Server
Lines 62
Message-ID <4FD7659E.89172310@bytecraft.com> (permalink)
References <12b3df42-f6a0-4411-a5e5-136900f8255b@googlegroups.com> <jqovin$9sr$1@dont-email.me> <4FD6ABFA.72F52C75@bytecraft.com> <jr7fpp$eti$1@dont-email.me>
NNTP-Posting-Host nbZIcP9ujGt3Z7oU6KK4Bg.user.speranza.aioe.org
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
X-Complaints-To abuse@aioe.org
X-Mailer Mozilla 4.79 [en]C-CCK-MCD NSCPCD479 (Windows NT 5.0; U)
X-Accept-Language en
X-Notice Filtered by postfilter v. 0.8.2
Xref csiph.com comp.std.c:1367

Show key headers only | View raw



Eric Sosman wrote:

> > A current compiler project I am working on potentially has a completely different twist on struct placement.
> >
> > There is quite a list of hardware based alignment requirements based on boundaries. It is a RAM poor processor and I am being very
> > tempted to assign global variables in the holes left behind in global structs.  My guess the need for RAM space will outweigh other
> > considerations.
>
>      Don't do it: Operations on the named elements of a struct are
> not guaranteed to preserve the contents of the holes.  For example
>
>         struct s {
>             unsigned char flag;
>             // possible hole here
>             unsigned int value;
>         } x;
>         unsigned char *hole = &x.flag + 1;
>         size_t hole_size = (unsigned char*)&x.value - hole;
>         if (hole_size > 0) *hole = 0xFF;
>         flag = 42;
>         if (hole_size > 0) assert(*hole == 0xFF);  // may fail
>
>         struct s y = x;
>         assert(memcmp(&x, &y, sizeof x) == 0);  // may fail
>
> If you need the variable, give it a name and make it an ordinary
> struct element.
>
>      If you're worried about different alignments on different
> systems and it's difficult to find one arrangement that works
> efficiently for all, consider generating system-specific struct
> definitions from a data file during your build process.  You can
> then give each system its own arrangement of the struct elements
> to pack things as efficiently as possible.  (Of course, this won't
> work for struct elements that "must be first" or "must appear in
> such-and-such order" -- but if memory scarcity is extreme, that
> sacrifice may be worthwhile.)

Your points are well taken. I have resolved every issue in this specific
processor except memcpy and memcmp both of which are rarely
used in embedded systems.

I am not worried about different alignments on different processors.

In this specific case first fit in a struct allocation is significantly tighter
allocation than next available that will fit. I am uncomfortable even
with packing the struct elements out of order.

I am about to re-write the struct allocator (within the next day or two)
and probably will at least use first fit in the struct or perhaps a
tetris style packer.

At that point I will see what hole metrics come out of a
bunch of regression tests with actual application code.


Thanks for the comments

w..

Back to comp.std.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Structure Packing. John Kearney <dethrophes@googlemail.com> - 2012-06-06 17:27 -0700
  Re: Structure Packing. James Kuyper <jameskuyper@verizon.net> - 2012-06-06 21:19 -0400
    Re: Structure Packing. Walter Banks <walter@bytecraft.com> - 2012-06-11 22:39 -0400
      Re: Structure Packing. Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-12 09:21 -0400
        Re: Structure Packing. Walter Banks <walter@bytecraft.com> - 2012-06-12 11:51 -0400
          Re: Structure Packing. Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-06-12 18:37 +0200
            Re: Structure Packing. Walter Banks <walter@bytecraft.com> - 2012-06-12 15:06 -0400
              Re: Structure Packing. Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-12 16:22 -0400
                Re: Structure Packing. Walter Banks <walter@bytecraft.com> - 2012-06-12 17:44 -0400
                Re: Structure Packing. Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-06-13 15:53 +0200
                Re: Structure Packing. Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-06-18 12:37 +0300
        Re: Structure Packing. Martin Shobe <martin.shobe@yahoo.com> - 2012-06-12 16:22 +0000
          Re: Structure Packing. Walter Banks <walter@bytecraft.com> - 2012-06-12 15:24 -0400
            Re: Structure Packing. Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-12 16:33 -0400
              Re: Structure Packing. Walter Banks <walter@bytecraft.com> - 2012-06-12 17:17 -0400
  Re: Structure Packing. Keith Thompson <kst-u@mib.org> - 2012-06-06 18:35 -0700
    Re: Structure Packing. John Kearney <dethrophes@googlemail.com> - 2012-06-06 21:58 -0700
      Re: Structure Packing. Keith Thompson <kst-u@mib.org> - 2012-06-06 23:54 -0700
        Re: Structure Packing. John Kearney <dethrophes@googlemail.com> - 2012-06-07 07:47 -0700
          Re: Structure Packing. James Kuyper <jameskuyper@verizon.net> - 2012-06-07 12:39 -0400
    Re: Structure Packing. jacob navia <jacob@spamsink.net> - 2012-06-07 11:14 +0200
      Re: Structure Packing. Keith Thompson <kst-u@mib.org> - 2012-06-07 09:46 -0700
        Re: Structure Packing. John Kearney <dethrophes@googlemail.com> - 2012-06-07 11:57 -0700

csiph-web