Monday, February 25, 2013
Moving away from XText
When I started with PSHDL, I used XText for developing the language. It seemed very beneficial for me as I had plenty of experience with it (some of which was bad experience), but others were very good. If you think about it, the idea of XText is pretty nice. You create a quite straight forward language definition and by some magic you will get a complete Eclipse Editor with syntax highlighting, outline, rename refactoring, linking etc. This is really awesome. But as PSHDL evolved it become harder to justify the usage of XText. After all it comes with some baggage.
If you don't know XText, go check it out. One of the first things that annoyed me however is the fact that the generated model is based on EMF and Eclipse. So everything is fine as long as you want is an Eclipse editor. However I discovered that PSHDL has to be more than just an Eclipse editor. While it is possible to create a command line version of it, it comes with some nasty side-effects. The first one is that it depends on none less than 45 external jars to run. This makes the compiler executable a 25MBytes biggy that takes 850ms just to fire up a completely useless OSGI and plugin management system. Compiling a bigger piece of code takes 5s.
As "replacement" I used ANTLR4. This of course does not give me a full blown Eclipse IDE, but it gives me the freedom to implement other things. For example I can now access the comments and bring most of them over to the VHDL code. This helps to bring some documentation to VHDL. I can also add documenting Comments JavaDoc style. This allows me to annotate the port declaration. Another thing is that I can give better error messages and provide better guidance towards a correct source in case of syntax errors. Also the compiler can now become much smaller. It is now 3.8MBytes and take 3.8s to compile the same source.
But what is much more important than anything else: I can now easily embed it into any IDE that I like, not just Eclipse. People are more willing to integrate it in their workflow if it is small and fast. The downside is: I have to develop my own Eclipse tooling. But I am fairly familiar with Eclipse and so that is no big problem for me.