[M3devel] elimination of jmpbuf size from cm3 frontend?

[Elmar Stellnberger]

Am 2015-07-19 um 10:23 schrieb Jay K:
> alloca is very portable even if it is not in ANSI C or even Posix.
>
>
>  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.
>
>  clang/LLVM presumably provide it.
>  A lot of code depends on it and it is generally easy to provide.
>
> OpenVMS apparently calls it __ALLOCA.
>
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
memory area.

>
>
> 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 M3!!
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 ...


- Elmar

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/492899e3/attachment-0002.html>