
MLRISC – A framework for retargetable and optimizing compiler back ends - sctb
http://www.cs.nyu.edu/leunga/MLRISC/Doc/html/INTRO.html
======
larsberg
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/?...](https://smlnj-
gforge.cs.uchicago.edu/scm/viewvc.php/MLRISC/?root=smlnj)

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!

~~~
l_dopa
_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?

~~~
larsberg
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.

~~~
l_dopa
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.

------
Solarsail
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.

~~~
panic
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-
gforge.cs.uchicago.edu/scm/viewvc.php/MLRISC/trunk?root=smlnj&view=log)

~~~
sitkack
[http://smlnj.cs.uchicago.edu/dist/working/110.78/MLRISC.tgz](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

------
fizixer
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](https://news.ycombinator.com/item?id=8283025)

~~~
platform
You might find an alignment of the vision with Nim [http://nim-
lang.org/](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 "

