<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">Am 2015-07-19 um 11:38 schrieb Elmar
Stellnberger:<br>
</div>
<blockquote cite="mid:55AB7011.9070709@elstel.org" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<br>
<div class="moz-cite-prefix">Am 2015-07-19 um 11:10 schrieb Jay K:<br>
</div>
<blockquote cite="mid:COL130-W16911B6A22B3F1B2AB28E9E6860@phx.gbl"
type="cite">
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style>
<div dir="ltr">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.
<div><br>
</div>
</div>
</blockquote>
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
...<br>
<br>
<br>
</blockquote>
<br>
You are right. It would be somewhat faster especially on AMD64 where
we have a lot of registers to rescue ...<br>
<br>
<br>
<blockquote cite="mid:55AB7011.9070709@elstel.org" type="cite">
<blockquote cite="mid:COL130-W16911B6A22B3F1B2AB28E9E6860@phx.gbl"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Try writing similar C++ for NT/x86 and look at what you
get.</div>
<div>"PushFrame" is highly optimized to build a linked list
through fs:0.</div>
<div>And even that is only done at most once per function.</div>
</div>
</blockquote>
<br>
Through fs:0 ? It used to be on the ss:[e/r]b in former times.<br>
Since pthreading it may also be fs:0 under Linux because of
get/setspecific.<br>
I am not sure what these functions do in detail (something with fs
at last).<br>
<br>
Nonetheless I would believe that avoiding to call get/setspecific
could speed<br>
things up noticeably. First there is the function overhead, second
we need to<br>
touch an independent memory area and last but not least the stack
is <br>
always thread local. However I am not sure on how we could place
the top<br>
anchor for the linked list of exception frames otherwise. Push an
exception<br>
frame pointer into every local variable area?<br>
</blockquote>
<br>
However I believe this should also be worth a consideration as soon
as we talk about m3cg support and speed.<br>
<br>
<br>
</body>
</html>