I kinda think I have a good abi ,

Let’s call it mjc,

I sometimes go into ghidra to see my assembly,

I’m kinda tired of the call and ret instructions, they feel limited, and from the past ,

Why not be like arm ,

There are special registers:

1.Stack pointers( base ptr and stack ptr) 2.Program counter 3.Virtual extended register set pointer ( I am not certain on its usefulness, it is not necessary for the abi to function , although kinda neet) 4. Normal Return address 5. Catching return address (not used in noexcept functions)

A function has :

In registers 1.

Out registers 1.

Inout registers 1.

Used registers

1,2, and 3 are determined by the function signature, and for any given function pointer type are the same.

4, on the orher Hand is: A set of all registers for a dynamic call ( through a function pointer) Or A set of registers used in the function that might be modified when returning from the Calle

This set grows linearly until the registers load is too high , then for these registers , the caller stores them to stack and pops back after return from Calle, this makes sure there is minimal stack usage,

( because the register assigner is used after the main optimization passes and in the linker, any recursive graph can be known to store the registers in stack)

However because dynamic/external calls don’t have the luxury of known assembly, so , every register might be used , so , the intermediate registers need storing before the dynamic call and re storing afterwards, just like how the call and ret instructions work via stack push and jumps, or how the c++ async resume and suspend is defined via jumps, This is just more explicit, because we have no control over what call instruction saves but we do for ret.

There are also 2 return paths , Instead of a branch after a call like most std::expected, we do an optimization, not valid in C, that isn’t try catch with cold paths , but , The caller happy paths have no need for a branch because a throw will return to the catch path in the caller from the catch register address, this is also very fast , like a single return statement, and the only cost Is that a register is occupied , not bad compared to throw , or even the if statement in my opinion

this is also possible because of the radical exception handling mechanism , Basically I don’t need to tell about all of it , but every function has any catch statements or raii clean up codes in the catch path , this doesn’t need any extra unwinder, because there is no data structure for the unwinder, it’s just code , and the return is directly to the unwind code instead of calling many cxx throw functions and using thread local or dynamic storage

The extended registers may be unnecessary, Im still contemplating if it’s good or not , but basically it’s a very fast preallocated stack region with a known size and big alignment, used like a stack but without much overhead of stack pointer minipulation.

Note that this abi is fully abstractable under itanium , basically, only the outer functions needs itanum for compatibility, At most the catching return points to a cxx throw for compatibility.

Note that , as far as I know, the call and ret instructions already store much unnecessary registers in the stack, so I dont think the dynamic overhead is much different from a normal dynamic call , Also , I believe that allowing the return , arguments and more be able to expand , be even simd registers is far more beneficial than a restricted set of registers as function arguments and a single return registers, let alone the catch register

There might also be optimizations:

F:
Init:...
Code:...
If ... jump to happy
(Throw code ...)
Move  catch ret register to normal ret .
( this will make the return at the end a throwing return)
Happy:
....
Clean:
....

End and ret:....

Ret to normal ret

Instead of duplicated cleanup code in happy and sad paths in the c++ throw conversions, or returning to an unnecessary brach that is known to be happy or sad in the Calle.

There are other considerations, but this is the gist.

Note that for a given function pointer type with mjc convention, there’s no limit on dll linking

Edit: Does anyone have an opinion or improvements or impressions?

I am not saying to do this, no one wants to make a new build system and language abi