We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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
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..