[M3devel] elimination of jmpbuf size from cm3 frontend?

[Jay K]

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

 - Jay


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

    

  


_______________________________________________
M3devel mailing list
M3devel at elegosoft.com
https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/5e3deb52/attachment-0002.html>