Latest sources from CVS.

Latest sources from CVS.

[Carsten Langgaard]

I just checked the latest sources out of cvs.

It look like you are only able to compile the kernel, if you got a
MIPS32/MIPS64 compliant compiler.
The mips32 and mips64 assembler directives are set in
include/asm-mips/mipsregs.h

I guess this will make some people out there, which doesn't use a MIPS32
compliant compiler, a little bit unhappy.
But then again, we would like to force everybody to use the SDE
compiler.

/Carsten


--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com

Re: Latest sources from CVS.

[Kevin D. Kissell]

> I just checked the latest sources out of cvs.
> 
> It look like you are only able to compile the kernel, if you got a
> MIPS32/MIPS64 compliant compiler.
> The mips32 and mips64 assembler directives are set in
> include/asm-mips/mipsregs.h
> 
> I guess this will make some people out there, which doesn't use a MIPS32
> compliant compiler, a little bit unhappy.
> But then again, we would like to force everybody to use the SDE
> compiler.

For those on the list who don't understand Carsten's sense
of humour, I think that was missing a smiley!  ;-)
I mean, sure, we'd like to move more people toward SDE, 
but "force" is putting it a bit strongly!  And if those directives
are really being used unconditionally, I worry that the code
being generated is likewise emitting MIPS32 instructions
that won't work on the "ghost fleet" of abandoned workstations
now running Linux on R4K/R5K CPUs.

            Kevin K.

Re: Latest sources from CVS.

[Kevin D. Kissell]

> I just checked the latest sources out of cvs.
> 
> It look like you are only able to compile the kernel, if you got a
> MIPS32/MIPS64 compliant compiler.
> The mips32 and mips64 assembler directives are set in
> include/asm-mips/mipsregs.h
> 
> I guess this will make some people out there, which doesn't use a MIPS32
> compliant compiler, a little bit unhappy.
> But then again, we would like to force everybody to use the SDE
> compiler.

For those on the list who don't understand Carsten's sense
of humour, I think that was missing a smiley!  ;-)
I mean, sure, we'd like to move more people toward SDE, 
but "force" is putting it a bit strongly!  And if those directives
are really being used unconditionally, I worry that the code
being generated is likewise emitting MIPS32 instructions
that won't work on the "ghost fleet" of abandoned workstations
now running Linux on R4K/R5K CPUs.

            Kevin K.

Re: Latest sources from CVS.

[Ralf Baechle]

On Wed, Dec 04, 2002 at 10:09:54AM +0100, Kevin D. Kissell wrote:

> > It look like you are only able to compile the kernel, if you got a
> > MIPS32/MIPS64 compliant compiler.

Assembler.  I'm building with egcs 1.1.2 + binutils 1.13 btw.

> I mean, sure, we'd like to move more people toward SDE, 
> but "force" is putting it a bit strongly!  And if those directives
> are really being used unconditionally, I worry that the code
> being generated is likewise emitting MIPS32 instructions
> that won't work on the "ghost fleet" of abandoned workstations
> now running Linux on R4K/R5K CPUs.

It isn't.  We've been dragging around .word stuff in our code for years
and it was time to clean tht mess.  Further we had stuff like:

  read_32bit_cp0_register(CP0_STATUS)

which is a ridiculous long macro name for something that just expands
into a single machine instruction; the macro also didn't provide for
access to another cop0 register set than set 0.  For a few TLB-related
functions we already had functions with shorter names, so two names for
doing the one and same thing.  Another problem was that the name did
already hardcode the size of the access intothe code, so the user of
those macros had to know if it was 32-bit or 64-bit.  In short it was
time to clean the mess and as it seemed that pretty much everybody was
already having a MIPS32 / MIPS64 assembler, simply always emitting a
.set mips32 / .set mips64 seemed the right thing.  That's necessary even
for accessing cop0 set 0 because gas rejects something like

  mfc0 $2, $12, 0

unless running in MIPS32 or MIPS64 mode - even though the generated opcode
is perfectly valid for MIPS I.  The 64-bit kernel was another reason for
me to go with the assumption of rather current binutils - and I'd like
to make the same assumptions on tools versions for both 32-bit and 64-bit
versions.

Anyway, it seems that my assumptions about tools versions were a bit too
agressive, so I'm going to kludge things a bit for pre-MIPS32/MIPS64
assemblers.

Deprecating support for MIPS I - IV legacy CPUs is definately not something
I'd support.  Not before x86 has died out that is ;-)

  Ralf

Re: Latest sources from CVS.

[Ralf Baechle]

On Wed, Dec 04, 2002 at 10:09:54AM +0100, Kevin D. Kissell wrote:

> For those on the list who don't understand Carsten's sense
> of humour, I think that was missing a smiley!  ;-)
> I mean, sure, we'd like to move more people toward SDE, 
> but "force" is putting it a bit strongly!  And if those directives
> are really being used unconditionally, I worry that the code
> being generated is likewise emitting MIPS32 instructions
> that won't work on the "ghost fleet" of abandoned workstations
> now running Linux on R4K/R5K CPUs.

A fix is now in CVS.  With this fix only compiling a kernel for MIPS32
and MIPS64 CPUs will require a the new tools.

Everybody satisfied?

I was quite amazed how much email in just like 2 days this change was
producing, even people binutils 2.8 started yelling ...

  Ralf

Re: Latest sources from CVS.

[Carsten Langgaard]

Ralf Baechle wrote:

> On Wed, Dec 04, 2002 at 10:09:54AM +0100, Kevin D. Kissell wrote:
>
> > For those on the list who don't understand Carsten's sense
> > of humour, I think that was missing a smiley!  ;-)
> > I mean, sure, we'd like to move more people toward SDE,
> > but "force" is putting it a bit strongly!  And if those directives
> > are really being used unconditionally, I worry that the code
> > being generated is likewise emitting MIPS32 instructions
> > that won't work on the "ghost fleet" of abandoned workstations
> > now running Linux on R4K/R5K CPUs.
>
> A fix is now in CVS.  With this fix only compiling a kernel for MIPS32
> and MIPS64 CPUs will require a the new tools.
>
> Everybody satisfied?

Not quite, I afraid.
I would like to be able to compile a 64-bit kernel, using the
MIPS32/MIPS64 config1 register, but I don't have a MIPS64 compliant n64
compiler (assembler). So I need the hardcoded ".word" opcode version, we
previously had.

Something like this:

/*
 * This should be changed when we get a compiler that support the MIPS32
ISA.
 */
#define read_mips32_cp0_config1()                               \
({ int __res;                                                   \
        __asm__ __volatile__(                                   \
 ".set\tnoreorder\n\t"                                   \
 ".set\tnoat\n\t"                                        \
 "#.set\tmips64\n\t"     \
 "#mfc0\t$1, $16, 1\n\t"     \
 "#.set\tmips0\n\t"     \
      ".word\t0x40018001\n\t"                                 \
 "move\t%0,$1\n\t"                                       \
 ".set\tat\n\t"                                          \
 ".set\treorder"                                         \
 :"=r" (__res));                                         \
        __res;})


>
> I was quite amazed how much email in just like 2 days this change was
> producing, even people binutils 2.8 started yelling ...
>
>   Ralf

--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com

Re: Latest sources from CVS.

[Maciej W. Rozycki]

On Thu, 5 Dec 2002, Carsten Langgaard wrote:

> > Everybody satisfied?
> 
> Not quite, I afraid.
> I would like to be able to compile a 64-bit kernel, using the
> MIPS32/MIPS64 config1 register, but I don't have a MIPS64 compliant n64
> compiler (assembler). So I need the hardcoded ".word" opcode version, we
> previously had.

 Please upgrade/patch your tools.  If you can't, then this qualifies for a
privately maintained patch perfectly. 

 Support for MIPS32/MIPS64 was added to binutils two years ago.  Version
2.11 suffices. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Latest sources from CVS.

[Carsten Langgaard]

"Maciej W. Rozycki" wrote:

> On Thu, 5 Dec 2002, Carsten Langgaard wrote:
>
> > > Everybody satisfied?
> >
> > Not quite, I afraid.
> > I would like to be able to compile a 64-bit kernel, using the
> > MIPS32/MIPS64 config1 register, but I don't have a MIPS64 compliant n64
> > compiler (assembler). So I need the hardcoded ".word" opcode version, we
> > previously had.
>
>  Please upgrade/patch your tools.  If you can't, then this qualifies for a
> privately maintained patch perfectly.

I can live with that, already done.


>
>  Support for MIPS32/MIPS64 was added to binutils two years ago.  Version
> 2.11 suffices.
>

I just checked the FTP server for a new version
(ftp://ftp.linux-mips.org/pub/linux/mips/crossdev/i386-linux/), and someone
actually provided a
new set of binutils. It's less than a month ago (Nov 12), it was put there.
But if that works you won't hear more about it from my side ;-)

Thanks.
/Carsten



>
> --
> +  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
> +--------------------------------------------------------------+
> +        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com

Re: Latest sources from CVS.

[Ralf Baechle]

On Thu, Dec 05, 2002 at 03:12:00PM +0100, Carsten Langgaard wrote:

> >  Support for MIPS32/MIPS64 was added to binutils two years ago.  Version
> > 2.11 suffices.
> >
> 
> I just checked the FTP server for a new version
> (ftp://ftp.linux-mips.org/pub/linux/mips/crossdev/i386-linux/), and someone
> actually provided a
> new set of binutils. It's less than a month ago (Nov 12), it was put there.
> But if that works you won't hear more about it from my side ;-)

Excellent :-)

  Ralf

Re: Latest sources from CVS.

[Carsten Langgaard]

Carsten Langgaard wrote:

> "Maciej W. Rozycki" wrote:
>
> > On Thu, 5 Dec 2002, Carsten Langgaard wrote:
> >
> > > > Everybody satisfied?
> > >
> > > Not quite, I afraid.
> > > I would like to be able to compile a 64-bit kernel, using the
> > > MIPS32/MIPS64 config1 register, but I don't have a MIPS64 compliant n64
> > > compiler (assembler). So I need the hardcoded ".word" opcode version, we
> > > previously had.
> >
> >  Please upgrade/patch your tools.  If you can't, then this qualifies for a
> > privately maintained patch perfectly.
>
> I can live with that, already done.
>
> >
> >  Support for MIPS32/MIPS64 was added to binutils two years ago.  Version
> > 2.11 suffices.
> >
>
> I just checked the FTP server for a new version
> (ftp://ftp.linux-mips.org/pub/linux/mips/crossdev/i386-linux/), and someone
> actually provided a
> new set of binutils. It's less than a month ago (Nov 12), it was put there.
> But if that works you won't hear more about it from my side ;-)
>

I'm afraid I have to speak up again :-(
Although the new binutils (binutils-mips64el-linux-2.13.1-1.i386.rpm) work on
the latest sources from linux-mips.org, I have a problem with my local sources.

I get the following error from the assembler:


mips64el-linux-gcc -D__KERNEL__
-I/home/soc/proj/work/carstenl/linux-2.4.18/sw/linux-2.4.18/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
-fno-strict-aliasing -fno-common -I
/home/soc/proj/work/carstenl/linux-2.4.18/sw/linux-2.4.18/include/asm/gcc
-D__KERNEL__
-I/home/soc/proj/work/carstenl/linux-2.4.18/sw/linux-2.4.18/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
-fno-strict-aliasing -fno-common -mabi=64 -G 0 -mno-abicalls -fno-pic
-Wa,--trap -pipe -mcpu=r8000 -mips4 -Wa,-32   -DKBUILD_BASENAME=sched
-fno-omit-frame-pointer -c -o sched.o sched.c
{standard input}: Assembler messages:
{standard input}:329: Warning: dla used to load 32-bit register
{standard input}:382: Error: Number (0xffffffff) larger than 32 bits
{standard input}:408: Warning: dla used to load 32-bit register
{standard input}:431: Warning: dla used to load 32-bit register
{standard input}:541: Warning: dla used to load 32-bit register
{standard input}:542: Warning: dla used to load 32-bit register
{standard input}:554: Warning: dla used to load 32-bit register
{standard input}:557: Warning: dla used to load 32-bit register
{standard input}:558: Warning: dla used to load 32-bit register
{standard input}:567: Warning: dla used to load 32-bit register
{standard input}:569: Warning: dla used to load 32-bit register
{standard input}:570: Warning: dla used to load 32-bit register
{standard input}:581: Warning: dla used to load 32-bit register
{standard input}:824: Warning: dla used to load 32-bit register
{standard input}:847: Warning: dla used to load 32-bit register
{standard input}:848: Warning: dla used to load 32-bit register
{standard input}:884: Warning: dla used to load 32-bit register
{standard input}:885: Warning: dla used to load 32-bit register
{standard input}:898: Warning: dla used to load 32-bit register
{standard input}:1107: Warning: dla used to load 32-bit register
{standard input}:1251: Warning: dla used to load 32-bit register
{standard input}:1407: Warning: dla used to load 32-bit register
{standard input}:2017: Error: Number (0xffffffff) larger than 32 bits
{standard input}:2029: Error: Number (0x0) larger than 32 bits
{standard input}:2031: Error: Number (0xffffffff) larger than 32 bits
{standard input}:2082: Warning: dla used to load 32-bit register
{standard input}:2262: Warning: dla used to load 32-bit register
{standard input}:2393: Warning: dla used to load 32-bit register
{standard input}:2478: Warning: dla used to load 32-bit register
{standard input}:2517: Error: Number (0xffffffff) larger than 32 bits
{standard input}:2529: Error: Number (0x0) larger than 32 bits
{standard input}:2531: Error: Number (0xffffffff) larger than 32 bits
{standard input}:2635: Warning: dla used to load 32-bit register
{standard input}:2797: Warning: dla used to load 32-bit register
{standard input}:2885: Error: Number (0xffffffff) larger than 32 bits
{standard input}:2897: Error: Number (0x0) larger than 32 bits
{standard input}:2899: Error: Number (0xffffffff) larger than 32 bits
{standard input}:3030: Warning: dla used to load 32-bit register
{standard input}:3102: Warning: dla used to load 32-bit register
{standard input}:3113: Warning: dla used to load 32-bit register
{standard input}:3123: Warning: dla used to load 32-bit register
{standard input}:3134: Warning: dla used to load 32-bit register
{standard input}:3140: Warning: dla used to load 32-bit register
{standard input}:3164: Warning: dla used to load 32-bit register
{standard input}:3178: Warning: dla used to load 32-bit register
{standard input}:3194: Warning: dla used to load 32-bit register
{standard input}:3199: Warning: dla used to load 32-bit register
{standard input}:3215: Warning: dla used to load 32-bit register
{standard input}:3220: Warning: dla used to load 32-bit register
{standard input}:3236: Warning: dla used to load 32-bit register
{standard input}:3241: Warning: dla used to load 32-bit register
{standard input}:3244: Warning: dla used to load 32-bit register
{standard input}:3398: Warning: dla used to load 32-bit register
{standard input}:3408: Warning: dla used to load 32-bit register
{standard input}:3410: Warning: dla used to load 32-bit register
{standard input}:3412: Warning: dla used to load 32-bit register
{standard input}:3502: Warning: dla used to load 32-bit register
{standard input}:3532: Error: Number (0xffffffff) larger than 32 bits
{standard input}:3534: Warning: dla used to load 32-bit register
{standard input}:3596: Warning: dla used to load 32-bit register
{standard input}:3657: Warning: dla used to load 32-bit register
{standard input}:3658: Warning: dla used to load 32-bit register
{standard input}:3677: Warning: dla used to load 32-bit register
{standard input}:3708: Warning: dla used to load 32-bit register
{standard input}:3755: Warning: dla used to load 32-bit register
{standard input}:3757: Warning: dla used to load 32-bit register
{standard input}:3773: Warning: dla used to load 32-bit register
{standard input}:3781: Warning: dla used to load 32-bit register
{standard input}:3789: Warning: dla used to load 32-bit register
{standard input}:3849: Warning: dla used to load 32-bit register
make[2]: *** [sched.o] Error 1
make[2]: Leaving directory
`/home/soc/proj/work/carstenl/linux-2.4.18/sw/linux-2.4.18/kernel'
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory
`/home/soc/proj/work/carstenl/linux-2.4.18/sw/linux-2.4.18/kernel'
make: *** [_dir_kernel] Error 2


The old binutils (binutils-mips64el-linux-2.9.5-3.i386.rpm) worked fine.



>
> Thanks.
> /Carsten
>
> >
> > --
> > +  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
> > +--------------------------------------------------------------+
> > +        e-mail: macro@ds2.pg.gda.pl, PGP key available        +
>
> --
> _    _ ____  ___   Carsten Langgaard  Mailto:carstenl@mips.com
> |\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
> | \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
>   TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
>                    Denmark            http://www.mips.com

--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com

Re: Latest sources from CVS.

[Ralf Baechle]

On Fri, Dec 06, 2002 at 01:52:57PM +0100, Carsten Langgaard wrote:

> I'm afraid I have to speak up again :-(
> Although the new binutils (binutils-mips64el-linux-2.13.1-1.i386.rpm) work on
> the latest sources from linux-mips.org, I have a problem with my local sources.
> 
> I get the following error from the assembler:
> 
> 
> {standard input}: Assembler messages:
> {standard input}:329: Warning: dla used to load 32-bit register
> {standard input}:382: Error: Number (0xffffffff) larger than 32 bits
> {standard input}:408: Warning: dla used to load 32-bit register

These are caused by an !%$@#$!$ incompatible change in gas.  In essence
the code model we're using now requires to pass the additional option
-mgp64.  arch/mips64/Makefile probes for gas accepting this new option.

So standard advice, update your sources.

  Ralf

Re: Latest sources from CVS.

[Carsten Langgaard]

Ralf Baechle wrote:

> On Fri, Dec 06, 2002 at 01:52:57PM +0100, Carsten Langgaard wrote:
>
> > I'm afraid I have to speak up again :-(
> > Although the new binutils (binutils-mips64el-linux-2.13.1-1.i386.rpm) work on
> > the latest sources from linux-mips.org, I have a problem with my local sources.
> >
> > I get the following error from the assembler:
> >
> >
> > {standard input}: Assembler messages:
> > {standard input}:329: Warning: dla used to load 32-bit register
> > {standard input}:382: Error: Number (0xffffffff) larger than 32 bits
> > {standard input}:408: Warning: dla used to load 32-bit register
>
> These are caused by an !%$@#$!$ incompatible change in gas.  In essence
> the code model we're using now requires to pass the additional option
> -mgp64.  arch/mips64/Makefile probes for gas accepting this new option.
>

Thanks a lot.


>
> So standard advice, update your sources.

In order to have a stable kernel at all time (for core validation), we need to stay
away from the bleeding edge.
So our local sources will always be a little bit behind the main stream.
I have started to send my last patches to you, in order to get ready for a merge
with your latest 2.4.20 sources.


>
>   Ralf

--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com

Re: Latest sources from CVS.

[Thiemo Seufer]

Carsten Langgaard wrote:
[snip]
> I'm afraid I have to speak up again :-(
> Although the new binutils (binutils-mips64el-linux-2.13.1-1.i386.rpm) work on
> the latest sources from linux-mips.org, I have a problem with my local sources.
>
> I get the following error from the assembler:
> 
> 
> mips64el-linux-gcc -D__KERNEL__
> -I/home/soc/proj/work/carstenl/linux-2.4.18/sw/linux-2.4.18/include -Wall
> -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
> -fno-strict-aliasing -fno-common -I
> /home/soc/proj/work/carstenl/linux-2.4.18/sw/linux-2.4.18/include/asm/gcc
> -D__KERNEL__
> -I/home/soc/proj/work/carstenl/linux-2.4.18/sw/linux-2.4.18/include -Wall
> -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
> -fno-strict-aliasing -fno-common -mabi=64 -G 0 -mno-abicalls -fno-pic
> -Wa,--trap -pipe -mcpu=r8000 -mips4 -Wa,-32   -DKBUILD_BASENAME=sched
> -fno-omit-frame-pointer -c -o sched.o sched.c
> {standard input}: Assembler messages:
> {standard input}:329: Warning: dla used to load 32-bit register
> {standard input}:382: Error: Number (0xffffffff) larger than 32 bits

The new assembler does better checks for invalid opcodes.
Looks like your code misses some e.g.

	set .mips3

but wants to handle 64 bit quantities nevertheless.


Thiemo

Re: Latest sources from CVS.

[Thiemo Seufer]

Thiemo Seufer wrote:
> Carsten Langgaard wrote:
> [snip]
> > I'm afraid I have to speak up again :-(
> > Although the new binutils (binutils-mips64el-linux-2.13.1-1.i386.rpm) work on
> > the latest sources from linux-mips.org, I have a problem with my local sources.
> >
> > I get the following error from the assembler:
> > 
> > 
> > mips64el-linux-gcc -D__KERNEL__
> > -I/home/soc/proj/work/carstenl/linux-2.4.18/sw/linux-2.4.18/include -Wall
> > -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
> > -fno-strict-aliasing -fno-common -I
> > /home/soc/proj/work/carstenl/linux-2.4.18/sw/linux-2.4.18/include/asm/gcc
> > -D__KERNEL__
> > -I/home/soc/proj/work/carstenl/linux-2.4.18/sw/linux-2.4.18/include -Wall
> > -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
> > -fno-strict-aliasing -fno-common -mabi=64 -G 0 -mno-abicalls -fno-pic
                                     ^^^^^^^^
> > -Wa,--trap -pipe -mcpu=r8000 -mips4 -Wa,-32   -DKBUILD_BASENAME=sched
                                        ^^^^^^^
Then again, I missed you are building for a 64 bit kernel. The
commandline given advises the compiler to create N64 code, but
the assembler is forced to regard it as O32.

I guess the reason for this is the hack to pack 64 bit code in
O32 binaries.


Thiemo

Re: Latest sources from CVS.

[Carsten Langgaard]

Thiemo Seufer wrote:

> Thiemo Seufer wrote:
> > Carsten Langgaard wrote:
> > [snip]
> > > I'm afraid I have to speak up again :-(
> > > Although the new binutils (binutils-mips64el-linux-2.13.1-1.i386.rpm) work on
> > > the latest sources from linux-mips.org, I have a problem with my local sources.
> > >
> > > I get the following error from the assembler:
> > >
> > >
> > > mips64el-linux-gcc -D__KERNEL__
> > > -I/home/soc/proj/work/carstenl/linux-2.4.18/sw/linux-2.4.18/include -Wall
> > > -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
> > > -fno-strict-aliasing -fno-common -I
> > > /home/soc/proj/work/carstenl/linux-2.4.18/sw/linux-2.4.18/include/asm/gcc
> > > -D__KERNEL__
> > > -I/home/soc/proj/work/carstenl/linux-2.4.18/sw/linux-2.4.18/include -Wall
> > > -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
> > > -fno-strict-aliasing -fno-common -mabi=64 -G 0 -mno-abicalls -fno-pic
>                                      ^^^^^^^^
> > > -Wa,--trap -pipe -mcpu=r8000 -mips4 -Wa,-32   -DKBUILD_BASENAME=sched
>                                         ^^^^^^^
> Then again, I missed you are building for a 64 bit kernel. The
> commandline given advises the compiler to create N64 code, but
> the assembler is forced to regard it as O32.
>
> I guess the reason for this is the hack to pack 64 bit code in
> O32 binaries.
>

Exactly.
Note, Ralf has already identified the problem, please see his answer.
After hacking the Makefile (gas option), everything work fine.


>
> Thiemo

--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com

Re: Latest sources from CVS.

[Thiemo Seufer]

Carsten Langgaard wrote:
[snip]
> > > > -fno-strict-aliasing -fno-common -mabi=64 -G 0 -mno-abicalls -fno-pic
> >                                      ^^^^^^^^
> > > > -Wa,--trap -pipe -mcpu=r8000 -mips4 -Wa,-32   -DKBUILD_BASENAME=sched
> >                                         ^^^^^^^
> > Then again, I missed you are building for a 64 bit kernel. The
> > commandline given advises the compiler to create N64 code, but
> > the assembler is forced to regard it as O32.
> >
> > I guess the reason for this is the hack to pack 64 bit code in
> > O32 binaries.
> >
> 
> Exactly.
> Note, Ralf has already identified the problem, please see his answer.
> After hacking the Makefile (gas option), everything work fine.

Er, well, for some values of 'fine'. In principle, 64 bit code shouldn't
be disguised in O32 objects. OTOH i must admit it's a bit early to use
binutils N32 for this purpose.


Thiemo

Re: Latest sources from CVS.

[Maciej W. Rozycki]

On Fri, 6 Dec 2002, Thiemo Seufer wrote:

> Er, well, for some values of 'fine'. In principle, 64 bit code shouldn't
> be disguised in O32 objects. OTOH i must admit it's a bit early to use
> binutils N32 for this purpose.

 Which wouldn't work either as it implies 32-bit pointers, while gcc still
emits 64-bit assembly.  If we want to preserve the setup cleanly, we
probably need yet another ABI model in gcc (especially in the face of the
coming changes to get rid of assembly macros), with sign-extended 32-bit
pointers for accessing program segments and 64-bit ones for the remaining
addresses.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Latest sources from CVS.

[Thiemo Seufer]

Maciej W. Rozycki wrote:
> On Fri, 6 Dec 2002, Thiemo Seufer wrote:
> 
> > Er, well, for some values of 'fine'. In principle, 64 bit code shouldn't
> > be disguised in O32 objects. OTOH i must admit it's a bit early to use
> > binutils N32 for this purpose.
> 
>  Which wouldn't work either as it implies 32-bit pointers, while gcc still
> emits 64-bit assembly.

Which should be enough for smaller address spaces.

> If we want to preserve the setup cleanly, we
> probably need yet another ABI model in gcc (especially in the face of the
> coming changes to get rid of assembly macros), with sign-extended 32-bit
> pointers for accessing program segments and 64-bit ones for the remaining
> addresses.

Do you think this is worth the hassle? N64 offers better flexibility in
the large memory case at some performance cost, and it's conceptionally
cleaner.


Thiemo

Re: Latest sources from CVS.

[Maciej W. Rozycki]

On Fri, 6 Dec 2002, Thiemo Seufer wrote:

> >  Which wouldn't work either as it implies 32-bit pointers, while gcc still
> > emits 64-bit assembly.
> 
> Which should be enough for smaller address spaces.

 But gas will complain of the same address truncation as for o32. 

> > If we want to preserve the setup cleanly, we
> > probably need yet another ABI model in gcc (especially in the face of the
> > coming changes to get rid of assembly macros), with sign-extended 32-bit
> > pointers for accessing program segments and 64-bit ones for the remaining
> > addresses.
> 
> Do you think this is worth the hassle? N64 offers better flexibility in
> the large memory case at some performance cost, and it's conceptionally
> cleaner.

 Remember we are writing of the kernel -- we don't know what userland is
going to bring us -- a user pointer need not fit in 32 bits.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Latest sources from CVS.

[Thiemo Seufer]

Maciej W. Rozycki wrote:
> On Fri, 6 Dec 2002, Thiemo Seufer wrote:
> 
> > >  Which wouldn't work either as it implies 32-bit pointers, while gcc still
> > > emits 64-bit assembly.
> > 
> > Which should be enough for smaller address spaces.
> 
>  But gas will complain of the same address truncation as for o32. 

Maybe I wasn't clear about it, I meant kernels with 32 bit address
space but 64 bit register width, allowing for userland N32 ABI.

E.g. the old DECstations with R4k CPU and limited memory would fit
in this scheme. :-)

> > > If we want to preserve the setup cleanly, we
> > > probably need yet another ABI model in gcc (especially in the face of the
> > > coming changes to get rid of assembly macros), with sign-extended 32-bit
> > > pointers for accessing program segments and 64-bit ones for the remaining
> > > addresses.
> > 
> > Do you think this is worth the hassle? N64 offers better flexibility in
> > the large memory case at some performance cost, and it's conceptionally
> > cleaner.
> 
>  Remember we are writing of the kernel -- we don't know what userland is
> going to bring us

I don't understand this. The kernel _defines_ what the userland is allowed
to do.

> -- a user pointer need not fit in 32 bits.

It needs to, if the kernel doesn't want to support 64 bit address space. :-)


Thiemo

Re: Latest sources from CVS.

[Ralf Baechle]

On Fri, Dec 06, 2002 at 06:24:38PM +0100, Thiemo Seufer wrote:

> Maybe I wasn't clear about it, I meant kernels with 32 bit address
> space but 64 bit register width, allowing for userland N32 ABI.
> 
> E.g. the old DECstations with R4k CPU and limited memory would fit
> in this scheme. :-)

I'm considering kernels with just 2-level page tables as a step into that
direction.  With 16kB pages that permits for 64GB of virtual address
space, with 4kB pages; with a bit of tweaking we should be able to
maintain the ability to map 2GB in the userspace.

  Ralf

Re: Latest sources from CVS.

[Maciej W. Rozycki]

On Fri, 6 Dec 2002, Thiemo Seufer wrote:

> Maybe I wasn't clear about it, I meant kernels with 32 bit address
> space but 64 bit register width, allowing for userland N32 ABI.
> 
> E.g. the old DECstations with R4k CPU and limited memory would fit
> in this scheme. :-)

 I'm only going to support n64 on the DECstation.  You are welcomed to do
n32 stuff yourself if you want to. 

> >  Remember we are writing of the kernel -- we don't know what userland is
> > going to bring us
> 
> I don't understand this. The kernel _defines_ what the userland is allowed
> to do.

 I haven't considered you may mean crippling the available user address
space.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Latest sources from CVS.

[Thiemo Seufer]

Maciej W. Rozycki wrote:
> On Fri, 6 Dec 2002, Thiemo Seufer wrote:
> 
> > Maybe I wasn't clear about it, I meant kernels with 32 bit address
> > space but 64 bit register width, allowing for userland N32 ABI.
> > 
> > E.g. the old DECstations with R4k CPU and limited memory would fit
> > in this scheme. :-)
> 
>  I'm only going to support n64 on the DECstation.  You are welcomed to do
> n32 stuff yourself if you want to. 

What does N64 on the DECstation better than N32 could do? N32 has
more compact code, better cache usage and less memory consumption.

> > >  Remember we are writing of the kernel -- we don't know what userland is
> > > going to bring us
> > 
> > I don't understand this. The kernel _defines_ what the userland is allowed
> > to do.
> 
>  I haven't considered you may mean crippling the available user address
> space.

IIRC is the maximum of RAM 448 MB on some machines. Actually utilizing
an user address space larger than 2 GB would mean a RAM/Swap ratio of
about 1:4, IOW, it likely gets unusable slow.

Is there any point besides of hack value to use N64 on these machines?


Thiemo

Re: Latest sources from CVS.

[Maciej W. Rozycki]

On Fri, 6 Dec 2002, Thiemo Seufer wrote:

> >  I'm only going to support n64 on the DECstation.  You are welcomed to do
> > n32 stuff yourself if you want to. 
> 
> What does N64 on the DECstation better than N32 could do? N32 has
> more compact code, better cache usage and less memory consumption.

 Well, as you probably noticed, the DECstation is not a performance
screamer anymore.  If I needed a fast system, I'd use something else.  I
need a reference platform, though, even if it costs performance.

> >  I haven't considered you may mean crippling the available user address
> > space.
> 
> IIRC is the maximum of RAM 448 MB on some machines. Actually utilizing

 For the record, it's 480MB, actually (15 * 32MB). 

> an user address space larger than 2 GB would mean a RAM/Swap ratio of
> about 1:4, IOW, it likely gets unusable slow.

 That depends on the utility of swap -- it's usually slow, although not
always. 

> Is there any point besides of hack value to use N64 on these machines?

 Probably not.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Latest sources from CVS.

[Ralf Baechle]

On Fri, Dec 06, 2002 at 05:45:58PM +0100, Thiemo Seufer wrote:

> > If we want to preserve the setup cleanly, we
> > probably need yet another ABI model in gcc (especially in the face of the
> > coming changes to get rid of assembly macros), with sign-extended 32-bit
> > pointers for accessing program segments and 64-bit ones for the remaining
> > addresses.
> 
> Do you think this is worth the hassle? N64 offers better flexibility in
> the large memory case at some performance cost, and it's conceptionally
> cleaner.

Absolutely:

[ralf@dea linux-sgi-2.4]$ mips64-linux-size vmlinux
   text    data     bss     dec     hex filename
1978296  317344  156224 2451864  256998 vmlinux
[ralf@dea linux-sgi-2.4]$ mips64-linux-size vmlinux
   text    data     bss     dec     hex filename
1761168  317344  156224 2234736  221970 vmlinux

The first kernel was built as 64-bit ELF using 64-bit pointer and everything
64-bit.  The second kernel was built using the -Wa,-32 trick.  That's over
12% of bloat for full 64-bitiness which brings zero gain.

  Ralf

Re: Latest sources from CVS.

[Thiemo Seufer]

Ralf Baechle wrote:
> On Fri, Dec 06, 2002 at 05:45:58PM +0100, Thiemo Seufer wrote:
> 
> > > If we want to preserve the setup cleanly, we
> > > probably need yet another ABI model in gcc (especially in the face of the
> > > coming changes to get rid of assembly macros), with sign-extended 32-bit
> > > pointers for accessing program segments and 64-bit ones for the remaining
> > > addresses.
> > 
> > Do you think this is worth the hassle? N64 offers better flexibility in
> > the large memory case at some performance cost, and it's conceptionally
> > cleaner.
> 
> Absolutely:
> 
> [ralf@dea linux-sgi-2.4]$ mips64-linux-size vmlinux
>    text    data     bss     dec     hex filename
> 1978296  317344  156224 2451864  256998 vmlinux
> [ralf@dea linux-sgi-2.4]$ mips64-linux-size vmlinux
>    text    data     bss     dec     hex filename
> 1761168  317344  156224 2234736  221970 vmlinux
> 
> The first kernel was built as 64-bit ELF using 64-bit pointer and everything
> 64-bit.  The second kernel was built using the -Wa,-32 trick.  That's over
> 12% of bloat for full 64-bitiness which brings zero gain.

I found that in the first case the text segment of my linux kernels
has trailing garbage in it, which can explain most of the difference.

I haven't looked into it yet, it seems to be harmless besides of
increasing file and memory size.

Could you have a look at the disassembly, I guess your kernels suffer
the same effect.


Thiemo

Re: Latest sources from CVS.

[Greg Lindahl]

On Fri, Dec 06, 2002 at 06:02:41PM +0100, Ralf Baechle wrote:

> The first kernel was built as 64-bit ELF using 64-bit pointer and everything
> 64-bit.  The second kernel was built using the -Wa,-32 trick.  That's over
> 12% of bloat for full 64-bitiness which brings zero gain.

Yes, but that 12% overhead will be reduced when gcc stops using those
crappy macros for everything, and finds some common subexpressions.

-- greg

Re: Latest sources from CVS.

[Dominic Sweetman]

Ralf Baechle (ralf@linux-mips.org) writes:

> Absolutely:
> 
> [ralf@dea linux-sgi-2.4]$ mips64-linux-size vmlinux
>    text    data     bss     dec     hex filename
> 1978296  317344  156224 2451864  256998 vmlinux
> [ralf@dea linux-sgi-2.4]$ mips64-linux-size vmlinux
>    text    data     bss     dec     hex filename
> 1761168  317344  156224 2234736  221970 vmlinux
> 
> The first kernel was built as 64-bit ELF using 64-bit pointer and everything
> 64-bit.  The second kernel was built using the -Wa,-32 trick.  That's over
> 12% of bloat for full 64-bitiness which brings zero gain.

Percentages are dangerous things.  This is 220Kbytes of memory, which
currently represents an investment of about $0.05.  There may be
embedded linux applications which care about 5c cost, but they
probably won't use any variety of 64 bits...

Re: Latest sources from CVS.

[Greg Lindahl]

On Fri, Dec 06, 2002 at 06:18:22PM +0000, Dominic Sweetman wrote:

> Percentages are dangerous things.  This is 220Kbytes of memory, which
> currently represents an investment of about $0.05.  There may be
> embedded linux applications which care about 5c cost, but they
> probably won't use any variety of 64 bits...

It's not the 5 cents, it's the slowdown of executing extra code.

-- greg

Re: Latest sources from CVS.

[Ralf Baechle]

On Fri, Dec 06, 2002 at 06:18:22PM +0000, Dominic Sweetman wrote:

> > The first kernel was built as 64-bit ELF using 64-bit pointer and everything
> > 64-bit.  The second kernel was built using the -Wa,-32 trick.  That's over
> > 12% of bloat for full 64-bitiness which brings zero gain.
> 
> Percentages are dangerous things.  This is 220Kbytes of memory, which
> currently represents an investment of about $0.05.  There may be
> embedded linux applications which care about 5c cost, but they
> probably won't use any variety of 64 bits...

I'd worry less if that was just 220kB of unused memory wasted.  But it's
actually inflated code, it's wasted i-cache and cycles.  220kB translates
to alost 7 times the size of today's typical 32kB i-cache.

Even if Thiemo was right this trick is probably the biggest micro-
optimization of the decade ...

  Ralf

Re: Latest sources from CVS.

[Thiemo Seufer]

Ralf Baechle wrote:
> On Fri, Dec 06, 2002 at 06:18:22PM +0000, Dominic Sweetman wrote:
> 
> > > The first kernel was built as 64-bit ELF using 64-bit pointer and everything
> > > 64-bit.  The second kernel was built using the -Wa,-32 trick.  That's over
> > > 12% of bloat for full 64-bitiness which brings zero gain.
> > 
> > Percentages are dangerous things.  This is 220Kbytes of memory, which
> > currently represents an investment of about $0.05.  There may be
> > embedded linux applications which care about 5c cost, but they
> > probably won't use any variety of 64 bits...
> 
> I'd worry less if that was just 220kB of unused memory wasted.  But it's
> actually inflated code, it's wasted i-cache and cycles.  220kB translates
> to alost 7 times the size of today's typical 32kB i-cache.
> 
> Even if Thiemo was right this trick is probably the biggest micro-
> optimization of the decade ...

Even if it was such a big win it would IMHO be better to use N64 and
teach the assembler some optimization for such register loads.
-Wa,--sign-extend-immediates shouldn't be that complicated to implement.


Thiemo

Re: Latest sources from CVS.

[Ralf Baechle]

On Sat, Dec 07, 2002 at 12:33:37AM +0100, Thiemo Seufer wrote:

> > I'd worry less if that was just 220kB of unused memory wasted.  But it's
> > actually inflated code, it's wasted i-cache and cycles.  220kB translates
> > to alost 7 times the size of today's typical 32kB i-cache.
> > 
> > Even if Thiemo was right this trick is probably the biggest micro-
> > optimization of the decade ...
> 
> Even if it was such a big win it would IMHO be better to use N64 and
> teach the assembler some optimization for such register loads.
> -Wa,--sign-extend-immediates shouldn't be that complicated to implement.

The entire situation will change anyway once gcc no longer emits macro
instructions such as la or dla.

  Ralf