[PATCH] MIPS32 DSP intrinsics
Nigel Stephens
nigel@mips.com
Wed Jun 1 17:05:00 GMT 2005
Paul Brook wrote:
>>I understand your concerns, but is this standard policy for GCC? We're
>>trying to get ahead here, and make sure that when our new CPU is
>>launched we have support for it in place within GCC and Binutils. We're
>>not talking about a long delay before publication - on the order of two
>>months.
>>
>>
>
>Apart from anything else we require that all intrinsics be documented.
>
Sure, but the built-in intrinsics for ARM, PPC Altivec, x86 SSE, etc are
documented only as a simple list of function names which imply that they
output instructions of the same name, for example:
The following built-in functions are available when both
@option{-m3dnow}
and @option{-march=athlon} are used. All of them generate the machine
instruction that is part of the name.
There's no detailed documentation on the operation of these built-ins or
their argument types.
>How do
>you propose to do this if the architecture details are not publicly
>available?
>
>
So if the new compiler intrinsics do indeed output the assembler
instructions "that are part of the name", and the assembler and
disassembler can then correctly assemble and disassemble them (with the
appropriate assembler test cases), then one could argue that we're
documented as well as any of the other CPU-specific built-ins. ;-)
We can add more exhaustive "complete program" tests in the future, as
and when support appears in the GNU simulator.
Nigel
More information about the Gcc-patches
mailing list