Yes, except that the shuffle is here used to sign-extend a variable which is already sign-extended to begin with, so all the register-rearrangement is superfluous to begin with.
Actually, if you follow ANSI C and would pass struct Point as a parameter, then it does require the compiler to pass this argument as a copy. I'm not sure what SAS/C does with that in this case, but it is not unreasonable to assume that it would simply copy it on the stack, too. In that case, the two options are pretty much equivalent: Whether the two members of the struct are on the stack because the compiler pushes them there as a single 32-bit longword due to the stack-based ABI, or whether it is on the stack because the compiler copied them there does not matter much. You probably cannot enforce the order on which they appear on the stack with Greenhill.
The problem with Intuition and its relationship with the Green Hills compiler is that Intuition depends upon the 'struct Point' to be passed as a scalar value.
I spent considerable time porting Intuition to use SAS/C, so that it could be built natively on an Amiga, and that's when I found how "fast and loose" Intuition plays with function parameter passing.
Given the quality of the code in general, I reckon it is not an accident or oversight how the K&R function and the call-back routines used in the state machine of Intuition treat their parameters. These must have been deliberate design choices.
Anyhow, I wonder what actually depends on this.
If I remember correctly (it's been a while), most of the operations which involve planar geometry (is this point within this area? do these areas overlap? scale this area to this size) use the packed 'struct Point', and Intuition uses these both in function parameters and in BOOPSI messages.
It's not as if these were the foundations upon which Intuition rests, but the use of this type of data structure is so pervasive that fixing up the code to make it less compiler implementation dependant will quickly get on your nerves.
One thing that depends unfortunately on the stack-based ABI (but I don't remember whether it depends on struct Point) was Boopsis, which for that reason felt like an alien to the system, too (besides the other obvious one).
I suppose this is true for every case of SmallTalk methods and practice transplanted to a different system (Objective-C comes to mind)
The boopsi callbacks received parameters on the stack, unlike everything else where one would have probably used registerized parameters or a struct Hook * to call into the user functions.
That's the SmallTalk legacy. It could have been worse: imagine that these were TagItem lists, and how slow the parameter processing would have been.