Hello Richard,
Am 25.06.2013 um 23:24 schrieb Richard Sandiford rdsandif...@googlemail.com:
Jürgen Urban juergenur...@gmx.de writes:
Am 23.06.2013 um 22:21 schrieb Richard Sandiford
rdsandif...@googlemail.com:
In the native PS2SDK (i.e. no Linux) I detected that there are undefined
Jürgen Urban juergenur...@gmx.de writes:
Am 25.06.2013 um 23:24 schrieb Richard Sandiford rdsandif...@googlemail.com:
Jürgen Urban juergenur...@gmx.de 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
Jürgen Urban juergenur...@gmx.de writes:
Am 23.06.2013 um 22:21 schrieb Richard Sandiford rdsandif...@googlemail.com:
In the native PS2SDK (i.e. no Linux) I detected that there are undefined
references to `__fixtfsi', `__floatsitf', `__subtf3', `__multf3',
__extenddftf2', `__lttf2' and
Hello Richard,
Am 23.06.2013 um 22:21 schrieb Richard Sandiford rdsandif...@googlemail.com:
Jürgen Urban juergenur...@gmx.de writes:
In the native PS2SDK (i.e. no Linux) I detected that there are undefined
references to `__fixtfsi', `__floatsitf', `__subtf3', `__multf3',
__extenddftf2',
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 are
Jürgen Urban juergenur...@gmx.de 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,
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 header
Jürgen Urban juergenur...@gmx.de 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
Jürgen Urban juergenur...@gmx.de writes:
Richard Sandiford rdsandif...@googlemail.com 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
Hello Richard,
I updated the patch as requested.
Richard Sandiford rdsandif...@googlemail.com 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.
On Fri, Jun 14, 2013 at 11:48 AM, Jürgen Urban juergenur...@gmx.de wrote:
Hello Richard,
I updated the patch as requested.
Richard Sandiford rdsandif...@googlemail.com writes:
I can't approve the Makefile.in bits. I've cc'ed Ian, who's the libgcc
maintainer. Ian: the problem is that
Richard Sandiford rdsandif...@googlemail.com 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
Jürgen Urban juergenur...@gmx.de 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
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; i.e.
Jürgen Urban juergenur...@gmx.de 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
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
Playstation 2
Jürgen Urban juergenur...@gmx.de 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 is also
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
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.00
Maciej W. Rozycki ma...@codesourcery.com 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
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 fix up glibc
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 you've
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 would work. I
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
Maciej W. Rozycki ma...@codesourcery.com 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
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 _I_
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 from
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,
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
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 double multiplication).
Maciej W. Rozycki ma...@codesourcery.com 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
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 instructions by
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 attention -- AFAICS
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). Disabling
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
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
Jeff Law l...@redhat.com 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
Jürgen Urban juergenur...@gmx.de 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
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 has raised
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). So
Richard Sandiford rdsandif...@googlemail.com writes:
Jürgen Urban juergenur...@gmx.de 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
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
43 matches
Mail list logo
