Thank you
Petr Kobalicek
Best regards
Petr Kobalicek
you might also want to try rev. #338, I disabled stack adjusting when
calling simple function (no stack arguments).
Best regards
Petr Kobalicek
On Thu, Mar 17, 2011 at 8:46 PM, Petr Kobalíček
I'd like to solve the red-zone issue first. I though that it is
correctly implemented, but now I'm not sure, please can you write me
the asm of correctly implemented function?
I'm sure I broke it yesterday
The other issue (unnecessary spill) can be workarounded by using new
variable. AsmJit knows the scope of each variable and there is
currently no mechanism how to tell it that the variable will be
rewritten, I'd like to fix this, but I don't know how (it must be fast
and not complicated).
Best regards
Petr Kobalicek
Best regards
Petr Kobalicek
I read the Unix 64-bit ABI (including the calling convention) and you
are right. Please verify my understanding:
- Leaf function is function that doesn't call other function
- Red-zone means 128 bytes
- Leaf function can use only 128 bytes of stack mem
- If I need more memory, I need to adjust rsp in prolog/epilog.
Correct?
Best regards
Petr Kobalicek
I need to adjust esp/rsp always in function calling convention is
unix-amd64 and stack size is larger than 128:
This should solve the issue:
if (_functionPrototype.getCallingConvention() == CALL_CONV_X64U &&
cc._memBytesTotal >= 128)
_isEspAdjusted = true;
Please try the latest rev, it should fix the red-zone issue.
Best regards
Petr Kobalicek
> Remaining redzone issues:
> * x86_32 and win64 don't have a redzone at all. On those systems, you
> simply can't safely access negative offsets of esp/rsp. I don't have a
> win64 system to test, but AsmJit does try to use redzone on x86_32.
Where is mentioned that I can't use stack below esp/rsp under windows?
I studied these calling conventions, but didn't notice something about
discarding stack. I understand the red-zone concept, but I thought
that it is possible to access bytes up to 4096+- (page size) bytes
under windows/linux.
But I'm going to fix it, no problemo :)
Best regards
Petr Kobalicek
On Fri, Mar 18, 2011 at 12:33 PM, Petr Kobalíček
Thank you!
Petr Kobalicek
try rev #345, I added better strenght to unuseVar() and now it is able
to prevent unnecessary spill. However, its experimental:)
Best regards
Petr Kobalicek
I think that this is possible with a little modification, I'm going to try it.
Best regards
Petr Kobalicek
I'm now thinking how to improve the register allocator. It's still not
smart in some cases, but I think that last 2 days there was an
improvement:)
please try rev #356, there was mistake in condition, now it should work
Best regards
Petr Kobalicek
I will look at the second issue when I get some spare time. The first
issue is harder, because the value is at the scope. You can try the
hints in cases where you want to unuse/spill variable.
For example this should work, but I didn't test it:)
c.newFunction(CALL_CONV_DEFAULT, FunctionBuilder1<int,int>());
c.getFunction()->setHint(FUNCTION_HINT_NAKED, true);
Label L0 = c.newLabel();
Label L1 = c.newLabel();
GPVar x(c.newGP());
c.jnz(L0);
c.unuse(x);
ECall *ctx = c.call((void*)callee);
ctx->setPrototype(CALL_CONV_DEFAULT, FunctionBuilder1<int,int>());
ctx->setArgument(0, c.argGP(0));
ctx->setReturn(x);
c.jmp(L1);
c.bind(L0);
c.mov(x, c.argGP(0));
c.bind(L1);
c.ret(x);
c.endFunction();
Best regards
Petr Kobalicek