On Fri, 2015-02-06 at 09:13 +0100, Torbjörn Granlund wrote:

> I think the old assembly code should be tweaked for r6 in a slightly
> deeper way.  Two extra move instructions in a critical loop isn't OK.
> The mips code you started with is seriously out-of-date, with
> over-scheduling of load; this ought to be fixed too.

My thought was to get a working version checked in and then make
improvements after that.

> In the r6 parts which exists and are planned, are mulu and muhu
> pipelined?  If they are pipelined, how close can a 2nd multiply be
> scheduled without issue stalling?  What are their latency?

mulu and muhu will be pipelined (at least for high and medium end
cores), I am not entirely sure about low end cores.

>   Is there a way to do 'make check' with a simulator or a remote system?
> 
> If you are patient enough, perhaps you could find a QEMU release which
> works well enough for testing this?  I recall having seen some mention
> of mipsr6 around QEMU, so presumably the QEMU folks made some attempt at
> supporting this.

The top-of-tree Qemu is pretty good these days, I use it for GCC
testing, including R6 testing.

> Finding a linux config which works with a QEMU version and config can be
> quite irksome.  Often, you will need to patch QEMU's handling of one or
> two instructions.
> 
> QEMU's mips64 emulator have been particularly buggy in the past years,
> with perhaps a dozen releases which were useless.
> 
>   I usually build MIPS code using a cross compiler on an x86 Linux box and
>   that is what I did to build GMP (using --build=x86_64-unknown-linux-gnu
>   --host=mips-img-linux-gnu or some other host depending on what flavor of
>   MIPS I wanted to build).  I was hoping I could run 'make check' on the
>   x86 box and have it run tests via a simulator.  That makes it easier to
>   build and test multiple MIPS architectures.
>   
> GMP provides a TEST_ENVIRONMENT environment variable which could be used
> for remote executiion.

OK, I will look into TEST_ENVIRONMENT.
> 
>   I tweaked the GMP configure script to recognize mips*-mti-* and
>   mips*-img-* targets, these hosts/targets exist in GCC and binutils as
>   names to use for cross compilers targeting MIPS (mti for pre-r6, img for
>   r6).
>   
> Then GCC apparently abuses the GNU configure system.  GMP follows the
> GNU convention cpu-system[-kernel]-os.  For r6 CPUs, use either
> cpu=mips64r6 or [when pipeline-specific optimised assembly is provided]
> cpu=mipsfoo where foo describes the specific CPU.
> 
> We need FSF paperwork to handle your patch.  Are you willing to sign
> your work to the FSF?  If you are employed to do programming, we need
> assignment or disclaimer from your employer too.

I'll have to work on this.  The company I work for (Imagination
Technologies, which purchased MIPS) has an FSF copyright assignment on
file but it does not include GMP in the list of projects.

Steve Ellcey
[email protected]


_______________________________________________
gmp-devel mailing list
[email protected]
https://gmplib.org/mailman/listinfo/gmp-devel

Reply via email to