MLRISC – A framework for retargetable and optimizing compiler back ends | Hacker News Reader

MLRISC – A framework for retargetable and optimizing compiler back ends

cs.nyu.edu

28 pointssctb12 comments

It isn't listed on that somewhat-old page, but as part of the Manticore project we (primarily Mike Rainey) also added an x86_64 backend to MLRISC:

https://smlnj-gforge.cs.uchicago.edu/scm/viewvc.php/MLRISC/?...

In the long run, we on Manticore - like most other projects - will probably give up the flexibility of MLRISC and contort our code generation to work with LLVM. It's hard to keep adding new instructions to MLRISC!

It's hard to keep adding new instructions to MLRISC!

Could you expand on this? Based on the problem statement page, this seems to be the exact problem MLRISC tried to address. Is there something that keeps it from working well in practice?

It just takes time to do, and given that it's been a long time since there were any "infrastructure" grants to handle student or faculty time to support adding those instructions, adding and debugging them just takes time that nobody has to take out of doing research.

It also doesn't help that everybody who has worked on MLRISC has long since moved on to other projects, so when you find what you think is a bug in something core, there's really nobody to chat with about it, get feedback on where the right place to make a fix is, etc.

Ah, thought you were talking about some technical limitation. That's a shame, one would think an alternative to LLVM that is not so C-specific would find more use.

Is this still maintained? It seems SML/NJ still uses it, do they track any sort of development of it? Are they the main supporters of the project? The website seems to date to 2003, and refers to architectures like Itanium as upcoming. It also doesn't mention x64 at all.

Looks like it's still part of the SML/NJ tree. The last commit was in 2013: http://smlnj-gforge.cs.uchicago.edu/scm/viewvc.php/MLRISC/tr...

http://smlnj.cs.uchicago.edu/dist/working/110.78/MLRISC.tgz

*edit, `cloc` doesn't understand the sml/nj set of file types

Is about 100kloc of .sml

Yes, SML/NJ and Manticore (which have more than a bit of overlap) are still the main supporters. The x86_64 backend is only used by Manticore today; SML/NJ is still only 32-bit, though there's some work going on to migrate it to 64-bit, at which point it would also exercise that backend.

Personally I'd like to be able to use a system that has human-readable C as a backend, along with the idea of 'semantic C' that I've discussed a couple times in the past. Anyone with me on this?

Past comment: https://news.ycombinator.com/item?id=8283025

Base on that comment it sounds like you want C with AST based macros and a bidirectional canonical AST mapping. As the other poster pointed out, I'd start by porting sweetjs to C.

You might find an alignment of the vision with Nim http://nim-lang.org/ . The have done a C backend as for their language, and the language appears to have the semantic properties you have mentioned...

from the site:

" ... •Macros can use the imperative paradigm to construct parse trees. Nim does not require a different coding style for meta programming.

•Macros cannot change Nim's syntax because there is no need for it. Nim's syntax is flexible enough.

•Statements are grouped by indentation but can span multiple lines. Indentation must not contain tabulators so the compiler always sees the code the same way as you do "

C doesn't make for an optimal backend, due to issues like:

- no proper tail calls

- no way to cheaply check if arithmetic has overflowed, so performant arbitrary-precision integers are hard to implement

- hard to find GC roots on C stack

C-- is a better portable assembly language that was designed for such purposes.

http://www.cminusminus.org/

Unfortunately it looks like it hasn't found wider adoption (except for GHC), similar to MLRISC.

Reply on news.ycombinator.com