[M3devel] frame per procedure instead of frame per TRY?

[Elmar Stellnberger]

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 
> get/setspecific.
> I am not sure what these functions do in detail (something with fs at 
> last).
>
> 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 
> exception
>  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...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/ed02d46b/attachment-0002.html>