Copying generated functions

[Sandro Magi-2]

Ideally, a runtime system would avoid memory fragmentation, both
internal and external. I started a thread about predicting generated
code size awhile back in order to avoid memory fragmentation. Turns
out that isn't really feasible in a cross-platform manner, so what
about the converse: generating into a temporary buffer, then copying
to the final buffer once the size is known? The copy itself would be a
small fraction of the cost of code generation.

For instance, the initial buffer could be stack-allocated, then copied
to a malloc'd buffer. Cheap and easy. The only pitfalls I can think of
here, are absolute jumps within the buffer which are then invalidated
because of the reocation. Does Lightning generate such code?

Sandro


_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

[Alban Bedel]

On Tue, 26 Feb 2008 08:33:15 -0500
"Sandro Magi" <naasking@...> wrote:

> For instance, the initial buffer could be stack-allocated, then copied
> to a malloc'd buffer. Cheap and easy. The only pitfalls I can think of
> here, are absolute jumps within the buffer which are then invalidated
> because of the reocation. Does Lightning generate such code?

My asm knowledge is limited to i386, however I doubt that any sane cpu
design would miss relative jump. So I doubt that local jumps will ever
be a big problem. However function call might well be a problem.

In my compiler I use a malloced buffer that is reallocated when more
space is needed. For the local jumps I just store offset to the code
start instead of raw pointers. For functions call I simply rewrite
all the prepare/pusharg/call sequence at the very end. It sure would be
nicer if lightning just had a macro to patch the called address, but
that do the job.

        Albeu



_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning

[Sandro Magi-2]

On Sat, Mar 8, 2008 at 2:15 PM, Alban Bedel <albeu@...> wrote:

> On Tue, 26 Feb 2008 08:33:15 -0500
>  "Sandro Magi" <naasking@...> wrote:
>
>  > For instance, the initial buffer could be stack-allocated, then copied
>  > to a malloc'd buffer. Cheap and easy. The only pitfalls I can think of
>  > here, are absolute jumps within the buffer which are then invalidated
>  > because of the reocation. Does Lightning generate such code?
>
>  My asm knowledge is limited to i386, however I doubt that any sane cpu
>  design would miss relative jump. So I doubt that local jumps will ever
>  be a big problem.

I just wanted to make sure that Lightning only uses relative jumps
within a function.

> However function call might well be a problem.

Generating mutually recursive functions are the only real problem.
Some sort of forward declaration, followed by patching would be
needed.

>  In my compiler I use a malloced buffer that is reallocated when more
>  space is needed.

Not sufficient for code GC unless you are copying all existing code
into a new buffer.

Sandro


_______________________________________________
Lightning mailing list
Lightning@...
http://lists.gnu.org/mailman/listinfo/lightning