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
