qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v8 00/38] target/mips: Limited support for the R


From: Maciej W. Rozycki
Subject: Re: [Qemu-devel] [PATCH v8 00/38] target/mips: Limited support for the R5900
Date: Thu, 25 Oct 2018 18:38:03 +0100 (BST)
User-agent: Alpine 2.21 (LFD 202 2017-01-01)

Hi Fredrik,

> >  NB all but pipeline 1 instructions of these are also implemented by other 
> > members of the TXx9 family.  They seem to be referred to as just "multiply 
> > and multiply-add instructions" in the TX79 manual (cf Section B.3.1).
> 
> Would
> 
> ASE_TOSHIBA_MMI  -- TX79 128-bit multimedia instructions
> ASE_TOSHIBA_MAC  -- TXx9 multiply and multiply-add instructions (MADD etc.)
> ASE_TOSHIBA_MAC1 -- TX79 pipeline 1 variant of ASE_TOSHIBA_MAC
> ASE_TOSHIBA_FMA  -- R5900 FPU extensions (MADD.s etc.)
> 
> be acceptable for the currently known Toshiba extensions? (Please propose
> better names.) One complication is that it seems only 8 bits are available
> for all vendor ASEs, and Toshiba would then scoop up half of those.

 I'm not sure if every single random vendor-specific instruction (or a 
bunch of) deserves its own ASE designation, be it internal or externally 
exposed.  I think the MMI set being a substantial architectural feature 
makes sense to be shown in /proc/cpuinfo (in Linux), but I don't think 
there's much more about it.  It's limited to 2 implementations only, so 
internally I think it can well be handled with a macro or static inline 
function (as appropriate) which boil down to (CPU_R5900 || CPU_TX79).

 And if you run out of bits for ASEs regardless, then I suggest just to 
expand the field in question.  In QEMU you can rely on the presence of the 
`uint64_t' data type, so with only 8 bits exhausted you're far from 
getting into trouble.

  Maciej



reply via email to

[Prev in Thread] Current Thread [Next in Thread]