> From: Fredrik Noring <nor...@nocrew.org>
> Sent: Tuesday, January 1, 2019 7:27 PM
> To: Aleksandar Markovic
> Cc: Aurelien Jarno; Philippe Mathieu-Daudé; Jürgen Urban; Maciej W. Rozycki;
> qemu-devel@nongnu.org
> Subject: Re: [PATCH v2 09/12] tests/tcg/mips: Test R5900 three-operand MADDU1
>
> Thanks Aleksandar!
>
> > > From: Fredrik Noring <nor...@nocrew.org>
> > > Subject: [PATCH v2 09/12] tests/tcg/mips: Test R5900 three-operand MADDU1
> >
> > Reviewed-by: Aleksandar Markovic <amarko...@wavecomp.com>
> >
> > This patch is selected for integration in the next MIPS pull request
> > scheduled shortly.
> >
> > THANKS FOR ALL EFFORTS!
>
> Is this a preparation to revert commit 823f2897bdd7 ("target/mips: Disable
> R5900 support")?
>
> Fredrik
Hello!
Glad to see you back!
Yes, one can say this is a step towards reenabling R5900 support.
However, this is not the only step. I will let you know about all
needed details in near future - and I apologize for being little
slow with responses so far, I was being swamped with other tasks.
Let's not rush. If one learned that the rush is bad, that is me,
making severe missteps, overly eager to do the thing sooner rather
than later. However, the faster in not always the better.
At this moment I have a question a suggestion for you:
- Question: Do you have somewhere link to n32 R5900 toolchain, or
similar thing that would enable me to test R5900's n32 in QEMU
(I'll do the tweaks in QEMU by myself for that, but I need a way
to compile R5900 test programs for n32)?
- Suggestion: The next MIPS pull request is scehuled for Friday,
Jan 18, 2018. It would be fantastic if you could prepare the
following by Jan 14:
* Add 32 TCGv_i64 registers that would represent higher halves
of R5900 general purpose registers.
* Add TCGv_i32 register SA (shift amount).
* Perhaps consider adding higher halves of registers HI an LO
independently on HI/LO array used by DSP.
* It is customary to implement R/W access while introducing
such registers:
* Implement R/W access instructions to higher halves of
R5900 GPRs:
* LQ
* SQ
* Implement R/W access instructions to SA register:
* MFSA
* MTSA
* MTSAH
* MTSAB
I think a reasonable person would consider that the number and
size of registers of emulated CPU is a fundamental thing that
must be done before enabling its support - hence my suggestion
above.
If you don't have enough time resources before Jan 14, that is
fine too, do everything at your own pace.
My vision is that we continue step by step amending R5900 until
we reach a decent and stable state of emulation and than enable
the R5900 support for end user. (I'll provide all the details
later on.)
Let me know if you have questions and/or different opinion.
Looking forward to seeing you!
Aleksandar
