If a char parameter is passed to a routine in Aarch64 is the top of the word undefined? and is the same true for if a char value is returned? I think the answer is yes but it would be good to be certain. This means if the char is used in some arithmetic the UXTB, or SXTB for signed, modifiers as described at A64 Shift and Extend Operations: Operand Modifiers must be used in an instruction using a register containing a char passed into or returned from a routine.
I presume the same is true for short as well so a signed short might for instance come in with the top two bytes containing zero
I think it would be a big mistake for ILP32 to require that subroutines assume that the top of the pointer parameters might be rubbish. I very much hope that is just an oversight. That will work fine for the integer types because of those modifiers but there's no such modifier for the base register in loads and stores. I know this would be different from how integer type are handled but pointers are very important.
It is a bit strange about the frame format for ilp32, I don't see that there is any real requirement for compatibility with lp64.
I wonder if the frame layout remains the same as LP64 to keep the stack pointer 16-byte aligned even with empty frames.
Ok, according to a reliable source, another (more significant) reason for the frame layout is that the frame pointer is callee-saved, so any non-leaf callee would have to preserve it in full anyway. (The link register is preserved in full to allow stp and ldp to be used when setting up the frame.)
There are also a few considerations regarding the unspecified-bits policy that I hadn't thought about. One of them is security; a C callee can't easily check that its inputs are valid for a small type because the C compiler would optimise away the checks. Another consideration is how stacked arguments would be handled; in this case, the unspecified-bits approach is slightly nicer because the caller doesn't have to do much to prepare the value (just str w0, [...]) and the callee can just load it as a W register.
Security. Gah you're right.And that would apply to passing over pointers in ilp32 mode as well. I suppose one could have an optimization option, and if a hacker can generate a wrong address they've pretty much got control anyway. I can see the point in the default being to make no assumptions though, I keep on being surprised by the exploits that are found and used..