I like C::TinyCompiler because it gives you a clue about what the module does: C language + tiny + compiler.
--Chris On Thu, Aug 15, 2013 at 12:07 PM, David Mertens <dcmertens.p...@gmail.com> wrote: > Another idea is C::TinyJIT. It's even more descriptive. But C::TinyCompiler > sounds better. > > Thoughts? Votes? > David > > On Thu, Aug 15, 2013 at 11:37 AM, David Mertens <dcmertens.p...@gmail.com> > wrote: >> >> On Thu, Aug 15, 2013 at 9:20 AM, Chris Marshall <devel.chm...@gmail.com> >> wrote: >>> >>> How about Devel::TCC for the bindings/interface/control part >> >> >> I looked through other modules with the Devel:: prefix (thanks to >> MetaCPAN's ability to do this search). Most modules here are development >> tools, such as debuggers and memory inspectors. But, to your point, some of >> them are interesting extensions that might be used in code indefinitely: >> Devel::Hook, Devel::Main, Devel::Declare, and Devel::REPL. >> >> But somehow Devel:: seems a bit too abstract to be helpful. I thought of >> this more as a plain old set of modules. Furthermore, most of the modules on >> CPAN that would interact nicely with this distribution are under C::, with >> the notable exception of Convert::Binary::C. Maybe I should reconsider >> C::TinyCC or C::TinyCompiler or something like that. >> >> I actually really like the ring of C::TinyCompiler: It tells you exactly >> what it is. :-) >> >>> >>> Alien::TCC (of course) for the detection and installation? >> >> >> Yes, of course. :-) >> >>> >>> >>> --Chris >>> >>> On Thu, Aug 15, 2013 at 8:57 AM, David Mertens <dcmertens.p...@gmail.com> >>> wrote: >>> > Hey everyone - >>> > >>> > In short, I have written a set of bindings for the library underlying >>> > the >>> > Tiny C Compiler and I want to know what package name I should use. I >>> > would >>> > prefer a top-level TCC package, in particular because I envision a >>> > large set >>> > of derived modules. Thoughts? >>> > >>> > David >>> > >>> > Motivation and features >>> > >>> > The Tiny C Compiler is a C compiler that can compile code for ARM and >>> > x86 >>> > processors. It was written to compile code very, very quickly, and >>> > compiles >>> > code roughly 7x faster than gcc -O0, roughly 40x faster than gcc -O3. >>> > In >>> > exchange for quick compile times, you get machine code that isn't as >>> > highly >>> > optimized. But it's still machine code. >>> > >>> > One of the coolest features of TCC is that if provides libtcc, which >>> > can >>> > take a string of C code and compile it to machine code without writing >>> > anything to disk. That's right, it's a true C jit compiler, just >>> > waiting for >>> > some nice Perl goodness to wrap it up. >>> > >>> > I've written bindings that expose the compiler's basic capabilities, >>> > such as >>> > defining preprocessor symbols, linking to other libraries, adding >>> > symbols to >>> > the symbol table, compiling the code, and retrieving compiled symbols >>> > (i.e. >>> > functions). I've also created an extension framework for module authors >>> > to >>> > wrap all of this into reusable pieces. For example, I've already >>> > written >>> > extensions that (1) expose croak() to your compile context, (2) provide >>> > a >>> > simple but useful data structure called StretchyBuffer, and (3) allow >>> > you to >>> > write C functions that you can call directly from your Perl code. I >>> > hope to >>> > some day wrap various C libraries with similar extensions. For example, >>> > I >>> > would like to wrap GSL such that a programmer can pull the GSL headers >>> > and >>> > symbols into their compiler context with a single Perl command. >>> > >>> > Similar Projects >>> > >>> > The first module/namespace that comes to mind is Inline::C. Certainly, >>> > it >>> > would be possible to create an Inline::TCC. However, Inline operates >>> > under >>> > the assumption that compiling code is a relatively costly enterprise, >>> > whereas my approach to TCC assumes that it is relatively cheap. When >>> > you >>> > decide that compiling code is cheap, a whole set of possibilities open >>> > up >>> > that you don't have otherwise. The whole extension system is perfect >>> > for >>> > TCC, but would be particular to the TCC system, and would not apply >>> > generally to the Inline system. As such, I don't think it's a very good >>> > fit >>> > for the Inline family or namespace. >>> > >>> > A second module/namespace is evident when you realize that a very >>> > primitive >>> > set of TCC bindings already exist under C::TCC. Unfortunately, that >>> > project >>> > does not provide any extension mechanism, or even a way for the >>> > underlying >>> > main() function to communicate with Perl. Also, I have tried to contact >>> > the >>> > author with no success. >>> > >>> > -- >>> > "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 >> >> >> >> >> -- >> "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 > > > > > -- > "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
