<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>Merely subtracting the stack pointer isn't correct on all systems.</div><div>At least on NT, stack pages must be touched in order without skipping any,</div><div>for stack overflow exceptions to work correctly.</div><div>There is a high water mark, so it isn't necessarily linear.</div><div><br></div><div><br></div><div><br></div><div>The array is local.</div><div>The reason for an array is that each instance of a TRY currently</div><div>uses its own jmpbuf.</div><div><br></div><div><br></div><div>So a function with n TRY's wants an array of n jmpbufs.</div><div><br></div><div><br></div><div>The elements are then indeed linked/unlinked by PushFrame/PopFrame,</div><div>which are incredibly unoptimized, vs. for example native NT C or C++</div><div>exception handling, and presumably other systems.</div><div><br></div><div><br></div><div>*Ideally* we'd have just one jmpbuf per function, at most, and</div><div>a local "scope id" to differentiate where in the function we are,</div><div>for finally/except to dispatch on.</div><div>You can think of it is a line number, but there can be multiple per line,</div><div>and they can be denser/smaller than line numbers.</div><div><br></div><div><br></div><div><br></div><div>NEWA: alloca is considered kind of dangerous, in that failure</div><div>is difficult to recognize, or not portably recognizable and handlable.</div><div><br></div><div><br></div><div>However, that is the same as merely deep function calls.</div><div><br></div><div><br></div><div>So maybe.</div><div>And we could smush the portability problem into our runtime.</div><div>In particular, we could catch the exception on NT, fix up the</div><div>page (_resetstkovflw) and call calloc/malloc instead.</div><div><br></div><div><br></div><div>I don't know how to handle the situation on other systems though.</div><div><br></div><div><br></div><div>My current proposal doesn't use an array, but the most portable</div><div>proposal would.</div><div><br></div><div><br></div><div>If people can do the work/research/testing for recognizing stack exhaustion</div><div>on a decent set of systems -- Linux, Solaris, FreeBSD, OpenBSD, NetBSD, NT,</div><div>possibly AIX, OpenVMS, Irix, HP-UX -- then this would grain traction in my mind.</div><div><br></div><div><br></div><div>But yes, safety and garbage collection are not free.</div><div>If you want the best possible performance, use C or C++.</div><div><br></div><div><br></div><div> - Jay</div><br><br><br><div><hr id="stopSpelling">Date: Sun, 19 Jul 2015 10:44:15 +0200<br>From: estellnb@elstel.org<br>To: jay.krell@cornell.edu; hendrik@topoi.pooq.com; m3devel@elegosoft.com<br>Subject: Re: [M3devel] elimination of jmpbuf size from cm3 frontend?<br><br>
<br>
<div class="ecxmoz-cite-prefix">Am 2015-07-19 um 10:23 schrieb Jay K:<br>
</div>
<blockquote cite="mid:COL130-W395EC5C192FDA371DC5C78E6860@phx.gbl">
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr">
<div>alloca is very portable even if it is not in ANSI C or even
Posix.</div>
<div><br>
</div>
<div><br>
</div>
<div> gcc has builtin support for it.</div>
<div><span style="font-size:12pt;"> Win32 provides it, where
it is called _alloca.</span></div>
<div><span style="font-size:12pt;">The NT/amd64 ABI
specifically accounts for it -- functions that call</span></div>
<div><span style="font-size:12pt;">alloca must have a fixed
"frame pointer" in a register other than rsp,</span></div>
<div><span style="font-size:12pt;">so that rsp can be changed
by calling alloca.</span></div>
<div><span style="font-size:12pt;"><br>
</span></div>
<div><span style="font-size:12pt;"> clang/LLVM presumably
provide it.</span></div>
<div><span style="font-size:12pt;"> A lot of code depends on
it and it is generally easy to provide.</span></div>
<div><span style="font-size:12pt;"><br>
</span></div>
<div><span style="font-size:12pt;">OpenVMS apparently calls it
__ALLOCA.</span></div>
<div><br>
</div>
</div>
</blockquote>
Basically if you plan to build jumpbuf support into m3cg you could<br>
easily use a few assembly statements as well in order to achieve <br>
what alloca does (independently from the operating system):<br>
<br>
mov %[e/r]sp, PTR VAR<br>
sub %[e/r]sp, JUMPBUF_SIZE <br>
<br>
I am sure that similar workarounds would exist for any arch other<br>
than x86 and AMD64.<br>
<br>
<br>
<blockquote cite="mid:COL130-W395EC5C192FDA371DC5C78E6860@phx.gbl">
<div dir="ltr">
<div><br>
</div>
<div>For more complete portability to the C backend we could</div>
<div>add an m3cg operation to allocate an array of jmpbufs</div>
<div>with a constant count.</div>
</div>
</blockquote>
Why allocate an array or external buffer of jump bufs?<br>
We used to have a linked list interleaved on the stack.<br>
This is fully sufficient and faster than an independent <br>
memory area.<br>
<br>
<blockquote cite="mid:COL130-W395EC5C192FDA371DC5C78E6860@phx.gbl">
<div dir="ltr">
<div><br>
</div>
<div><br>
</div>
<div>It is certainly more portable than C99, and C99 VLAs are
kind of more general than I need.</div>
<div>That is, I might pass a "variable" to alloca, but it is
kind of a constant.</div>
</div>
</blockquote>
<br>
If we have arrived at using something similar as alloca in m3cg why
shouldn`t we provide<br>
this functionality to the user? i.e. let programmers call such a
function from high level M3 <br>
code in order to alloc variable length bufffers, arrays, etc.<br>
<br>
VAR localvar := NEWA(MyType);<br>
<br>
This is a functionality which I believe that is really missing in
M3!!<br>
When we implemented the algorithm of Strassen (saving some
multiplications for matrix<br>
mults.) we had to notice that everything goes much slower just
because of the need for<br>
garbage collection ...<br>
<br>
<br>
- Elmar<br>
<br>
<br>_______________________________________________
M3devel mailing list
M3devel@elegosoft.com
https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel</div> </div></body>
</html>