Latest sources from CVS.
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:[email protected] |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com
Quoted 11 lines
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 ininclude/asm-mips/mipsregs.hI 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.
Quoted 2 lines · Kevin D. Kissell
Quoted 2 lines
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.
Quoted 6 lines
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
Quoted 8 lines · Kevin D. Kissell
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
Quoted 11 lines · Ralf Baechle
Quoted 8 lines · Kevin D. Kissell
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.
Quoted 4 lines
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;})Quoted 5 lines
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:[email protected] |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com
Quoted 7 lines · Carsten Langgaard
Quoted 1 line
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.
Signature · 3 lines
+ Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: [email protected], PGP key available +
Quoted 4 lines · Maciej W. Rozycki
Quoted 2 lines · Carsten Langgaard
Quoted 1 line
Everybody satisfied?
Quoted 8 lines
Quoted 5 lines
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.
Quoted 4 lines
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
Review
Quoted 5 lines
--
(quoted diff) +3
-0+ Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: [email protected], PGP key available +
--
_ _ ____ ___ Carsten Langgaard Mailto:[email protected] |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com
Quoted 9 lines · Carsten Langgaard
Quoted 3 lines
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
Quoted 22 lines · Carsten Langgaard
Quoted 4 lines · Maciej W. Rozycki
Quoted 2 lines · Carsten Langgaard
Quoted 1 line
Everybody satisfied?
Quoted 8 lines
Quoted 5 lines
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.
Quoted 4 lines
Support for MIPS32/MIPS64 was added to binutils two years ago. Version
2.11 suffices.
Quoted 6 lines
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.
Quoted 10 lines
Thanks.
/CarstenReview
Quoted 5 lines
--
(quoted diff) +3
-0+ Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: [email protected], PGP key available +
Quoted 6 lines
--
_ _ ____ ___ Carsten Langgaard Mailto:[email protected] |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556Denmark http://www.mips.com
--
_ _ ____ ___ Carsten Langgaard Mailto:[email protected] |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com
Quoted 11 lines · Carsten Langgaard
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
Quoted 9 lines · Ralf Baechle
Quoted 7 lines · Carsten Langgaard
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:
Quoted 9 lines
Quoted 4 lines
{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 registerThese 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/Makefileprobes for gas accepting this new option.
Thanks a lot.
Quoted 2 lines
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.
Quoted 2 lines
Ralf
--
_ _ ____ ___ Carsten Langgaard Mailto:[email protected] |\ /|||___)(___ 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 wrote:
[snip]
Quoted 18 lines
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__
(quoted diff) +0
-3-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(quoted diff) +0
-6-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
Quoted 3 lines
{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
Quoted 9 lines · Thiemo Seufer
Carsten Langgaard wrote:
[snip]Quoted 7 lines
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:
Quoted 9 lines
Review
Quoted 9 lines
mips64el-linux-gcc -D__KERNEL__
(quoted diff) +0
-3-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(quoted diff) +0
-4-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
^^^^^^^^
Quoted 1 line
Quoted 1 line
-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
Quoted 20 lines · Thiemo Seufer
Quoted 9 lines · Thiemo Seufer
Carsten Langgaard wrote:
[snip]Quoted 7 lines
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:
Quoted 9 lines
Review
Quoted 9 lines
mips64el-linux-gcc -D__KERNEL__
(quoted diff) +0
-3-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(quoted diff) +0
-4-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^^^^^^^^
Quoted 9 lines
Quoted 1 line
Quoted 1 line
-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.
Quoted 2 lines
Thiemo
--
_ _ ____ ___ Carsten Langgaard Mailto:[email protected] |\ /|||___)(___ 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 wrote:
[snip]
Quoted 8 lines
Quoted 8 lines
Quoted 1 line
Quoted 1 line
-fno-strict-aliasing -fno-common -mabi=64 -G 0 -mno-abicalls -fno-pic
^^^^^^^^Quoted 1 line
Quoted 1 line
-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.
Quoted 7 lines
Quoted 3 lines
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 theMakefile(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
Quoted 3 lines · Thiemo Seufer
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.
Signature · 3 lines
+ Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: [email protected], PGP key available +
Quoted 8 lines · Maciej W. Rozycki
Quoted 3 lines · Thiemo Seufer
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.
Quoted 5 lines
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
Quoted 9 lines · Thiemo Seufer
Quoted 5 lines
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
Quoted 21 lines · Ralf Baechle
Quoted 9 lines · Thiemo Seufer
Quoted 5 lines
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
Quoted 3 lines
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
Quoted 3 lines · Ralf Baechle
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
Quoted 9 lines · Ralf Baechle
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
Quoted 3 lines
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...
Quoted 4 lines · Dominic Sweetman
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
Quoted 8 lines · Dominic Sweetman
Quoted 3 lines
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
Quoted 11 lines · Ralf Baechle
Quoted 8 lines · Dominic Sweetman
Quoted 3 lines
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...
Quoted 6 lines
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
Quoted 10 lines · Thiemo Seufer
Quoted 6 lines
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
Quoted 4 lines · Thiemo Seufer
Quoted 2 lines
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.
Quoted 9 lines
Quoted 5 lines
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.
Signature · 3 lines
+ Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: [email protected], PGP key available +
Quoted 8 lines · Maciej W. Rozycki
Quoted 4 lines · Thiemo Seufer
Quoted 2 lines
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. :-)
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 1 line
-- 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
Quoted 5 lines · Thiemo Seufer
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
Quoted 5 lines · Thiemo Seufer
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.
Quoted 5 lines
Quoted 2 lines
Remember we are writing of the kernel -- we don't know what userland is
going to bring usI 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.
Signature · 3 lines
+ Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: [email protected], PGP key available +
Quoted 10 lines · Maciej W. Rozycki
Quoted 5 lines · Thiemo Seufer
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.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
Remember we are writing of the kernel -- we don't know what userland is
going to bring usI 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
Quoted 5 lines · Thiemo Seufer
Quoted 2 lines
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.
Quoted 4 lines
Quoted 2 lines
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).
Quoted 2 lines
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.
Quoted 1 line
Is there any point besides of hack value to use N64 on these machines?
Probably not.
Signature · 3 lines
+ Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: [email protected], PGP key available +