GCC Dehydra is evolving much faster than the Elsa version did and it is easier to use. Once I implemented virtual methods correctly, Joshua was able to do his thing in no time at all. All it takes is a custom GCC (I’d love to see it packaged) and specifying plugin parameters in CXXFLAGS.
Dehydra has some new tricks now like a tree representation of types (instead of a string) with full typedef support. Lisp remnants in GCC are getting a new life as JavaScript objects.
I’m current working on exposing the full GCC tree structure in JavaScript so one could do any analysis they wanted in pure JS. Dynamically typed GCC tree nodes are great for that. I’m starting with middle-end GIMPLE representation so in theory one will be able to analyze anything gcc can compile (Java, C++, C, ObjC, ObjC++, FORTRAN?). Eventually this will be expanded to support frontend specific tree nodes to be able to look at code closer to the way it was written. Oh and I expect people will be able to script large parts of C++ -> JavaScript rewrites with Dehydra.
In theory, one could make tree node conversion two way which would enable writing optimization passes in JS, but that would be silly.
What’s the point?
I want to be able to do Exception-safety analysis in pure JS. I want to enable unit checking (thought typedefs and inline conversion functions) in pure JS.
Additionally, Dehydra should be awesome for generating bindings. For example, I’ll be able use Dehydra to import GCC’s autogenerated enums to get string names for nodes.
Also it will become easy to extract callgraphs and various other stats out of the code if they are accessible in JS. Eventually we’ll be switching Dehydra to Tamarin to do all of the above really really fast.
GCC Plugins
While I am messing with the GCC AST, Dave is working on utilizing GCC’s control flow graphs with a separate plugin. Eventually we’ll merge our work, but for now it’s nice to not step on each others toes while adding features to the compiler. Given how easy life is with plugins I am amazed that people chose to go uphill bothways and not collaborate on a plugin interface for their crazy GCC extensions. Yes, I’m looking at you: mygcc and gccxml.
Aren’t there IDEs interested in making use of GCC internals too or is everybody interested in maintaining yet another crappy C parser like Linux’s Sparse tool?
I’m looking forward to exploring the many ways we can reuse what’s in the compiler to empower developers for Mozilla 2.
You won’t have to switch DeHydra to Tamarin — the “jsapi.h” JS API (mostly; I’ll check the entry points used by DeHydra but IIRC they’re likley to stay) will remain.
/be
… will remain in the ActionMonkey future, I mean (when SpiderMonkey and Tamarin [tamarin-tracing, of course] finish their slow mating dance).
/be
This is awesome. I hope more projects that involve parsing C++ go this route. I just spent a few days fighting SWIG because its C++ parser isn’t quite perfect. It’s frustrating, but hopefully things will continue to evolve now that GCC plugins are an option for people.
> Given how easy life is with plugins I am amazed that people chose to go uphill bothways and not collaborate on a plugin interface for their crazy GCC extensions
Unfortunately, plugins accessing compiler internals have always been frowned upon by many regulars of the gcc community and more importantly by the Steering Commitee, it is only since just very recently that first steps are being taken -and in fact allowed to be taken- to implement the necessary infrastructure mechanisms within gcc.
But there are still many non-technical issues that people are afraid of, mainly related due to concerns about possible ways to circumvent the GPL .
If you are interested in details, you may want to search the gcc archives for the terms “introspector”, “plugins”, “scripting”, “intermediate state”
Boris