18:31 Pon, 30.03.2020. Jiaxun Yang <[email protected]> је написао/ла: > > > > 于 2020年3月31日 GMT+08:00 上午12:22:43, "Philippe Mathieu-Daudé" < [email protected]> 写到: > >On 3/30/20 6:18 PM, Jiaxun Yang wrote: > >> > >> > >> 于 2020年3月30日 GMT+08:00 下午11:39:44, "Philippe Mathieu-Daudé" > ><[email protected]> 写到: > >>> 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
