[M3devel] frame per procedure instead of frame per TRY?
estellnb at elstel.org
Sun Jul 19 12:06:20 CEST 2015
Am 2015-07-19 um 11:38 schrieb Elmar Stellnberger:
> Am 2015-07-19 um 11:10 schrieb Jay K:
>> I'm pretty sure it can work, but you need also a local "dense"
>> volatile integer that describes where in the function you are. That
>> isn't free, but it is much cheaper than calling setjmp/PushFrame for
>> each try.
> Is it really that much faster? I can remember having implemented my
> own setjump/longjump in assembly some time ago and it should only save
> you one procedure call but generate some additional jumps. However I
> do not know how time costly the new-fashioned register value
> obfuscation is (registers are no more stored as they are but
> obfuscated for security reasons by glibc). Xor-ing by a simple value;
> does it really cost the world? I am not the one who can tell you
> whether such a venture like this would pay off ...
You are right. It would be somewhat faster especially on AMD64 where we
have a lot of registers to rescue ...
>> Try writing similar C++ for NT/x86 and look at what you get.
>> "PushFrame" is highly optimized to build a linked list through fs:0.
>> And even that is only done at most once per function.
> Through fs:0 ? It used to be on the ss:[e/r]b in former times.
> Since pthreading it may also be fs:0 under Linux because of
> I am not sure what these functions do in detail (something with fs at
> Nonetheless I would believe that avoiding to call get/setspecific
> could speed
> things up noticeably. First there is the function overhead, second we
> need to
> touch an independent memory area and last but not least the stack is
> always thread local. However I am not sure on how we could place the top
> anchor for the linked list of exception frames otherwise. Push an
> frame pointer into every local variable area?
However I believe this should also be worth a consideration as soon as
we talk about m3cg support and speed.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the M3devel