Hello Maciej,
> > I tested the calculation with the type "float".
> > ABI o32 with -mhard-float and -msingle-float produces the following
> results:
> > 1.00 (0x3f80) / 0.00 (0x) = nan (0x7fff)
> > 0.00 (0x) / 0.00 (0x) = nan (0x7fff)
> > 0.0
"Maciej W. Rozycki" writes:
>> I tested the calculation with the type "float".
>> ABI o32 with -mhard-float and -msingle-float produces the following results:
>> 1.00 (0x3f80) / 0.00 (0x) = nan (0x7fff)
>> 0.00 (0x) / 0.00 (0x) = nan (0x7fff)
>>
Hi Jürgen,
> > Glibc uses them exactly where it uses 32-bit LL/SC, except where a 64-bit
> > data type is involved. Of course that also requires a 64-bit ABI, either
> > n64 or n32, as these are 64-bit instructions -- from what you wrote thus
> > far I've gathered, perhaps incorrectly, that yo
Hello Maciej,
> > > 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 fi
Hi Jürgen,
> > 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:
> >
> > .setmips2
> > ll $2, ($3)
> >
> > assembles correctly with -march=r5900?
>
> This seems to work. I didn't know that this wo
Hello Maciej,
> 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:
>
> .setmips2
> ll $2, ($3)
>
> assembles correctly with -march=r5900?
This seems to work. I didn't know that this would work. I
On Fri, 11 Jan 2013, Richard Sandiford wrote:
> BTW Maciej, sorry to be prickly about this, but: where I live, "I insist"
> has a very domineering ring to it, at least in this kind of context.
> The implication tends to be that "having insisted, I really expect it to
> happen, simply because it is
"Maciej W. Rozycki" writes:
> And in any case I insist that the instructions are correctly marked in
> the opcode table.
I agree that it would be better to exclude the unimplemented instructions.
Jürgen: if you're happy to submit a patch along those lines, I promise
to review it.
BTW Maciej, s
On 01/10/2013 03:58 PM, "Jürgen Urban" wrote:
Hello Jeff,
If you're using something from the Cygnus port, then it would be covered
by the blanket copyright assignment Cygnus had in place with the FSF.
If there are any doubts about the origin of a hunk of GCC code I could
probably pull out the o
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 sho
Hello Jeff,
> If you're using something from the Cygnus port, then it would be covered
> by the blanket copyright assignment Cygnus had in place with the FSF.
> If there are any doubts about the origin of a hunk of GCC code I could
> probably pull out the old sources to determine if it came fro
On 01/08/2013 03:49 PM, "Jürgen Urban" wrote:
@Jeff: I think you know the stringent copyright rules for GCC. I want
to use the code from the original patch, but I don't know how many
people were involved. So I can't use it without copyright problems.
Can you please tell me which code can I use w
> > IIRC we defined doubles as 32bits wide in our old port. We simply
> > didn't support 64bit wide doubles. I don't remember what mechanism we
> > used to make this happen.
>
> Ah, yeah.
I think limiting wide doubles would be good.
> >>> I tried to disable dmult and ddiv (see mips.md). Disa
Hello Maciej,
> > > 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 atte
Hello Richard,
> > 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.
trunc.w.s is enabled by ISA_HAS_TRUNC_W_S. This automatically disables cvt.w.s,
because trunc.w.s is preferred.
> > I disabled 64 bit FPU instructio
"Maciej W. Rozycki" writes:
> On Tue, 8 Jan 2013, Richard Sandiford wrote:
>> >> > I disabled 64 bit FPU instructions by "-msoft-float". This works, but
>> >> > using "-msingle-float" fails. This would be the better
>> >> > configuration. There are still 64 bit FPU instructions used (e.g. "dmfc1
>
On Tue, 8 Jan 2013, Richard Sandiford wrote:
> >> > I disabled 64 bit FPU instructions by "-msoft-float". This works, but
> >> > using "-msingle-float" fails. This would be the better
> >> > configuration. There are still 64 bit FPU instructions used (e.g. "dmfc1
> >> > $2,$f0" when using "long do
"Maciej W. Rozycki" writes:
>> > I disabled 64 bit FPU instructions by "-msoft-float". This works, but
>> > using "-msingle-float" fails. This would be the better
>> > configuration. There are still 64 bit FPU instructions used (e.g. "dmfc1
>> > $2,$f0" when using "long double" multiplication). So
Jeff Law writes:
> On 01/07/2013 02:52 PM, Richard Sandiford wrote:
>
>>> I disabled 64 bit FPU instructions by "-msoft-float". This works, but
>>> using "-msingle-float" fails. This would be the better
>>> configuration. There are still 64 bit FPU instructions used (e.g. "dmfc1
>>> $2,$f0" when u
Richard Sandiford writes:
> "Jürgen Urban" writes:
>> 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.
Maci
On 01/07/2013 02:52 PM, Richard Sandiford wrote:
I disabled 64 bit FPU instructions by "-msoft-float". This works, but
using "-msingle-float" fails. This would be the better
configuration. There are still 64 bit FPU instructions used (e.g. "dmfc1
$2,$f0" when using "long double" multiplication).
On Mon, 7 Jan 2013, Richard Sandiford wrote:
> > 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 h
"Jürgen Urban" writes:
> 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.
> I disabled 64 bit FPU instructions by
Jeff Law writes:
> On 01/06/2013 03:56 PM, "Jürgen Urban" wrote:
>> Hello,
>>
>> I created a patch from scratch to support MIPS r5900 used in the
>> Playstation 2, but I have some problems with it. The attached patch
>> only works with the latest binutils from CVS. The binutils forces the
>> compi
On 01/06/2013 03:56 PM, "Jürgen Urban" wrote:
Hello,
I created a patch from scratch to support MIPS r5900 used in the
Playstation 2, but I have some problems with it. The attached patch
only works with the latest binutils from CVS. The binutils forces the
compiler to use r5900 compatible instruc
25 matches
Mail list logo
