This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] MIPS32 DSP intrinsics
- From: Nigel Stephens <nigel at mips dot com>
- To: Eric Christopher <echristo at redhat dot com>
- Cc: Chao-ying Fu <fu at mips dot com>, Richard Sandiford <rsandifo at redhat dot com>, "Thekkath, Radhika" <radhika at mips dot com>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 01 Jun 2005 16:36:19 +0100
- Subject: Re: [PATCH] MIPS32 DSP intrinsics
- References: <3CB54817FDF733459B230DD27C690CEC012BAE76@Exchange.MIPS.COM> <email@example.com><000c01c5616c$23fa36d0$a914a8c0@MIPS.COM> <firstname.lastname@example.org> <000a01c5663e$d8f8b2b0$a914a8c0@MIPS.COM> <email@example.com>
Eric Christopher wrote:
About the testing, we modified binutils to assemble DSP
instructions, and used our own simulator to test the program.
The GNU simulator has not been changed to support DSP
instructions. This needs to be done sometime.
Since you'll need testcases for this work you'll at least need to have
the simulator patches for the net submitted to support the new
Hmm - have we really always insisted on full support in the GNU
simulator for new instructions added by CPU vendors, in advance of a new
CPU's general availability, including x86, PPC, IA-64, etc? As far as
regression tests are concerned we don't actually *have* to run the
resulting binaries, we can just check that the expected instructions
appear in the assembler output, can't we?
I'm not against adding these new instructions to the GNU simulator, it's
just that this may not be possible until the new architecture documents
have been made publicly available.
Nigel Stephens Mailto:firstname.lastname@example.org
_ _ ____ ___ MIPS Technologies Phone.: +44 1223 706200
|\ /|||___)(___ The Fruit Farm Direct: +44 1223 706207
| \/ ||| ____) Ely Road, Chittering Fax...: +44 1223 706250
TECHNOLOGIES UK Cambridge CB5 9PH Cell..: +44 7976 686470