Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Idea: Low-register calling convention #231

Open
lukego opened this issue Feb 11, 2019 · 3 comments
Open

Idea: Low-register calling convention #231

lukego opened this issue Feb 11, 2019 · 3 comments

Comments

@lukego
Copy link
Contributor

lukego commented Feb 11, 2019

Capturing an idea from @corsix to solve the register part of the default FFI calling convention being too heavyweight in some situations (#230):

Suppose we could declare that certain functions preserve the value of all CPU registers except for their arguments and return value. For example, an FFI function prototype could be declared as

__lowreg int foo(int x, int y, double z)

and the compiler would know that this function (likely written in assembler) will preserve the values of all registers except for rsi (x), rdi (y), xmm0 (z), and rax (return value.) This would make the function more efficient to call because the JIT would not need to bother saving and restoring the values of all the other registers that are caller-save in the standard platform calling convention.

@fsfod
Copy link

fsfod commented Feb 11, 2019

This is very similar to one of the features i added intrinsic system as well creating an intrinsic from a blob of memory you can instead specify an arbitrary address to call with the same system of listing input\output\modified registers.

@lukego
Copy link
Contributor Author

lukego commented Feb 12, 2019

@fsfod Generally I am wondering whether a custom calling convention can serve as an "80/20" solution for intrinsics. That is, to support most of the use cases for full-scale intrinsics but with a fraction of the implementation complexity. What do you think?

(I floated this idea on the LuaJIT repo some years back but didn't get a bite on discussion LuaJIT/LuaJIT#39 (comment).)

@lukego
Copy link
Contributor Author

lukego commented Feb 12, 2019

... Sorry, there actually was a longer discussion over at the LuaJIT repo, which I will now reread... LuaJIT/LuaJIT#100

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants