Jürgen,
Adding the binutils list as more appropriate for some concerns discussed
here.
> > > > ll, sc, dmult, ddiv, cvt.w.s, 64 bit FPU instructions.
> > > > ll and sc is disabled with "-mno-llsc" and works.
> > > > cvt.w.s is replaced by trunc.w.s. This seems to work.
> > >
> > > Probably showing my ignorance, but I couldn't see this in the patch.
> >
> > This has raised my attention -- AFAICS the binutils change recently
> > approved correctly disables DMULT, DDIV, CVT.W.S, etc. for -march=r5900,
> > but does not do that for LL or SC. I think that should be fixed. And I
> > gather LLD and SCD should then be disabled as well.
>
> The glibc can only be compiled with support for ll and sc. The Linux
> kernel successfully emulates these instructions. When compiling GCC for
> mips*r5900*-elf (i.e. not Linux), the instructions ll/sc and lld/scd are
> disabled by my patch.
That a particular OS emulates some instructions in software does not
necessarily make them a part of the architecture. GAS needs to support
any target environment, including bare iron, and as such should closely
match the hardware implementation. I think the right place to address it
is glibc.
The library can be built for the base MIPS I ISA that did not have LL or
SC instructions either and therefore already has some provisions in place
to override the processor/ISA selection for the code fragments in question
so that the instructions otherwise missing from the target hardware
selected are nevertheless assembled successfully. This is currently
enabled for the o32 ABI, where .set mips2 is used to enable the assembly
of LL and SC.
Now if that failed for you, then it's a plain bug in GAS that should be
fixed. Can you therefore check whether a piece like:
.set mips2
ll $2, ($3)
assembles correctly with -march=r5900?
Please note that the issue of LLD and SCD remains open -- these
instructions are a part of the base MIPS III 64-bit ISA and therefore they
are assumed by glibc and elsewhere to be present, and they are not
emulated by Linux. So not only you'll have to fix up glibc to surround
their use with .set mips3 for the n64 and n32 ABIs (please note that .set
mips3 is needed for LL and SC for these ABIs as well to avoid a
miscalculation of addresses where applicable), but you'll have to add
emulation code to Linux as well.
And in any case I insist that the instructions are correctly marked in
the opcode table.
> > Things would get more complicated if one wanted to run a real OS such as
> > Linux on the R5900 and let the kernel FP emulator handle the missing
> > double FP automagically -- this is a little bit out of scope here as
> > regular -mdouble-float would then just do, but makes me wonder whether
> > -mfp32 should really be enforced (as opposed to just defaulted) for the
> > R5900, hmm...
>
> I tried to emulate the 64 Bit FPU when the real 32 Bit FPU was enabled
> in Linux. There are 2 problems with this:
>
> 1. When the program starts, I don't know if it needs a 64 Bit or 32 Bit
> FPRs. So registers are initialized for 32 bit. When dmfc0 or dmtc0
> appears, I need to emulate them using 32 Bit FPU, because some 32 bit
> programs use these instructions with a 32 Bit FPU (e.g. Linux 2.6.35
> kernel and Debian 5.0). When a 64 bit calculation instructions appears,
> I need to switch from 32 bit FPRs to 64 bit FPRs. When the program used
> 32 bit instructions with the odd FPRs, there is no way to reconstruct
> the overwritten part of the 64 bit FPRs.
The mode of the FPU is determined by the ABI -- o32 programs use the
32-bit configuration (CP0.Status.FR set to 0) and n64/n32 programs use the
64-bit arrangement (CP0.Status.FR set to 1). That's already handled
correctly by the kernel, by configuring the FPU on a process-by-process
basis according to data obtained from the ELF file header of the
executable run.
Of course all double arithmetic would have to be handled by the emulator,
by trapping the Unimplemented Operation exception. This would clearly be
a new mode of operation and not supported out of the box with current
code as that would have to be tweaked to handle the case where only half
the register state is stored in hardware.
> 2. Some undefined instructions (e.g. c.eq.d) doesn't lead to an
> exception on an r5900, but have undefined behavior. So there is no
> emulation possible. It just calculates random stuff.
Oh well, that rules out any practical use of the FPU under Linux then.
> So the FPU needs to be disabled and completely emulated by the kernel,
> because then all FPU instructions lead to an exception. This is working
> with Linux 2.6 on PS2.
Naturally, as long as they got the Coprocessor Unusable exception right.
> There are even more problems when running unchanged code from official
> Fedora 12 on PS2, because of some different opcode encoding. The users
> of my PS2 Linux 2.6 complain about low speed, because many instructions
> are emulated. I need some fast implementation, even if the size of the
> floating point data types is smaller. So 32 bit FPU must be default for
> r5900.
That sounds weird -- why would anyone want to use a non-standard encoding
for any instructions? The base MIPS III 64-bit ISA was set as far back as
in 1991. Is R5900 documentation publicly available BTW?
Maciej
