Here's a link to the final C89 draft spec (the ratified spec is paywalled):
https://www.open-std.org/JTC1/sc22/wg14/www/docs/n1256.pdf
From section 6.7.2.1, semantics #10:
> The alignment of the addressable storage unit is unspecified.
This is for struct field access, but it clearly implies the compiler can choose to use unaligned struct fields. Also, the size of the integer types are all implementation defined:
then #12:
> Each non-bit-field member of a structure or union object is aligned in an implementation- defined manner appropriate to its type.
Alignment is defined as:
> requirement that objects of a particular type be located on storage boundaries with addresses that are particular multiples of a byte address
It doesn't say which multiple. 1 is a multiple. (So is 0.5, just in case the complier wants to go nuts with arcane code gen.) The spec even allows chars to be 7 bits. I didn't bother looking up the definition of byte in the spec for those architectures. (7 bits? 8 bits?)
In section 6.2.5, they talk about implementation-defined restrictions on integer types + alignment requirements:
> For each of the signed integer types, there is a corresponding (but different) unsigned integer type (designated with the keyword unsigned) that uses the same amount of storage (including sign information) and has the same alignment requirements.
So, the alignment of integers has to be the same for signed + unsigned types. That still doesn't say byte-aligned integers are disallowed.
Later:
> An integer may be converted to any pointer type. Except as previously specified, the result is implementation-defined, might not be correctly aligned,
Again, the alignment behavior is clearly implementation-defined.
I can't find a definition of implementation in the spec, but it clearly includes the compiler, standard library, and operating system. There is this quote:
> For implementations with a signed zero (including all IEC60559 implementations)
which, according to the IEC60559 abstract "An implementation of a floating-point system conforming to this standard may be realized entirely in software, entirely in hardware, or in any combination of software and hardware." I doubt they were trying to constrain floating point to be done in software by compilers, so it's pretty clear they intended to incorporate the physical hardware in the definition of the "implementation".
Later, they say:
> ...is defined if and only if the implementation supports the floating-point exception
which was definitely in the realm of hardware support back in 1989. Some later sections says that some macros (such as for FMA) are defined iff the implementation implements the primitive in hardware, and not just software.