18:31 Pon, 30.03.2020. Jiaxun Yang <jiaxun.yang@flygoat.com> је написао/ла:
>
>
>
> 于 2020年3月31日 GMT+08:00 上午12:22:43, "Philippe Mathieu-Daudé" <
philmd@redhat.com> 写到:
> >On 3/30/20 6:18 PM, Jiaxun Yang wrote:
> >>
> >>
> >> 于 2020年3月30日 GMT+08:00 下午11:39:44, "Philippe Mathieu-Daudé"
> ><philmd@redhat.com> 写到:
> >>> Hi Jiaxun Yang,
> >>>
> >>> On 3/24/20 1:22 PM, Jiaxun Yang wrote:
> >>>> Loongson multimedia condition instructions were previously
> >>> implemented as
> >>>> write 0 to rd due to lack of documentation. So I just confirmed
> >with
> >>> Loongson
> >>>> about their encoding and implemented them correctly.
> >>>
> >>> If you have a binary using loongson multimedia instructions, can you
> >>> add
> >>> a test? So this code won't bitrot.
> >>
> >> I know ffmpeg uses it.
> >> But I think that's too fat.
> >
> >Looks perfect to me!
> >
> >It'll be simpler if you use a pre-build binary from a known
> >distribution.
>
> Unfortunately none of the distribution built ffmpeg with loongson insns
enabled,
> as it can't be enabled at runtime.
>
> I'll try that after fulfill Loongson Extensions in  QEMU.
>
> FFmpeg do use some other Loongson insns despite mmi.
>
> There are still 15+ instructions for me to work.
>

Jiaxun, hi.

My advice is to think about integrating Loongson-relared test into QEMU "in
background", with the intention that you possibly develop them later on.

Let's focus first on the code you want to add to enhance core
Loongson-related QEMU features, and we'll help you later on about Loongton
tests that could also be added to QEMU upstream.

I am sure you have some informal tests for all code you develop, but there
is a long way from these tests to the test that can be integrated in QEMU
upetream.

Just for reference, and something for you to think about in breaks between
real coding:

Basically, in QEMU, there are several kind of tests you could have in mind:

1) Unit tests yhat typically test emulation of just a single instruction
(see /tests/tcg/mips/user/ase/msa for example);

2) Acceptance test that test boot/shutdown and possibly other features of
virtual machines prepared in advance (kernel, rootfs, etc.), residing in
test/acceptance;

3) Tests that may use tests made for libraries and applicstions that use
the functionality of your newly-added features;

4) Other test that you may devise by your own and think are usefull and
make sense.

But again, let's focus and show us the main body of your code (as you
already started doing), let's start from there, and see how is it going and
what happens.

Thanks again for your work so far!

Yours,
Aleksandar

> Thanks
> --
> Jiaxun Yang