This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] MIPS32 DSP intrinsics

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

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
   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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]