On Fri, 16 Feb 2024, Segher Boessenkool wrote: > > Conversely no heuristics is required to unwind VAX frames, because they > > are fixed in layout by hardware, fully self-described, and with the > > hardware frame pointer always available. > > The downside of the VAX situation of course is that the compiler has no > freedom to optimise the frame and *logue code at all, let alone well. > This may not matter so much on narrow ucoded in-order machines, there > are different balances there :-)
There is no function prologue to optimise in the VAX case, because all the frame setup has already been made by the CALLS instruction itself in the caller. The first machine instruction of the callee is technically already past the "prologue". And then RET serves as the whole function "epilogue". A discussion happened at the VAX/NetBSD mailing list as to a change to the calling convention to make it more RISC-like and replace the procedure call (CALLS and CALLG; the latter unused in our psABI) and return (RET) instructions with the subroutine branch (BSB), jump (JSB) and return (RSB) instructions, which are similar in semantics to say x86 CALL (for BSB/JSB) and RET (for RSB) instructions. Should that happen we'd have fine-grained control over the function prologues and epilogues. It's not clear however what the consequences such a change would have on performance, and it would surely increase code size. And the final VAX microarchitecture implementations (NVAX/NVAX+, dating back to 1991) have provisions in hardware, unsurprisingly, for optimising the execution speed of the CALL* and RET instructions. Maciej
