Jordi Molgo jmolgo@lleida.net wrote:

my name is Jordi Molgo, and I'm a student from the University of Lleida (Spain). I have been learning and developping with pike for the last three years, and I think that is the best language I have tried (good work, Pike team ;)

Thanks. :)

Currently I am searching for something which could be ok for my Graduate Project. Since the most interesting area in computer science to me is Compiler Design, so I am interested in developping a GCC front-end for some language. And my thoughts came directly to Pike. Uhmm.. why not? Of course, it would handle a little portion of Pike at the beggining, just the enough for my project being accepted.

I can comment on that idea from a design viewpoint. I don't know how familiar you are with the pike internals so I just ramble on and hope you'll ask if there are things you don't understand.

If Pike programs are compiled with gcc you'd have to link in a large runtime for it to work. I suspect it would more or less be the whole core plus some modules all the time: You'd have to get in the support for the data types like mappings and arrays, the gc would have to come go in with them, and the core modules which are required for bootstrapping would probably require all the stuff for file, backend, thread and signal support.

So what you'd get out from gcc is code that is more or less just a long sequence of calls to functions in the runtime that does the actual work. It'd be something similar to the machine code that we already generate in 7.4 and later. What gcc could do better than the internal code generator is mainly flow analysis and machine code generation afaics. E.g. register allocation isn't applicable since the virtual machine is stack based. Optimizations on data types would be hard to accomplish because pike doesn't have strict typing - every value carries around a runtime type which is checked everywhere before it's used. (We'd like to optimize that, of course, so that the runtime type info could be dropped in areas where the actual types are strictly known in advance.)

Another thing is that the Pike compiler is accessible from within Pike. Although you could compile a large part of the pike code externally with gcc it'd still be necessary to have the internal compiler around. In some applications (e.g. Roxen WebServer) large parts are compiled internally at runtime and would therefore not benefit from the gcc stuff. So it'd be more neat if this gcc compiler was embedded into Pike so that it replaced the internal compiler instead.

So my view is that it'd be more useful to incorporate stuff from gcc into pike rather than trying to make a pike frontend for gcc(*). This is mainly due to the dynamic nature of Pike as opposed to statically compiled, strongly typed languages like C, C++ and Java.

As I said earlier, the areas I can see where gcc clearly is better than pike is flow analysis and machine code generation. I suspect that porting the flow analysis from gcc would mean rewriting it, since I can't imagine that there are hardly any similarities between the abstract syntax trees in pike and gcc.

Porting over the machine code generation appears to be a lot more interesting. Pike has an extremely rudimentary architecture for that (see the files in src/code, especially README.txt). We'd gladly replace it with the elaborate stuff in gcc that uses high level machine descriptions etc.

Anyway, whatever you choose to do I welcome you to do it in or with Pike. If it's something that can fit in reasonably well then we'd be happy to help and get it integrated with the standard dist. It's very nice to get more people that aren't afraid of digging into the internals. :)

*) Although that would imply developing an embeddable pike library, something we'd like to do anyway.