All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Alrae <leon.alrae@imgtec.com>
To: "Maciej W. Rozycki" <macro@codesourcery.com>
Cc: qemu-devel@nongnu.org, Aurelien Jarno <aurelien@aurel32.net>
Subject: Re: [Qemu-devel] [PATCH] mips: Respect CP0.Status.CU1 for microMIPS FP branches
Date: Fri, 7 Nov 2014 10:39:04 +0000	[thread overview]
Message-ID: <545CA148.8000203@imgtec.com> (raw)
In-Reply-To: <alpine.DEB.1.10.1411051539130.2881@tp.orcam.me.uk>

On 05/11/2014 20:16, Maciej W. Rozycki wrote:
>  Now as to CP0.Status.CU1, while fixing the 5Kc and 5KEc processors is an 
> obvious change, I think the removal of the extra check may not be such.  
> The thing is in the original architecture -- and it still stands for CP2 
> -- these bits used to control external coprocessors that may or may not 
> have been present.  For example to have an R3000 processor with an FPU you 
> wired an external R3010 unit to it.  Consequently all the CP0.Status.CUx 
> bits were always writable and the relevant logic to intereact with the 
> external chip enabled when requested.
> 
>  And there is software that relies on this property as prior to the 
> introduction of the modern MIPS architecture there was no CP0.Config1 
> register present to check the presence of an FPU with.  Instead what 
> software was supposed to do was to enable CP1, execute a CFC instruction 
> to read CP1.FIR that was supposed not to trap under these circumstances, 
> and check the value obtained in the Imp field (as it was then called) aka 
> ProcessorID.  If that was non-zero, an FPU was present, if it was zero 
> (due to the floating bus being strapped IIUC), no FPU was available. [2] 
> For example we have code in Linux doing this when run on the relevant 
> hardware.
> 
>  Obviously COP1X instructions would trap on CP0.Status.CU3 instead and for 
> example the FP emulator that we have in Linux is prepared for this 
> situation (whether it should really emulate a full MIPS IV if not higher 
> FP instruction set on a lower-ISA processor is another question).
> 
>  And I think all this draws the "right" implementation that we can make, 
> across all the three coprocessors actually, e.g. for CP1, except stores 
> and transfers from:
> 
>     check_cp1_enabled(ctx);
>     if (ctx->CP0_Config1 & (1 << CP0C1_FP)) {
>         handle_the_op();
>     }
> 
> for stores and transfers from:
> 
>     check_cp1_enabled(ctx);
>     if (ctx->CP0_Config1 & (1 << CP0C1_FP)) {
>         write_destination(read(source));
>     } else {
>         write_destination(0);
>     }

Yes, if we take into account also legacy CPUs, then this sounds like a
good way to go (instead of just removing extra check).

Thanks,
Leon

      reply	other threads:[~2014-11-07 10:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-03 19:08 [Qemu-devel] [PATCH] mips: Respect CP0.Status.CU1 for microMIPS FP branches Maciej W. Rozycki
2014-11-05 15:26 ` Leon Alrae
2014-11-05 20:16   ` Maciej W. Rozycki
2014-11-07 10:39     ` Leon Alrae [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=545CA148.8000203@imgtec.com \
    --to=leon.alrae@imgtec.com \
    --cc=aurelien@aurel32.net \
    --cc=macro@codesourcery.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.