<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><div>NT/x86 is the slow one.</div><div>Still much faster than Modula-3.</div><div><br></div><div><br></div><div>There is a linked list through fs:0.</div><div>fs:0 is thread local.</div><div>For code speed, the link/unlink can be inlined.</div><div>For code size, it can be a small function call.</div><div>Just like two instructions for function enter and exit.</div><div>And set a local volatile "as scopes are crossed".</div><div><br></div><div><br></div><div>locals used in the except/finally</div><div>block are not likely enregistered across calls.</div><div><br></div><div><br></div><div>Compare this with current Modula-3:</div><div><br></div><div><br></div><div> pthread_getspecific (TlsGetValue) </div><div> to get the current head </div><div> link it in </div><div> setjmp </div><div><br></div><div> </div><div> And this happens for every TRY, instead of just<span style="font-size: 12pt; "> at most once per function.</span></div><div> </div><div><br></div><div>The fs:0 link/unlink is at most once per function.</div><div><br></div><div><br></div><div>And all the other NT platforms are faster.</div><div><br></div><div><br></div><div>They don't link/unlink anything.</div><div>They have metadata describing prologs.</div><div>The runtime can use that to restore nonvolatile registers (including</div><div>the stack) at any point.</div><div>The codegen is somewhat constrained -- to be describable,</div><div>but I suspect what you can describe encompasses anything</div><div>a compiler would want to do.</div><div>Leaf functions have no data, and can't change nonvolatile registers,</div><div>including rsp, and they can't make any calls (which would change rsp).</div><div><br></div><div><br></div><div>The tables are found from the return address.</div><div>The only dynamic data the runtime has to leave around</div><div>is the actual return address. No linked list, no volatile local</div><div>indicating position in the function.</div><div><br></div><div><br></div><div>fs:0 is the NT/x86 location.</div><div>This is a highly optimized thread local (fiber local actually).</div><div>I don't know what other ABIs use, if anything -- again, all the other</div><div>NT platforms have no linked list, just return addresses and metadata.</div><div><br></div><div><br></div><div><br></div><div>Notes:</div><div>The non-x86 approach is sometimes referred to as "no overhead", <span style="font-size: 12pt; ">as "TRY" doesn't do anything (except</span></div><div><span style="font-size: 12pt; ">leave cold data around).</span></div><div>X86 exception dispatch is faster than non-x86. The stack is faster to walk, through the fs:0 linked list.</div><div>The premise is that exception dispatch can be slow.</div><div>The non exceptional paths are what should be optimized.</div><div>And again, even NT/x86 is much more optimized than what Modula-3 does.</div><div><br></div><div><br></div><div><br></div><div> - Jay</div><br><br><br><br><div><hr id="stopSpelling">Date: Sun, 19 Jul 2015 12:06:20 +0200<br>From: estellnb@elstel.org<br>To: jay.krell@cornell.edu; m3devel@elegosoft.com<br>Subject: Re: [M3devel] frame per procedure instead of frame per TRY?<br><br>
<br>
<div class="ecxmoz-cite-prefix">Am 2015-07-19 um 11:38 schrieb Elmar
Stellnberger:<br>
</div>
<blockquote cite="mid:55AB7011.9070709@elstel.org">
<br>
<div class="ecxmoz-cite-prefix">Am 2015-07-19 um 11:10 schrieb Jay K:<br>
</div>
<blockquote cite="mid:COL130-W16911B6A22B3F1B2AB28E9E6860@phx.gbl">
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
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">
<blockquote cite="mid:COL130-W16911B6A22B3F1B2AB28E9E6860@phx.gbl">
<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></div> </div></body>
</html>