Jürgen Urban writes:
> Am 25.06.2013 um 23:24 schrieb Richard Sandiford :
>> Jürgen Urban writes:
>>> Am 23.06.2013 um 22:21 schrieb Richard Sandiford
Do you want to stick with 128-bit long doubles for PS2, or would you
prefer to do what SDE does?
>>>
>>> I prefer shorter long doubles
Hello Richard,
Am 25.06.2013 um 23:24 schrieb Richard Sandiford :
> Jürgen Urban writes:
>> Am 23.06.2013 um 22:21 schrieb Richard Sandiford
>> :
In the native PS2SDK (i.e. no Linux) I detected that there are undefined
references to `__fixtfsi', `__floatsitf', `__subtf3', `__multf3',
Jürgen Urban writes:
> Am 23.06.2013 um 22:21 schrieb Richard Sandiford :
>>> In the native PS2SDK (i.e. no Linux) I detected that there are undefined
>>> references to `__fixtfsi', `__floatsitf', `__subtf3', `__multf3',
>>> __extenddftf2', `__lttf2' and `__gttf2'. These are the functions for
>>>
Hello Richard,
Am 23.06.2013 um 22:21 schrieb Richard Sandiford :
> "Jürgen Urban" writes:
>>
>> In the native PS2SDK (i.e. no Linux) I detected that there are undefined
>> references to `__fixtfsi', `__floatsitf', `__subtf3', `__multf3',
>> __extenddftf2', `__lttf2' and `__gttf2'. These are th
"Jürgen Urban" writes:
> Hello Richard,
>
>> >> Does it still work with those changes, as below? If so, I'll check it in.
>> >
>> > I tested it. It is still working. So the patch is OK, please check it in.
>>
>> OK, I've applied this and the config.gcc patch.
>
> Thanks.
>
> In the native PS2SDK
Hello Richard,
> >> Does it still work with those changes, as below? If so, I'll check it in.
> >
> > I tested it. It is still working. So the patch is OK, please check it in.
>
> OK, I've applied this and the config.gcc patch.
Thanks.
In the native PS2SDK (i.e. no Linux) I detected that there
"Jürgen Urban" writes:
>> Does it still work with those changes, as below? If so, I'll check it in.
>
> I tested it. It is still working. So the patch is OK, please check it in.
OK, I've applied this and the config.gcc patch.
Thanks,
Richard
Hello Richard,
> > The code is now completely moved into libgcc/config/mips/t-mips and
> > libgcc/config/mips/lib2funcs.c (new file).
> > The code should now be easier to understand.
> > I used the code from libgcc/config/m32c as example (e.g. same file name
> > lib2funcs.c). I copied the file hea
"Jürgen Urban" writes:
>> Richard Sandiford writes:
>>
>> > I can't approve the Makefile.in bits. I've cc'ed Ian, who's the libgcc
>> > maintainer. Ian: the problem is that "_muldi3.o" on 64-bit targets
>> > is actually an implementation of __multi3. Jürgen wants to have a
>> > __muldi3 too, w
On Fri, Jun 14, 2013 at 11:48 AM, "Jürgen Urban" wrote:
> Hello Richard,
>
> I updated the patch as requested.
>
>> Richard Sandiford writes:
>>
>> > I can't approve the Makefile.in bits. I've cc'ed Ian, who's the libgcc
>> > maintainer. Ian: the problem is that "_muldi3.o" on 64-bit targets
>>
Hello Richard,
I updated the patch as requested.
> Richard Sandiford writes:
>
> > I can't approve the Makefile.in bits. I've cc'ed Ian, who's the libgcc
> > maintainer. Ian: the problem is that "_muldi3.o" on 64-bit targets
> > is actually an implementation of __multi3. Jürgen wants to have
Richard Sandiford writes:
> I can't approve the Makefile.in bits. I've cc'ed Ian, who's the libgcc
> maintainer. Ian: the problem is that "_muldi3.o" on 64-bit targets
> is actually an implementation of __multi3. Jürgen wants to have a
> __muldi3 too, with the same implementation as on 32-bit
"Jürgen Urban" writes:
>> > How much other changes will be currently accepted here? There is other
>> > stuff which I want to prepare and submit here, e.g.:
>> > 1. disable use of dmult and ddiv (ABI n32).
>> > 2. use trunc.w.s instead of cvt.w.s (to get single float working for
>> > normal range
Hello Richard,
> > How much other changes will be currently accepted here? There is other
> > stuff which I want to prepare and submit here, e.g.:
> > 1. disable use of dmult and ddiv (ABI n32).
> > 2. use trunc.w.s instead of cvt.w.s (to get single float working for
> > normal range calculations;
"Jürgen Urban" writes:
> Hello Richard,
>
>> Thanks, looks good. The comments I have are only minor and seemed easier
>> to spell out as a revised patch, attached below. The changes are:
>>
>> * removing the config.sub bit, which looked redundant. We already have
>> the up-to-date upstream co
Hello Richard,
> Thanks, looks good. The comments I have are only minor and seemed easier
> to spell out as a revised patch, attached below. The changes are:
>
> * removing the config.sub bit, which looked redundant. We already have
> the up-to-date upstream config.sub.
>
> * removing the tar
"Jürgen Urban" writes:
> after some months I reworked the patch for r5900. It would be nice if
> this could be accepted. The patch contains only changes to get basic
> support for MIPS r5900. It can be used to compile a working Linux kernel
> for the Playstation 2. It i
On 06/02/2013 01:45 PM, "Jürgen Urban" wrote:
Hello,
after some months I reworked the patch for r5900. It would be nice if this
could be accepted. The patch contains only changes to get basic support for
MIPS r5900. It can be used to compile a working Linux kernel for the
Playsta
Hello,
after some months I reworked the patch for r5900. It would be nice if this
could be accepted. The patch contains only changes to get basic support for
MIPS r5900. It can be used to compile a working Linux kernel for the
Playstation 2. It is also possible to get Linux programs working
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
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 instructions which is good to find
errors in the GCC
45 matches
Mail list logo
