Status of EM languages

[rochus-keller]

Does anyone know, whether the documentation in https://tack.sourceforge.net/olddocs/em.pdf of the EM language family is still precise and representative enough for the recent version of the toolkit (i.e. the most recent commit on the default branch, or the 6.0pre5 release)? If not, how about the old 5.6 release? If I would use the mentioned document to build a new front or back end creating or using the specified EM, would it still work with the rest of the tools?

[davidgiven]

Yup, it's still accurate. We haven't made any spec changes (that I can remember!) since then.

If you're interested in doing either, there's a robust EM reading/writing library supplied. See https://github.com/davidgiven/ack/blob/default/modules/src/em_mes/em_mes.3 for the writer and https://github.com/davidgiven/ack/blob/default/modules/src/read_em/read_em.3 for the reader. It's not as trivial as it sounds because EM files can have two different encodings depending on whether you want plain text or binary.

[rochus-keller]

Great, thanks.

Somewhere you wrote that the generated code is good enough for CISC, but bad for RISC. How about the peephole and global optimizer? Is the resulting EM code significantly more efficient? Are there any performance results, e.g. on a CISC machine with and witouth the EM optimizer stages?

Has anyone ever tried to reuse the TCC backend, i.e. feed EM code to the TCC code generator? That would make all TCC backends accessible in one batch (i.e. i386, AMD64, arm, arm64, Risc-V).

[davidgiven]

Belatedly: I have certainly not done any performance tests for the backend peephole optimiser. I've worked on the i80 one, and that just does small stuff, but the m68020 one looks significant, with things like add #2, sp; ... turned into ... (sp)+.

Interestingly, the x86 machs don't have a backend peephole optimiser configuration, which is odd as they're the most highly optimised.

In terms of the frontend peephole optimiser, that is, util/opt, I have even less data. The patterns file is significant, though. Also, it does some last-stage processing which is mandatory; if you disable it entirely the code stops working.

Re tcc: that's an interesting idea. The EM code would need a lot of processing to make it low-level enough for tcc, but my prototype mcg code generator already does this. (Do you know about graph colouring register allocators? If so, help wanted.) However, isn't the tcc code generator really inefficient, focusing on fast code generation rather than fast code execution?

[rochus-keller]

Indeed ;-)
Meanwhile I took a totally different route; someone pointed me to the Eigen Compiler Suite (see e.g. https://github.com/EigenCompilerSuite/) and I spend quite a lot of time with it so far. It supports a lot of architectures, but since it is written in C++, it's likely not of use for the ACK. I migrated two C compiler to Eigen backends, one of which is the libfirm cparser (just replaced libfirm by the Eigen backend). Eigen unfortunately doesn't have an optimizer yet, but I also made performance measurements with cparser/libfirm and noticed that the optimized code was not that much faster than the unoptimized (only about 30% despite the huge, complex optimization pipeline), but compile time more than doubled. TCC is unoptimized, and the generated code achieves about the same performance as GCC generated code with -O0. Before I went with Eigen I spent a significant amount of time with the TCC backend and analysis/modularization of the code, was not a pleasant experience. It's no wonder that the further development of TCC has been making no headway for years.