[PATCH resend] MIPS: Allow FPU emulator to use non-stack area.

David Daney ddaney@caviumnetworks.com
Tue Oct 7 18:50:00 GMT 2014


On 10/07/2014 11:44 AM, Andy Lutomirski wrote:
> On Tue, Oct 7, 2014 at 11:32 AM, Leonid Yegoshin
> <Leonid.Yegoshin@imgtec.com> wrote:
>> Well, I am not a subscriber to mail-list, so I read it the first time and
>> some notes:
>>
>
>>
>> 3)  The signal happened during execution of emulated instruction - signals
>> are under control of kernel and we can easily delay a signal during
>> execution of emulated instruction until return from do_dsemulret. It is not
>> a big deal - nor code, nor performance. Thank you for good point.
>
> If you go down this particular rabbit hole, you will never come back out.
>
> What happens if one of those out-of-line instructions causes a
> synchronous trap?  What if SIGSTOP arrives before ret?  What if
> another thread removes the magic ret sequence?
>
>>
>> 4)  The voice for doing any instruction emulation in kernel - it is not a
>> MIPS business model to force customer to put details of all Coprocessor 2
>> instructions public. We provide an interface and the rest is a customer
>> business. Besides that it is really painful to make a differentiation
>> between Cavium Octeon and some another CPU instructions with the same
>> opcode. On other side, leaving emulation of their instructions to them is
>> not a wise after having some good way doing that multiple years.
>
> IMO this is all backwards.  If MIPS customers put proprietary
> instructions into their ISA, they leave out the FPU, and they put a
> proprietary insn in a branch delay slot, then I think that they
> deserve a fatal signal.
>
> There's a really easy solution for new systems: fix the toolchain.
> Teach the assembler to disallow any proprietary instructions in an FP
> branch delay slot.
>

Yes, gas for MIPS already has an instruction attribute for instructions 
that cannot be placed in delay slots.  It should be a fairly simple 
matter to extend this to instructions that cannot be emulated.

Thanks,
David Daney


> --Andy
>



More information about the Libc-alpha mailing list