software/!RELEASES/ircservices/achurch.org/services/lists/ircservices-coding/2002/000328.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
   2 <HTML>
   3  <HEAD>
   4    <TITLE> [IRCServices Coding] GCC3
   5    </TITLE>
   6    <LINK REL="Index" HREF="index.html" >
   7    <LINK REL="made" HREF="mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20GCC3&In-Reply-To=004601c1be40%2413b778a0%240200000a%40stormkeepers.com">
   8    <META NAME="robots" CONTENT="index,nofollow">
   9    <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
  10    <LINK REL="Previous"  HREF="000327.html">
  11    <LINK REL="Next"  HREF="000342.html">
  12  </HEAD>
  13  <BODY BGCOLOR="#ffffff">
  14    <H1>[IRCServices Coding] GCC3</H1>
  15     <B>Trevor Talbot</B>
  16     <A HREF="mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20GCC3&In-Reply-To=004601c1be40%2413b778a0%240200000a%40stormkeepers.com"
  17        TITLE="[IRCServices Coding] GCC3">quension at softhome.net
  18        </A><BR>
  19     <I>Mon Feb 25 18:28:57 PST 2002</I>
  20     <P><UL>
  21         <LI>Previous message: <A HREF="000327.html">[IRCServices Coding] GCC3
  22 </A></li>
  23         <LI>Next message: <A HREF="000342.html">[IRCServices Coding] GCC3 sizes
  24 </A></li>
  25          <LI> <B>Messages sorted by:</B>
  26               <a href="date.html#328">[ date ]</a>
  27               <a href="thread.html#328">[ thread ]</a>
  28               <a href="subject.html#328">[ subject ]</a>
  29               <a href="author.html#328">[ author ]</a>
  30          </LI>
  31        </UL>
  32     <HR>
  33 <!--beginarticle-->
  34 <PRE>On Monday, February 25, 2002, at 01:04  PM, Kelmar K. Firesun wrote:
  35
  36 &gt;<i> ----- Original Message -----
  37 </I>&gt;<i> From: &quot;Andrew Church&quot; &lt;<A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">achurch at achurch.org</A>&gt;
  38 </I>&gt;<i>
  39 </I>&gt;&gt;&gt;&gt;<i>      The major problem I have with GCC 3.0 is that it reorders
  40 </I>&gt;&gt;&gt;&gt;<i> structures
  41 </I>&gt;&gt;&gt;&gt;<i> (or at least did at one point), which would break convert-db, and in
  42 </I>&gt;&gt;&gt;&gt;<i> general is a Bad Idea (among other things it prevents you from laying
  43 </I>&gt;&gt;&gt;&gt;<i> structures on top of data in memory).  Does anyone know if this has
  44 </I>&gt;&gt;&gt;&gt;<i> been
  45 </I>&gt;&gt;&gt;&gt;<i> fixed or if there's a way around it?
  46 </I>&gt;&gt;&gt;<i>
  47 </I>&gt;&gt;&gt;<i> Are you sure it reordered them? It might just have changed the padding
  48 </I>&gt;&gt;&gt;<i> between members, which compilers have been known to do in the past.
  49 </I>&gt;&gt;&gt;<i> Anyhow, I haven't tried convert-db yet but I will when I get the
  50 </I>&gt;&gt;&gt;<i> chance
  51 </I>&gt;&gt;<i>
  52 </I>&gt;&gt;<i>      To be perfectly honest, that's based on hearsay--I haven't
  53 </I>&gt;&gt;<i> confirmed
  54 </I>&gt;&gt;<i> it one way or the other.  But I do recall quite a lot of discussion on
  55 </I>&gt;&gt;<i> that
  56 </I>&gt;&gt;<i> point, so I'd like to have confirmation that it does work before
  57 </I>&gt;&gt;<i> &quot;officially&quot; endorsing it.
  58 </I>
  59 Reordering is not permitted by the ANSI/ISO C standards.
  60
  61 &gt;<i> I could certanly see it padding the data structures.
  62 </I>&gt;<i> This would be to optimize memory access by keeping things
  63 </I>&gt;<i> aligned with the CPU's WORD size.  64bits in the case of
  64 </I>&gt;<i> most Intel Pentiums if I recall correctly.
  65 </I>
  66 Usually 32 bits, possible exceptions where optimized structures
  67 occur (MMX usage, for example).
  68
  69 &gt;<i> For example, if you have a structure like so:
  70 </I>&gt;<i>
  71 </I>&gt;<i> struct foo
  72 </I>&gt;<i> {
  73 </I>&gt;<i>     int_16 bar;
  74 </I>&gt;<i>     int_8 baz;
  75 </I>&gt;<i> };
  76 </I>&gt;<i>
  77 </I>&gt;<i> The compiler would append or prepend (depending on compiler)
  78 </I>&gt;<i> on an extra 40bits of data to align it in memory on each
  79 </I>&gt;<i> allocation.
  80 </I>
  81 Under 32bit x86, it's likely to add 8 bits of padding to the end
  82 of the structure.  The alignment is for the width of the largest
  83 datatype.
  84
  85 &gt;<i> This is a very common optimization for speed in many compilers.
  86 </I>&gt;<i> I'm actually very surprised that GCC would just now be
  87 </I>&gt;<i> implementing it.
  88 </I>
  89 Not just for speed; some platforms require aligned types
  90 (such as Motorola 68k and PPC under certain conditions).
  91 It's also well-documented by the C standards.
  92
  93 Partly for this reason, mapping structs onto arbitrary data in
  94 memory results in undefined behavior.
  95
  96 -- Quension
  97
  98
  99 </PRE>
 100
 101 <!--endarticle-->
 102     <HR>
 103     <P><UL>
 104         <!--threads-->
 105         <LI>Previous message: <A HREF="000327.html">[IRCServices Coding] GCC3
 106 </A></li>
 107         <LI>Next message: <A HREF="000342.html">[IRCServices Coding] GCC3 sizes
 108 </A></li>
 109          <LI> <B>Messages sorted by:</B>
 110               <a href="date.html#328">[ date ]</a>
 111               <a href="thread.html#328">[ thread ]</a>
 112               <a href="subject.html#328">[ subject ]</a>
 113               <a href="author.html#328">[ author ]</a>
 114          </LI>
 115        </UL>
 116
 117 </body></html>