flexspin compiler for P2: Assembly, Spin, BASIC, and C in one compiler

1646566676870»

Comments

  • There's two (or really 3) things about structure packing/padding.
    By default, members are aligned based on their size, so 64bit values are 8 byte aligned, 32bit values are 4 byte aligned, and so on. Padding is introduced only to achieve proper alignment of members.
    For the end of the structure, it will be padded out based on the largest sized member. This is done so that an array of the struct will have consistent alignment.
    If packing is enabled, then no padding is introduced anywhere.

    I'm not aware of any compilers that have a type smaller than a byte. Bitfields are a special case, but in reality they are stored in a type that is at least a byte, and packing won't reduce unused bits in the bitfield. Padding/packing still applies to the types used for the bitfield.
    struct foo
    {
      int x : 1;
    };
    
    This still takes up the space of an int.
    struct bar
    {
      int x : 1;
      int y : 1;
    };
    
    This still takes up the space of an int (just one).
    struct foobar
    {
      int x : 1;
      char y : 1;
    };
    
    This takes up the space of an int PLUS a char, because changing the type of a bitfield starts a new one.
    Note this would also likely be padded out at the end of the struct to a multiple of size int (i.e. 3 bytes in this case).
  • Roy Eltham wrote: »
    There's two (or really 3) things about structure packing/padding.
    By default, members are aligned based on their size, so 64bit values are 8 byte aligned, 32bit values are 4 byte aligned, and so on. Padding is introduced only to achieve proper alignment of members.

    Actually not quite true. For example, when compiling for 32bit x86 Linux, unit64_t is 4 byte aligned. Yes, for very stupid reasons, this not just depends on CPU architecture, but also on operating system.
  • Yeah, there are exceptions, especially for 64bit crap where people made bad choices to ease transition or for compatibility.

  • So not particularly defined in the standard then.
  • Roy Eltham wrote: »
    Yeah, there are exceptions, especially for 64bit crap where people made bad choices to ease transition or for compatibility.
    I assume the ABIs for that were decided before x64 even was a thing... What is uttely craptastic is the inconsistent size of the long type. Technically, this affects all integer types, but almost all (angry look at cc65) compilers have settled on char/short/int being 8/16/32 bit. long is sometimes 32, sometimes 64, who knows?
    ...
    Which is why IMO the only integer types one should use are int (because it is somewhat ingrained in some parts of the language. Just try not to depend on it being more than 16 bit too often.) and the non-ludicrous types from stdint.h, ideally typedef'd to less verbose names (and of course char when you're actually dealing with characters)

    For propeller-related code, I generally use these (the "vm" prefix being an artifact of where it was copy-pasted from that kinda stuck):
    typedef uint32_t vmlong;
    typedef int32_t vmlong_s;
    typedef uint16_t vmword;
    typedef int16_t vmword_s;
    typedef uint8_t vmbyte;
    typedef int8_t vmbyte_s;
    typedef unsigned int uint;
    
Sign In or Register to comment.