Re: Deprecation of the LM32 target

[Michael Walle <michael@walle.cc>]

Hi,

Am 2020-12-26 10:06, schrieb John Paul Adrian Glaubitz:
> Hello!
> 
> On 12/26/20 9:39 AM, Thomas Huth wrote:
>> the problem is not that the target CPU is old, but rather that 
>> according to the (former?) maintainer, there are no users left:
>> 
>>  https://www.mail-archive.com/qemu-devel@nongnu.org/msg605024.html
>> 
>> So it got marked as deprecated in this commit here:
>> 
>>  https://git.qemu.org/?p=qemu.git;a=commitdiff;h=d84980051229fa43c96b3
>> 
>> Without maintainer and without users, there is no point in keeping 
>> this target, is there?
> 
> I'm not sure how you determine whether there are people using the code
> or not. There
> is no really user tracking in QEMU, is there?

That is correct, one cannot know if there are actually users of the
milkymist board or the lattice eval board. These are the two only
supported boards. The (or I should better say "my") main purpose to
add a qemu target for milkymist was to help the developers of the
board, e.g. to ease debugging, etc. But development has stopped
long time ago [1]. I've never seen a request to add a new board.

> And the maintainer's claim that RISC-V takes over makes no sense
> either.

I've meant the ecosystem around the SoC. LM32 on linux never took of,
mostly because there is no MMU (we've worked on one though). There is
no official lm32 support in linux and g++ support is broken (or never
even worked). While for RISC-V there is huge userbase building all sorts
of tooling.

There is a project called LiteX [2], some sort of toolbox to build your
own SoC, which supports the LM32 as a CPU component. But I've never seen
anyone trying to add a board to qemu.

> The point of
> emulators is to be able to run old and existing software. If a target 
> had only a
> justification to exist while it's commercially viable, you would have
> to remove 90% of the targets in QEMU.
> I mean, the whole point of an emulator is being able to run existing
> code on modern hardware,
> usually because the old hardware is no longer available. And as long
> as the target is
> functional, I don't see a point in taking away the functionality.

I'm not arguing against this. In fact, I'd also like to keep the lm32
qemu target, but I personally don't have any time for that anymore. And
I don't know if its fair to put the burdon of unmaintained boards to all
the qemu developers. There are a lot of test cases for the LM32
target, but these only cover the CPU instructions. The last time I've
looked audio was broken. So without anyone caring about the target, it
won't also be much help for the user either.

-michael

[1] 
https://github.com/m-labs/milkymist/commit/7d944d3dcffb5e528a44937b10123ff65a0aecbc
[2] https://github.com/enjoy-digital/litex