What you want to do is reasonable, and I am doing exactly that in MELT (a high level domain specific language to extend GCC; MELT is compiled to C, thru a translator itself written in MELT).<\/p>\n
First, when generating C code (or many other source languages), a good advice is to keep some sort of abstract syntax tree (AST) in memory. So build first the entire AST of the generated C code, then emit it as C syntax. Don’t think of your code generation framework without an explicit AST (in other words, generation of C code with a bunch of printf is a maintenance nightmare, you want to have some intermediate representation).<\/p>\n
Second, the main reason to generate C code is to take advantage of a good optimizing compiler (another reason is the portability and ubiquity of C). If you don’t care about performance of the generated code (and TCC compiles very quickly C into a very naive and slow machine code) you could use some other approaches, e.g. using some JIT libraries like Gnu lightning (very quick generation of slow machine code), Gnu Libjit (generated machine code is a bit better), LLVM (good machine code generated, but generation time comparable to a compiler).<\/p>\n
So if you generate C code and want it to run quickly, the compilation time of the C code is not negligible (since you probably would fork a Once you emitted your C code, forked its compilation into a You coul use many other different approaches, e.g. have a bytecode interpreter and generate for that bytecode, use Common Lisp (e.g. SBCL on Linux which compiles dynamically to machine code), LuaJit, Java, MetaOcaml etc.<\/p>\n As others suggested, you don’t care much about the time to write a C file, and it will stay in filesystem cache in practice. And writing it is much faster than compiling it, so staying in memory is not worth the trouble. Use some tmpfs<\/em> if you are concerned by I\/O times.<\/p>\n You asked<\/p>\n Can a library Of course yes: you should fork a command to build the library from the generated C code (e.g. a Your base application program should have defined a convention about the set of dlsym-ed names (usually functions) and how they are called. It should only directly call functions in your You don’t<\/strong> want your You probably won’t bother to P.S. the MELT translator is currently 57KLOC of MELT code translated to nearly 1770KLOC of C code.<\/p>\n","protected":false},"excerpt":{"rendered":" What you want to do is reasonable, and I am doing exactly that in MELT (a high level domain specific language to extend GCC; MELT is compiled to C, thru a translator itself written in MELT). First, when generating C code (or many other source languages), a good advice is to keep some sort of […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-4705","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/4705","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/comments?post=4705"}],"version-history":[{"count":0,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/4705\/revisions"}],"wp:attachment":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/media?parent=4705"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/categories?post=4705"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/tags?post=4705"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}gcc -O -fPIC -shared<\/code> command to make some shared object foo.so<\/code> out of your generated foo.c<\/code>). By experience, generating C code takes much less time than compiling it (with gcc -O<\/code>). In MELT, the generation of C code is more than 10x faster than its compilation by GCC (and usually 30x faster). But the optimizations done by a C compiler are worth it.<\/p>\n.so<\/code> shared object, you can dlopen<\/code> it. Don’t be shy, my manydl.c example demonstrates that on Linux you can dlopen a big lot of shared objects (many hundreds of thousands). The real bottleneck is the compilation of the generated C code. In practice, you don’t really need to dlclose<\/code> on Linux (unless you are coding a server program needing to run for months); an unused shared module can stay practically dlopen<\/code>-ed and you mostly are leaking process address space (which is a cheap resource), since most of that unused .so<\/code> would be swapped-out. dlopen<\/code> is done quickly, what takes time is the compilation of a C source, because you really want the optimization to be done by the C compiler.<\/p>\naddenda<\/h2>\n
\n
.so<\/code> file on Linux be re-compiled and re-<\/em> loaded at runtime?<\/p>\n<\/blockquote>\ngcc -O -fPIC -shared generated.c -o generated.so<\/code>, but you could do it indirectly e.g. by running a make -j<\/code>, especially if the generated.so<\/code> is big enough to make it relevant to split the generated.c<\/code> in several C generated files!) and then you dynamically load your library with dlopen (giving a full path like \/some\/file\/path\/to\/generated.so<\/code>, and probably the RTLD_NOW<\/code> flag, to it) and you have to use dlsym<\/code> to find relevant symbols inside. Don’t think of re<\/em>-loading (a second time) the same generated.so<\/code>, better to emit a unique generated1.c<\/code> (then generated2.c<\/code> etc…) C file, then to compile it to a unique<\/em> generated1.so<\/code> (the second time to generated2.so<\/code>, etc…) then to dlopen<\/code> it (and this can be done many hundred thousands of times). You may want to have, in the emitted generated*.c<\/code> files, some constructor functions which would be executed at dlopen<\/code> time of the generated*.so<\/code><\/p>\ngenerated*.so<\/code> thru dlsym<\/code>-ed function pointers. In practice you would decide for example that each generated*.c<\/code> defines a function void dynfoo(int)<\/code> and int dynbar(int,int)<\/code> and use dlsym<\/code> with \"dynfoo\"<\/code> and \"dynbar\"<\/code> and call these thru function pointers (returned by dlsym<\/code>). You should also define conventions of how and when these dynfoo<\/code> and dynbar<\/code> would be called. You’ll better link your base application with -rdynamic<\/code> so that your generated*.c<\/code> files could call your application functions.<\/p>\ngenerated*.so<\/code> to re-define<\/strong> existing<\/em> names. For instance, you don’t want to redefine malloc<\/code> in your generated*.c<\/code> and expect all heap allocation functions to magically use your new variant (that probably won’t work, and if even if it did, it would be dangerous).<\/p>\ndlclose<\/code> a dynamically loaded shared object, except at application clean-up and exit time (but I don’t bother at all to dlclose<\/code>). If you do dlclose<\/code> some dynamically loaded generated*.so<\/code> file, be sure that nothing is used in it: no pointers, not even return addresses in call frames, are existing to it.<\/p>\n