3 ms·
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://smln
by larsberg 12y ago
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/?root=smlnj 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!
- l_dopa 12y agoIt'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 12y agoIt 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 12y agoAh, 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.