<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>