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