[coLinux-devel] packed structures, long long

[Ballard J. <sac...@ho...>]

I was curious about the intention of the packed data structures.  There are
many of them.  I wondered if they are required to be packed or if they just
save space being packed.  Packed structures are great at size but at the
cost of speed being non-aligned.  If there is no requirement for them to be
packed, then would an option that optimizes for speed be pratical?

About the "long long,"  it is unfortunate that such C syntax is not
standardized.  I imagine it is one of the reasons why Intel and other
manufacturers hold back their 64 bit processors.  That is one of the reasons
why a header file is usually made to standardized the syntax at the project
level.  Most variables within functions do not need a project level syntax,
yet it is helpful.  The data structures, however, need a standard.  An
example:

In the project level header:

#define coLinuxNatural8bit        unsigned char
#define coLinuxNatural16bit        unsigned short
#define coLinuxNatural32bit        unsigned long
#define coLinuxNatural64bit        unsigned long long

In a specific structure definition header:

struct _coLinuxExample  {
    coLinuxNatural16bit        one ;
    coLinuxNatural16bit        two ;
    coLinuxNatural64bit        three ;
    } ;

That works for GNUC but what if my compiler does not support it because
"long long is not standardized, insert:

#undef coLinuxNatural64bit
#define coLinuxNatural64bit    unsigned _int64

The structure definition stays the same without a bunch of #ifdefs.

Those longer names get tedious to type but they document the code well.  For
the procedure level or module level:

typedef coLinuxNatural8bit        NATURAL8
typedef coLinuxNatural16bit       NATURAL16
typedef coLinuxNatural32bit       NATURAL32
typedef coLinuxNatural64bit       NATURAL64

NATURAL64    function( NATURAL32 NUMBER )
    {
    NATURAL16    blah, blah, blah ;
..

The typedef dereferences the macro and allows the compilers to easily
cooperate between types or warn otherwise.

Jonathan