Re: [Lightning] Memory Allocation on Mac OS X

[Paulo César Pereira de Andrade]

Em 28 de setembro de 2010 14:52, Paulo César Pereira de Andrade
<address@hidden> escreveu:
> Em 28 de setembro de 2010 03:49, Paolo Bonzini <address@hidden> escreveu:
>> On 09/28/2010 06:52 AM, Paulo César Pereira de Andrade wrote:

  Hi,

[...]
>>> the stack adjustment due to building a large frame, it will patch the
>>> adjustment
>>> of the wrong function, same if it calls jit_allocai to have some %ebp
>>> relative
>>> buffer, like is done for x87/sse conversion (but this one is mostly for
>>> testing,
>>> maybe should always allocate the first 8 stack bytes for it, or just
>>> push/pop
>>> always).
>>
>> Yes, these are the problems I was hinting at.  The root idea is that
>> lightning _is_ an assembler, so it is hard to define what the user can and
>> cannot do.  The instances of "undefined behavior" should be very limited,
>> and JIT compilers can use many tricks that lightning should support.

  I added a new jit_push_pop_p() predicate to handle this. But I preferred
to have it off by default. Because code that jumps from function to function
should be very uncommon.
  It should also be noted that in either mode, offsets from jit_allocai() are
only valid from the last jit_prolog(), so, at least this never changed, and
one must know exactly what is doing if using them, probably call
jit_allocai() on all jit functions, and with same parameters, just after
jit_prolog(), if wants offset to work on any function, and jump from
function to function; that is, from code with different jit_prolog calls.

  The interface for "flags" is still not very well defined, and usually should
be done in program scope [1], but the way to change should be:

jit_flags.rnd_near = 1|0;
jit_flags.push_pop = 1|0;

or use the macro to read those, what is kind weird :-)

jit_round_to_nearest_p() = 1|0;
jit_push_pop_p() = 1|0;

  There are only two options so far. The cpu flags in jit_cpu usually
should not be used, but one can for example write:

jit_cpu.sse2 = 0;

to force use of x87, or, for testing purposes, usually just read assembly
dump, to generate code for unsupported features. Currently there is
only minimal sse4.1 untested code for in sse_floor_x_y and sse_ceil_x_y,
in fp-sse.h.

[1] flags are in a separate global bitfield because they both, do not polute
the cpu features global, and because they could be per function.

Thanks,
Paulo