delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1995/05/07/22:14:06

Date: Mon, 8 May 1995 10:17:57 +0900
From: Stephen Turnbull <turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp>
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Int's need to be on paragraph boundaries?

   From: RDC <rdc AT freenet DOT vancouver DOT bc DOT ca>

   On Sun, 7 May 1995, Eli Zaretskii wrote:
   > > i'm having an interesting problem.  i have the following struct
   > > that i am reading in from a file: somehow a byte is getting
   > > lost, and it doesn't make much sense.  i could
   > 
   > That's because the compiler is free to pad structure fields to make
   > memory accesses more efficient.  If you want to make the structure
   > packed (i.e. that its sizeof will be 13), use the __attribute__((packed))
   > extension of GNU C (it's in the docs).
   > 
    Is there an 'easy' pack/unpack conversion ?

    IE: I want to 'pack' for space considerations and 'unpack' for speed.
      ...  or ... would I need _two_ different arrays and move bytes between 
   (slow and defeats any 'gains') ... (No sparse MAT code please ;> ).

Well, in the case cited, presumably the file is large and packed is
important.  If you're not reading the whole file in, then you can do

struct disk_record {
    char one_char;
    int  one_int _attribute ((packed));
    };

struct mem_record {
    char one_char;
    int  one_int;
    };

and copy back and forth trivally.  This only makes sense if memory
considerations aren't important and you do a lot of manipulation of
each mem_record.

If you don't consider maintaining your own cache "easy," well, ....
And you're just plain wrong about defeating speed gains.  That depends
on how much each record is read and written, and how much the
processor cares about alignment.

-- 
Stephen Turnbull  /  Yaseppochi-gumi  /  <turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp>
http://turnbull.sk.tsukuba.ac.jp/      anon FTP: turnbull.sk.tsukuba.ac.jp
Check out Kansai-WWW, too ------------> http://pclsp2.kuicr.kyoto-u.ac.jp/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019