Re: ReiserFS reading performance patch

[Bean]

2012/4/28 Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden>:
> On 27.04.2012 20:36, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> On 27.04.2012 16:05, Albert Zeyer wrote:
>>> * Write a simplified compile.py script.
>> We don't have any compile.py.
>>> * Remove nested functions. They don't work on Mac because of stack
>>> execution protection.
>> It can be disabled. It's Apple fault for not allowing to disable it
>> selectively. Replacing nested functions is possible if done properly but
>> the "let's make it all static" is wrong and will create problems with
>> recursion, i.a. with nested partitions.
> And actually nested functions don't matter. What does are trampolines
> and they are only emitted it nested functions access local variables of
> parent and not inlined.

Hi,

I think mac is not alone, netbsd uses non-executable stack and heap as
well. Anyway, lower system security just to run an application does
seem a little undesirable.

I once wrote a small framework to get rid of the nasty trampolines, for example:

#define DEFINE_CLOSURE struct __closure_struct {
#define DEFINE_CLOSURE_END } __closure_data;
#define CLOSURE_TYPE void *__closure
#define CLOSURE __closure
#define CLOSURE_DATA &__closure_data
#define USE_CLOSURE struct __closure_struct *__closure_p = __closure;
#define UNUSED_CLOSURE (void) __closure;
#define _C(a) __closure_p-> a
#define _D(a) __closure_data. a

typedef int (*callback)(int a, int b, int c, int d, CLOSURE_TYPE);

int func1(callback cb, CLOSURE_TYPE)
{
  return cb(1, 2, 3, 4, CLOSURE) + 1;
}

int func2(int _p1)
{
DEFINE_CLOSURE
  int p1;
  int p2;
DEFINE_CLOSURE_END

  auto int cb(int a, int b, int c, int d, CLOSURE_TYPE);

  int cb(int a, int b, int c, int d, CLOSURE_TYPE)
  {
    USE_CLOSURE
    return _C(p1) + _C(p2) + a + b + c + d;
  }

  _D(p1) = _p1;
  _D(p2) = 1;
  return func1(cb, CLOSURE_DATA);
}

-- 
Best wishes
Bean