Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!timbuk!cs.umn.edu!ux.acs!vw.acs.umn.edu!dhoyt
From: dhoyt@vw.acs.umn.edu
Newsgroups: comp.std.c++
Subject: Re: Packing, Ordering, and Rearranging
Message-ID: <2275@ux.acs.umn.edu>
Date: 25 Sep 90 19:59:21 GMT
Sender: news@ux.acs.umn.edu
Organization: University of Minnesota, Academic Computing Services
Lines: 49

In article <204@xstor.UUCP>, iverson@xstor.UUCP (Tim Iverson) writes...
>While your statement is true, it is very misleading.  It is due to the lack
>of a standard when exercising such precise control that makes programs
>non-portable, not the existence of such code in a program.  If you'll pause
>to reflect a momoment, you'll realize that every area in a language that
>allows the vender to make a decision on how to bridge a gap between cause
>and effect results in a potential portability problem.

  No, even truly 'portable' extentions cause portablity problems.  Take the
Cray for instance.  It has no 'char' datatype and can address only a word
(bytes do not exist).  To address a character, the low order (32 on a Cray 2)
bits of an address point to the word of the character and the top three bits
(63:61 - ignored by the hardware) are the character offset from the beginning
of the word.

  As you might guess all character resultion is done is software.
        if ( c[n] == 'a' )
will take a lot more cycles than a 1.0 / f.  As a result any non-aligned
manipulations are very, very slow.

  Now take, the average brainless programmer that micro-'optimizes' his or her
code to 'save' memory in structures.  They 'know' that with

        struct a {
                char one[ 2 ];
                int  two;
        };

the size if the structure is 

        sizeof( struct a ) == 2 + sizeof( int )

And takes advantage of this packing.  Now Cray has two options.  Break the
code or produce very, very slow code.  If the standard requires it to be
packed, i.e. the code is defacto portable, it still is a portablity nightmare;
Cray is forced to produce very slow code.  Blech.

  The micro programmer that cries, "I never thought it was going to be ported
to a Cray!"  Just hasn't hasn't worked very long.  Also it is interesting to
note that this 'optimization' will actually slow any machine with a 32 or 64
bit bus (all mainframes, mini's and most workstations) by causing all sorts of
non-aligned references and writes.

  The ONLY time that there is a real need for the programmer to understand
the underlying structure layout is when the programmer is dealing device
drivers and whatnot.  The need to save memory (aka 640k) is better addressed
by a make-structures-very-tight switch on the compiler.

david paul hoyt | dhoyt@vx.acs.umn.edu | dhoyt@umnacvx.bitnet