Re: [PATCH] MIPS32 DSP intrinsics

[Nigel Stephens <nigel at mips dot com>]

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