Most of them are already aligned to their natural boundaries, so lowering
the alignment to 1 byte can only worsen things by making the C compiler
generate poorer (unaligned access) code for some platforms.
The layout of structures is not specified by the C Standard, but is rather
given by a particular platform + toolchain's ABI (application binary interface).
Most ABIs follow the expected pattern "alignment of scalars is their size,
alignment of arrays is that of its element type, alignment of structs is the
maximum alignment of its members". A couple of links to particular ABIs are
given in build.h.
Problems are expected with archs that care about unaligned access when a pointer
to a non-packed struct is taken that resides in a packed aggregate, but these
uses should be weeded out (I'm not sure if there are any in our codebase).
The following types are affected, only hitdata_t changes its size:
sectortype, walltype, spritetype, spriteext_t, spritesmooth_t,
struct validmode_t, picanm_t, palette_t, vec2_t, vec3_t, hitdata_t.
git-svn-id: https://svn.eduke32.com/eduke32@3455 1a8010ca-5511-0410-912e-c29ae57300e0
Pass types via ffi.typeof() instead of declaring them in the
global namespace when possible.
git-svn-id: https://svn.eduke32.com/eduke32@3437 1a8010ca-5511-0410-912e-c29ae57300e0
- more predefined vars
- fix recursive states and ones with a stray "else" before the end
git-svn-id: https://svn.eduke32.com/eduke32@3409 1a8010ca-5511-0410-912e-c29ae57300e0
- more codegen
- make more members const, some char unsigned
- fix some "geom" metamethods
- '^' operator
git-svn-id: https://svn.eduke32.com/eduke32@3253 1a8010ca-5511-0410-912e-c29ae57300e0
Going to extremes to avoid code duplication like the plague, but at
least it's great to learn about the whole function environment business.
git-svn-id: https://svn.eduke32.com/eduke32@3060 1a8010ca-5511-0410-912e-c29ae57300e0
