tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Dynamic code generation


From: David Mertens
Subject: Re: [Tinycc-devel] Dynamic code generation
Date: Sun, 18 Aug 2013 21:22:04 -0500

John -

This is *very* interesting. One thing that I have been dreaming about is the ability to have some major module partially compile code once and then allow the "user" to plug in miscellaneous expressions and finish the compilation. It sounds like your patch might allow this sort of functionality, or be the first step towards something like that. :-D

David


On Sun, Aug 18, 2013 at 2:56 PM, <address@hidden> wrote:
Hi.

Saw the post about perl bindings this morning; lots of code to just extract
function signatures (even in perl ;-)) when the required information
is at your fingertips. Recalled using Haskell (GHC) parser generator
for similar tasks although not in the context of using tcc.
A while back, I was playing with the dynamic code generation
facilities using the example code in libtcc_test.c and noticed
couple of additional missing pieces. Decided to spent some time
in cooking up something to address some of these issues; the result
is attached as a diff. Added some functions to retrieve information
about declared symbols, struct definitions, and values of
object-like macros. Please see libtcc.h and libtcc_test.c to get
an idea about how to use these. Added a new function:

    tcc_compile_string_partial(TCCState *s, char *src, int final)

This permits compilation from multiple source strings keeping the
stacks intact as long as 'final' is 0:

    tcc_compile_string_partial(s, prgm_source, 0)

Inspect symbols such as function declarations to get the return
and the parameter types (see libtcc.h and libtcc_test.c for
example). One probably will generate wrapper functions suitable
for the host language, and compile that as the final piece:

    tcc_compile_string_partial(s, wrapper_source, 1)

Then generate the code as usual.

It seems necessary to carry around the entire TCCState when
only the memory for the code is really of interest. tcc_delete()
deletes the memory provided by the user, kinda impolite thing
to do. If that memory is kept, then the user can decide when to
free it. It seems to work even with multiple states. The process
goes something like this:

    req_mem_size = tcc_relocate(s, NULL);
    /* allocate memory */
    ...
    tcc_relocate(s, memory);
    tcc_delete_ret_code*(s); /* code memory is still there */

[* new function, can't think of a better name at this moment :-(.]

We can use the code, and later free it when no longer needed.


Thanks,

John

P.S. the diff is against the code in the mob branch.


_______________________________________________
Tinycc-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/tinycc-devel



--
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]