Hi,
azblue wrote:
Combuster wrote:
Considering you seem to be using 64-bit code, you can even consider using the red zone - as long as it's not part of the kernel.
I jut learned about the red zone from this thread (and the other one linked), but I don't understand why it needs to be confined exclusively to long mode; shouldn't it also work in ring 3 protected mode leaf functions? If they're not calling other functions, and an interrupt will switch to another stack, I don't see why long mode is required (or why the red zone would be limited to 128 bytes).
The first thing to understand is that for instructions like "mov rax,[rsp+(-123)]" there's 3 alternatives:
- encode the offset (-123) as a sign extended 8-bit immediate
- encode the offset (-123) as a sign extended 16-bit immediate and waste 2 extra bytes (one for the extra immediate byte and another for the size override prefix you'd need)
- encode the offset (-123) as a sign extended 32-bit immediate and waste 3 extra bytes
The point of the red zone is to make code more efficient by avoiding the need to adjust RSP (e.g. doing "sub rsp,256" to make space, which causes a dependency problem for later instructions that use RSP because they have to wait until the new value of RSP has been calculated); while also increasing the chance that those (shorter, better) "sign extended 8-bit immediate" instructions can be used.
It's this "(shorter, better) sign extended 8-bit immediate" that's responsible for the 128 byte size limit. If the red zone was larger, you'd have to use something less efficient (16-bit or 32-bit immediate), and it'd probably better to adjust RSP instead.
Now, calling conventions...
There is no reason the same red zone stuff couldn't be done for 32-bit code (or 16-bit code). In fact, if you're willing to write your own compiler and ensure that all your shared libraries, kernel API, etc. is designed for it; nothing prevents you from implementing any calling convention you like. The problem here is that it'd break compatibility with the calling conventions that everything has used for about 25 years.
Also note that you only need a strictly defined calling convention for cases where the tools can't optimise the calling convention properly (e.g. because the called function is in a completely different object file, or in a shared library or something). For better tools (e.g. where native code generation is done by a link-time optimiser, and where the calling conventions used by most functions can be optimised properly) the "strictly defined calling convention" wouldn't be used anywhere near as much, and would have far less performance impact. Basically; if you're going to replace standard tools just to improve that strictly defined calling convention; then you're probably solving the wrong problem in the first place.
Cheers,
Brendan