Re: What to do with the nanomips disassembler (was: [PATCH] disas: Remove libvixl disassembler)
On 04/07/2022 14.22, Milica Lazarevic wrote: On 09/06/2022 18.31, Vince Del Vecchio wrote: ... Regardless, I think we can look at converting the existing disassembler from C++ to C. That would address the current concern, right? > Right - if it's not too much of a hassle that would be great! Hi everyone, I am interested in taking on this task. Since nobody else replied, I assume nobody started working on this task yet, so I'd say: Please go ahead and convert that file to plain C! Thanks, Thomas
What to do with the nanomips disassembler (was: [PATCH] disas: Remove libvixl disassembler)
Hi everyone, I am interested in taking on this task. Milica
What to do with the nanomips disassembler (was: [PATCH] disas: Remove libvixl disassembler)
FYI: Copying the conversation. On 09/06/2022 18.31, Vince Del Vecchio wrote: On Thu, Jun 9, 2022 at 10:34AM, Thomas Huth wrote: On 09/06/2022 16.15, Claudio Fontana wrote: On 6/9/22 13:27, Claudio Fontana wrote: On 6/9/22 10:57, Daniel P. Berrangé wrote: On Thu, Jun 09, 2022 at 10:47:24AM +0200, Thomas Huth wrote: On 08/06/2022 17.51, Paolo Bonzini wrote: On 6/3/22 19:35, Thomas Huth wrote: On 03/06/2022 19.26, Claudio Fontana wrote: [...] maybe something we can now drop if there are no more C++ users? I thought about that, too, but we still have disas/nanomips.cpp left and the Windows-related files in qga/vss-win32/* . That is pure C++ so it does not need the extra complication of "detect whether the C and C++ compiler are ABI-compatible" (typically due to different libasan/libtsan implementation between gcc and clang). So it's really just nanoMIPS that's left. Ok, so the next theoretical question is: If we get rid of the nanomips.cpp file or convert it to plain C, would we then simplify the code in configure again (and forbid C++ for the main QEMU code), or would we rather keep the current settings in case we want to re-introduce more C++ code again in the future? It doesn't feel very compelling to have just 1 source file that's C++ in QEMU. I'm curious how we ended up with this nanomips.cpp file - perhaps it originated from another project that was C++ based ? The code itself doesn't look like it especially needs to be using C++. There's just 1 class there and every method is associated with that class, and external entry point from the rest of QEMU is just one boring method. Feels like it could easily have been done in C. Personally I'd prefer it to be converted to C, and if we want to add any C++ in future it should be justified & debated on its merits, rather than as an artifact of any historical artifacts such as the code in configure happening to still exist. I'll take a look at it, maybe I can turn it to C fairly quickly. It seems to be generated code, getting the original authors involved in the thread. Not sure whether the original mips folks are still around ... but the folks from MediaTek recently expressed their interest in nanoMIPS: https://lore.kernel.org/qemu-devel/20220504110403.613168-8-stefan.pe...@syrmia.com/ Maybe they could help with the nanoMIPS disassembler? I know it's likely a lot of work, but the best solution would maybe be to add nanoMIPS support to capstone instead, then other projects could benefit from the support in this library, too... If I googled that right, there is a LLVM implementation of nanoMIPS available here: https://github.com/milos1397/nanomips-outliner/tree/master/llvm/lib/Target/Mips ... so maybe that could be used as input for capstone (which is based on llvm)? Thomas Yes, we are working on an LLVM port for nanoMIPS. It's functionally complete and pretty usable, although we're still tuning performance. The more official location is https://github.com/MediaTek-Labs/llvm-project. However, for now we're still using the binutils assembler; there's no encoding information in the current LLVM description. We have tentative plans to work on encoding and integrated-as later this year. Correct me if I'm wrong, but I would assume that, before that's available, it's not feasible to use capstone? I'm also not very familiar with the way capstone translated the information from LLVM into its disassembler source files, but I guess you're right - this likely cannot work yet. Regardless, I think we can look at converting the existing disassembler from C++ to C. That would address the current concern, right? Right - if it's not too much of a hassle that would be great! Thomas Hi everyone, I am interested in taking on this task. Milica
Re: What to do with the nanomips disassembler (was: [PATCH] disas: Remove libvixl disassembler)
On 09/06/2022 18.31, Vince Del Vecchio wrote: On Thu, Jun 9, 2022 at 10:34AM, Thomas Huth wrote: On 09/06/2022 16.15, Claudio Fontana wrote: On 6/9/22 13:27, Claudio Fontana wrote: On 6/9/22 10:57, Daniel P. Berrangé wrote: On Thu, Jun 09, 2022 at 10:47:24AM +0200, Thomas Huth wrote: On 08/06/2022 17.51, Paolo Bonzini wrote: On 6/3/22 19:35, Thomas Huth wrote: On 03/06/2022 19.26, Claudio Fontana wrote: [...] maybe something we can now drop if there are no more C++ users? I thought about that, too, but we still have disas/nanomips.cpp left and the Windows-related files in qga/vss-win32/* . That is pure C++ so it does not need the extra complication of "detect whether the C and C++ compiler are ABI-compatible" (typically due to different libasan/libtsan implementation between gcc and clang). So it's really just nanoMIPS that's left. Ok, so the next theoretical question is: If we get rid of the nanomips.cpp file or convert it to plain C, would we then simplify the code in configure again (and forbid C++ for the main QEMU code), or would we rather keep the current settings in case we want to re-introduce more C++ code again in the future? It doesn't feel very compelling to have just 1 source file that's C++ in QEMU. I'm curious how we ended up with this nanomips.cpp file - perhaps it originated from another project that was C++ based ? The code itself doesn't look like it especially needs to be using C++. There's just 1 class there and every method is associated with that class, and external entry point from the rest of QEMU is just one boring method. Feels like it could easily have been done in C. Personally I'd prefer it to be converted to C, and if we want to add any C++ in future it should be justified & debated on its merits, rather than as an artifact of any historical artifacts such as the code in configure happening to still exist. I'll take a look at it, maybe I can turn it to C fairly quickly. It seems to be generated code, getting the original authors involved in the thread. Not sure whether the original mips folks are still around ... but the folks from MediaTek recently expressed their interest in nanoMIPS: https://lore.kernel.org/qemu-devel/20220504110403.613168-8-stefan.pe...@syrmia.com/ Maybe they could help with the nanoMIPS disassembler? I know it's likely a lot of work, but the best solution would maybe be to add nanoMIPS support to capstone instead, then other projects could benefit from the support in this library, too... If I googled that right, there is a LLVM implementation of nanoMIPS available here: https://github.com/milos1397/nanomips-outliner/tree/master/llvm/lib/Target/Mips ... so maybe that could be used as input for capstone (which is based on llvm)? Thomas Yes, we are working on an LLVM port for nanoMIPS. It's functionally complete and pretty usable, although we're still tuning performance. The more official location is https://github.com/MediaTek-Labs/llvm-project. However, for now we're still using the binutils assembler; there's no encoding information in the current LLVM description. We have tentative plans to work on encoding and integrated-as later this year. Correct me if I'm wrong, but I would assume that, before that's available, it's not feasible to use capstone? I'm also not very familiar with the way capstone translated the information from LLVM into its disassembler source files, but I guess you're right - this likely cannot work yet. Regardless, I think we can look at converting the existing disassembler from C++ to C. That would address the current concern, right? Right - if it's not too much of a hassle that would be great! Thomas
RE: What to do with the nanomips disassembler (was: [PATCH] disas: Remove libvixl disassembler)
On Thu, Jun 9, 2022 at 10:34AM, Thomas Huth wrote: > On 09/06/2022 16.15, Claudio Fontana wrote: >> On 6/9/22 13:27, Claudio Fontana wrote: >>> On 6/9/22 10:57, Daniel P. Berrangé wrote: On Thu, Jun 09, 2022 at 10:47:24AM +0200, Thomas Huth wrote: > On 08/06/2022 17.51, Paolo Bonzini wrote: >> On 6/3/22 19:35, Thomas Huth wrote: >>> On 03/06/2022 19.26, Claudio Fontana wrote: > [...] maybe something we can now drop if there are no more C++ users? >>> >>> I thought about that, too, but we still have disas/nanomips.cpp >>> left and the Windows-related files in qga/vss-win32/* . >> >> That is pure C++ so it does not need the extra complication of >> "detect whether the C and C++ compiler are ABI-compatible" >> (typically due to different libasan/libtsan implementation between >> gcc and clang). So it's really just nanoMIPS that's left. > > Ok, so the next theoretical question is: If we get rid of the > nanomips.cpp file or convert it to plain C, would we then simplify > the code in configure again (and forbid C++ for the main QEMU > code), or would we rather keep the current settings in case we want > to re-introduce more C++ code again in the future? > It doesn't feel very compelling to have just 1 source file that's C++ in QEMU. I'm curious how we ended up with this nanomips.cpp file - perhaps it originated from another project that was C++ based ? The code itself doesn't look like it especially needs to be using C++. There's just 1 class there and every method is associated with that class, and external entry point from the rest of QEMU is just one boring method. Feels like it could easily have been done in C. Personally I'd prefer it to be converted to C, and if we want to add any C++ in future it should be justified & debated on its merits, rather than as an artifact of any historical artifacts such as the code in configure happening to still exist. >>> >>> I'll take a look at it, maybe I can turn it to C fairly quickly. >> >> It seems to be generated code, getting the original authors involved in the >> thread. > > Not sure whether the original mips folks are still around ... but the folks > from MediaTek recently expressed their interest in nanoMIPS: > > > https://lore.kernel.org/qemu-devel/20220504110403.613168-8-stefan.pe...@syrmia.com/ > > Maybe they could help with the nanoMIPS disassembler? > > I know it's likely a lot of work, but the best solution would maybe be to add > nanoMIPS support to capstone instead, then other projects could benefit from > the support in this library, too... > > If I googled that right, there is a LLVM implementation of nanoMIPS available > here: > > > https://github.com/milos1397/nanomips-outliner/tree/master/llvm/lib/Target/Mips__;!!CTRNKA9wMg0ARbw!ypaF-7vGkOBh5G3xybGwIuJdGpUfrMavQlYF_4T9iocgw5x994tABF_B_RsCJIdqY4vwVzA$ > > > ... so maybe that could be used as input for capstone (which is based on > llvm)? > > Thomas Yes, we are working on an LLVM port for nanoMIPS. It's functionally complete and pretty usable, although we're still tuning performance. The more official location is https://github.com/MediaTek-Labs/llvm-project. However, for now we're still using the binutils assembler; there's no encoding information in the current LLVM description. We have tentative plans to work on encoding and integrated-as later this year. Correct me if I'm wrong, but I would assume that, before that's available, it's not feasible to use capstone? Regardless, I think we can look at converting the existing disassembler from C++ to C. That would address the current concern, right? -Vince
What to do with the nanomips disassembler (was: [PATCH] disas: Remove libvixl disassembler)
On 09/06/2022 16.15, Claudio Fontana wrote: On 6/9/22 13:27, Claudio Fontana wrote: On 6/9/22 10:57, Daniel P. Berrangé wrote: On Thu, Jun 09, 2022 at 10:47:24AM +0200, Thomas Huth wrote: On 08/06/2022 17.51, Paolo Bonzini wrote: On 6/3/22 19:35, Thomas Huth wrote: On 03/06/2022 19.26, Claudio Fontana wrote: [...] maybe something we can now drop if there are no more C++ users? I thought about that, too, but we still have disas/nanomips.cpp left and the Windows-related files in qga/vss-win32/* . That is pure C++ so it does not need the extra complication of "detect whether the C and C++ compiler are ABI-compatible" (typically due to different libasan/libtsan implementation between gcc and clang). So it's really just nanoMIPS that's left. Ok, so the next theoretical question is: If we get rid of the nanomips.cpp file or convert it to plain C, would we then simplify the code in configure again (and forbid C++ for the main QEMU code), or would we rather keep the current settings in case we want to re-introduce more C++ code again in the future? It doesn't feel very compelling to have just 1 source file that's C++ in QEMU. I'm curious how we ended up with this nanomips.cpp file - perhaps it originated from another project that was C++ based ? The code itself doesn't look like it especially needs to be using C++. There's just 1 class there and every method is associated with that class, and external entry point from the rest of QEMU is just one boring method. Feels like it could easily have been done in C. Personally I'd prefer it to be converted to C, and if we want to add any C++ in future it should be justified & debated on its merits, rather than as an artifact of any historical artifacts such as the code in configure happening to still exist. I'll take a look at it, maybe I can turn it to C fairly quickly. It seems to be generated code, getting the original authors involved in the thread. Not sure whether the original mips folks are still around ... but the folks from MediaTek recently expressed their interest in nanoMIPS: https://lore.kernel.org/qemu-devel/20220504110403.613168-8-stefan.pe...@syrmia.com/ Maybe they could help with the nanoMIPS disassembler? I know it's likely a lot of work, but the best solution would maybe be to add nanoMIPS support to capstone instead, then other projects could benefit from the support in this library, too... If I googled that right, there is a LLVM implementation of nanoMIPS available here: https://github.com/milos1397/nanomips-outliner/tree/master/llvm/lib/Target/Mips ... so maybe that could be used as input for capstone (which is based on llvm)? Thomas
