Hey Chris, Sorry, some of my responses above are a bit surly.
We should think of C::Blocks as a front-end to libtcc with highly sophisticated symbol table management. Although we might use C::Blocks to prototype PDL JIT stuff, we almost certainly should expect to hook directly into libtcc ourselves. Since libtcc with extended symbol table support is distributed via Alien::TinyCCx, we should be able to get that working for all sorts of PDLs for all sorts of Perl versions. As for object-oriented stuff, I have begun to realize that we will need to keep track of object and class properties at the Perl level, i.e. we need some sort of object system or meta-object protocol. Tracking this at the C level is likely to be too daunting. Rather than re-invent the wheel, I believe we can make use of Moose's Class::MOP. We would need to subclass things like Class::MOP::Attribute and Class::MOP::Method so that they know how to construct vtables and struct layouts, and so they know how to work with C types and code. If we use XS::Object::Magic, then we will not have too much trouble using a hashref for the basic Perl-level reference, something that I *really* like about Prima. So, that's my 2 cents for the moment on that bit. David On Wed, Aug 5, 2015 at 3:32 PM, Chris Marshall <[email protected]> wrote: > Hi David- > > Per my response to Joel, I think the basic improved PDL::PP::JIT > support could be done in a simple but clunky way using a basic > libtcc interface. The legacy perls could still have the benefits of > new JIT compiling while the modern perls could be C::Blocks based. > > I haven't yet gotten tcc to build on cygwin but I look forward to trying > out your code when I get a working tcc. > > Cheers, > Chris > > On Wed, Aug 5, 2015 at 1:24 PM, David Mertens <[email protected]> > wrote: > >> Hey Chris, >> >> Another idea occurred to me. If you absolutely need v5.10 supported, >> somebody (i.e. not me) could probably hack something together with >> Devel::Declare. This would make it possible to use the same interface, and >> would work for Perls all the way back to v5.8.1. I am skeptical about how >> well it would handle some of the most important features of C::Blocks, >> however, such as lexical scoping of shared C libraries. This would not be a >> small undertaking. >> >> David >> >> On Wed, Aug 5, 2015 at 12:21 PM, David Mertens <[email protected]> >> wrote: >> >>> Yes, it absolutely requires the keyword API to work. >>> >>> From the Perl side, it builds and inserts OPs, and it checks the local >>> compiling context for lexically scoped variables. These can only be done by >>> "breaking" into the Perl parser, hence the keyword API. >>> >>> From the TCC side, TCC uses a lot of globals, setting them up during >>> TCCState construction. This means you cannot have multiple active >>> compilation units at the same time. Keywords let me enforce one state at a >>> time merely by code layout, in a way that is completely obvious to a user, >>> letting me hide all of this. >>> >>> It may be possible to write a C::Blocks library that exposes the libtcc >>> API, in which case you would be able to build your own compiler states and >>> manage extended symbol tables. Or, if you just want normal TCC, just use >>> XS::TCC, C::TinyCompiler, or FFI::TinyCC. >>> >>> David >>> >>> On Tue, Aug 4, 2015 at 8:39 PM, Chris Marshall <[email protected]> >>> wrote: >>> >>>> Does C::Blocks really require the perl keyword API to work? >>>> It would be nice if there was a version that could work with >>>> perl 5.10.x. >>>> >>>> --Chris >>>> >>>> >>>> > -- "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
------------------------------------------------------------------------------
_______________________________________________ pdl-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pdl-general
