[patch] linux: cpu_probe(): remove 32-bit CPU bits for MIPS64

[patch] linux: cpu_probe(): remove 32-bit CPU bits for MIPS64

[Maciej W. Rozycki]

Hello,

 There is no need to carry support for pure 32-bit CPUs around in
cpu_probe() in arch/mips64/kernel/setup.c, since such CPUs are not
supported by the port and likely won't ever reach that code due to a
reserved instruction exception earlier.  The code is misleading and a
possible cause of troubles, e.g. the 2.4 branch doesn't link now because
of an unresolved reference to cpu_has_fpu() which is only needed for
R2000/R3000. 

 The following patch removes the code for 2.4.  For the trunk
cpu_has_fpu() would be removed as well.  Any objections?

  Maciej

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

patch-mips-2.4.19-rc1-20020719-mips64-cpu-2
diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020719.macro/arch/mips64/kernel/setup.c linux-mips-2.4.19-rc1-20020719/arch/mips64/kernel/setup.c
--- linux-mips-2.4.19-rc1-20020719.macro/arch/mips64/kernel/setup.c	2002-07-15 02:57:48.000000000 +0000
+++ linux-mips-2.4.19-rc1-20020719/arch/mips64/kernel/setup.c	2002-07-22 23:44:00.000000000 +0000
@@ -123,16 +123,6 @@ static inline void check_wait(void)
 {
 	printk("Checking for 'wait' instruction... ");
 	switch(mips_cpu.cputype) {
-	case CPU_R3081:
-	case CPU_R3081E:
-		cpu_wait = r3081_wait;
-		printk(" available.\n");
-		break;
-	case CPU_TX3927:
-	case CPU_TX39XX:
-		cpu_wait = r39xx_wait;
-		printk(" available.\n");
-		break;
 	case CPU_R4200: 
 /*	case CPU_R4300: */
 	case CPU_R4600: 
@@ -143,9 +133,6 @@ static inline void check_wait(void)
 	case CPU_NEVADA:
 	case CPU_RM7000:
 	case CPU_TX49XX:
-	case CPU_4KC:
-	case CPU_4KEC:
-	case CPU_4KSC:
 	case CPU_5KC:
 /*	case CPU_20KC:*/
 		cpu_wait = r4k_wait;
@@ -163,28 +150,6 @@ void __init check_bugs(void)
 }
 
 /*
- * Probe whether cpu has config register by trying to play with
- * alternate cache bit and see whether it matters.
- * It's used by cpu_probe to distinguish between R3000A and R3081.
- */
-static inline int cpu_has_confreg(void)
-{
-#ifdef CONFIG_CPU_R3000
-	extern unsigned long r3k_cache_size(unsigned long);
-	unsigned long size1, size2;
-	unsigned long cfg = read_32bit_cp0_register(CP0_CONF);
-
-	size1 = r3k_cache_size(ST0_ISC);
-	write_32bit_cp0_register(CP0_CONF, cfg^CONF_AC);
-	size2 = r3k_cache_size(ST0_ISC);
-	write_32bit_cp0_register(CP0_CONF, cfg);
-	return size1 != size2;
-#else
-	return 0;
-#endif
-}
-
-/*
  * Get the FPU Implementation/Revision.
  */
 static inline unsigned long cpu_get_fpu_id(void)
@@ -235,28 +200,6 @@ static inline void cpu_probe(void)
 	switch (mips_cpu.processor_id & 0xff0000) {
 	case PRID_COMP_LEGACY:
 		switch (mips_cpu.processor_id & 0xff00) {
-		case PRID_IMP_R2000:
-			mips_cpu.cputype = CPU_R2000;
-			mips_cpu.isa_level = MIPS_CPU_ISA_I;
-			mips_cpu.options = MIPS_CPU_TLB | MIPS_CPU_NOFPUEX;
-			if (cpu_has_fpu())
-				mips_cpu.options |= MIPS_CPU_FPU;
-			mips_cpu.tlbsize = 64;
-			break;
-		case PRID_IMP_R3000:
-			if ((mips_cpu.processor_id & 0xff) == PRID_REV_R3000A)
-				if (cpu_has_confreg())
-					mips_cpu.cputype = CPU_R3081E;
-				else
-					mips_cpu.cputype = CPU_R3000A;
-			else
-				mips_cpu.cputype = CPU_R3000;
-			mips_cpu.isa_level = MIPS_CPU_ISA_I;
-			mips_cpu.options = MIPS_CPU_TLB | MIPS_CPU_NOFPUEX;
-			if (cpu_has_fpu())
-				mips_cpu.options |= MIPS_CPU_FPU;
-			mips_cpu.tlbsize = 64;
-			break;
 		case PRID_IMP_R4000:
 			if ((mips_cpu.processor_id & 0xff) == PRID_REV_R4400)
 				mips_cpu.cputype = CPU_R4400SC;
@@ -329,32 +272,6 @@ static inline void cpu_probe(void)
 		        mips_cpu.tlbsize = 48;
 			break;
 		#endif
-		case PRID_IMP_TX39:
-			mips_cpu.isa_level = MIPS_CPU_ISA_I;
-			mips_cpu.options = MIPS_CPU_TLB;
-
-			if ((mips_cpu.processor_id & 0xf0) ==
-			    (PRID_REV_TX3927 & 0xf0)) {
-				mips_cpu.cputype = CPU_TX3927;
-				mips_cpu.tlbsize = 64;
-				mips_cpu.icache.ways = 2;
-				mips_cpu.dcache.ways = 2;
-			} else {
-				switch (mips_cpu.processor_id & 0xff) {
-				case PRID_REV_TX3912:
-					mips_cpu.cputype = CPU_TX3912;
-					mips_cpu.tlbsize = 32;
-					break;
-				case PRID_REV_TX3922:
-					mips_cpu.cputype = CPU_TX3922;
-					mips_cpu.tlbsize = 64;
-					break;
-				default:
-					mips_cpu.cputype = CPU_UNKNOWN;
-					break;
-				}
-			}
-			break;
 		case PRID_IMP_R4700:
 			mips_cpu.cputype = CPU_R4700;
 			mips_cpu.isa_level = MIPS_CPU_ISA_III;
@@ -401,18 +318,6 @@ static inline void cpu_probe(void)
 			mips_cpu.icache.ways = 2;
 			mips_cpu.dcache.ways = 2;
 			break;
-		case PRID_IMP_R6000:
-			mips_cpu.cputype = CPU_R6000;
-			mips_cpu.isa_level = MIPS_CPU_ISA_II;
-			mips_cpu.options = MIPS_CPU_TLB | MIPS_CPU_FPU;
-			mips_cpu.tlbsize = 32;
-			break;
-		case PRID_IMP_R6000A:
-			mips_cpu.cputype = CPU_R6000A;
-			mips_cpu.isa_level = MIPS_CPU_ISA_II;
-			mips_cpu.options = MIPS_CPU_TLB | MIPS_CPU_FPU;
-			mips_cpu.tlbsize = 32;
-			break;
 		case PRID_IMP_RM7000:
 			mips_cpu.cputype = CPU_RM7000;
 			mips_cpu.isa_level = MIPS_CPU_ISA_IV;
@@ -459,15 +364,6 @@ static inline void cpu_probe(void)
 #ifdef CONFIG_CPU_MIPS32
 	case PRID_COMP_MIPS:
 		switch (mips_cpu.processor_id & 0xff00) {
-		case PRID_IMP_4KC:
-			mips_cpu.cputype = CPU_4KC;
-			break;
-		case PRID_IMP_4KEC:
-			mips_cpu.cputype = CPU_4KEC;
-			break;
-		case PRID_IMP_4KSC:
-			mips_cpu.cputype = CPU_4KSC;
-			break;
 		case PRID_IMP_5KC:
 			mips_cpu.cputype = CPU_5KC;
 			mips_cpu.isa_level = MIPS_CPU_ISA_M64;
@@ -481,20 +377,6 @@ static inline void cpu_probe(void)
 			break;
 		}		
 		break;
-	case PRID_COMP_ALCHEMY:
-		switch (mips_cpu.processor_id & 0xff00) {
-		case PRID_IMP_AU1_REV1:
-		case PRID_IMP_AU1_REV2:
-			if (mips_cpu.processor_id & 0xff000000)
-				mips_cpu.cputype = CPU_AU1500;
-			else
-				mips_cpu.cputype = CPU_AU1000;
-			break;
-		default:
-			mips_cpu.cputype = CPU_UNKNOWN;
-			break;
-		}
-		break;
 #endif /* CONFIG_CPU_MIPS32 */
 	case PRID_COMP_SIBYTE:
 		switch (mips_cpu.processor_id & 0xff00) {
@@ -793,18 +675,6 @@ void __init setup_arch(char **cmdline_p)
 	paging_init();
 }
 
-void r3081_wait(void) 
-{
-	unsigned long cfg = read_32bit_cp0_register(CP0_CONF);
-	write_32bit_cp0_register(CP0_CONF, cfg|CONF_HALT);
-}
-
-void r39xx_wait(void)
-{
-	unsigned long cfg = read_32bit_cp0_register(CP0_CONF);
-	write_32bit_cp0_register(CP0_CONF, cfg|TX39_CONF_HALT);
-}
-
 void r4k_wait(void)
 {
 	__asm__(".set\tmips3\n\t"

Re: [patch] linux: cpu_probe(): remove 32-bit CPU bits for MIPS64

[Ralf Baechle]

On Tue, Jul 23, 2002 at 01:55:13PM +0200, Maciej W. Rozycki wrote:

>  There is no need to carry support for pure 32-bit CPUs around in
> cpu_probe() in arch/mips64/kernel/setup.c, since such CPUs are not
> supported by the port and likely won't ever reach that code due to a
> reserved instruction exception earlier.  The code is misleading and a
> possible cause of troubles, e.g. the 2.4 branch doesn't link now because
> of an unresolved reference to cpu_has_fpu() which is only needed for
> R2000/R3000. 
> 
>  The following patch removes the code for 2.4.  For the trunk
> cpu_has_fpu() would be removed as well.  Any objections?

I intentionally have that 32-bit stuff in the 64-bit kernel so we can simply
have share identical CPU probing code between the 32-bit and 64-bit kernels.
This in anticipation of a further unification of the two ports which still
duplicate plenty of code with just minor changes.

To make sharing easier I suggest to move all the CPU probing code into it's
own file, probe.c or so?

  Ralf

Re: [patch] linux: cpu_probe(): remove 32-bit CPU bits for MIPS64

[Maciej W. Rozycki]

On Tue, 23 Jul 2002, Ralf Baechle wrote:

> I intentionally have that 32-bit stuff in the 64-bit kernel so we can simply
> have share identical CPU probing code between the 32-bit and 64-bit kernels.
> This in anticipation of a further unification of the two ports which still
> duplicate plenty of code with just minor changes.

 I suspected a maintability reason.  Thus as a temporary fix I'm checking
in a version that provides the missing cpu_has_fpu() function (a copy
from the trunk).

> To make sharing easier I suggest to move all the CPU probing code into it's
> own file, probe.c or so?

 That might be a good idea in principle, but it won't solve the problem
anyway.  I'd like to see the code for 32-bit processors get annihilated by
the compiler if built for mips64.  I'll look at it soon.  The MIPS32/64
crap needs to be fixed here as well.

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

Re: [patch] linux: cpu_probe(): remove 32-bit CPU bits for MIPS64

[Ralf Baechle]

On Tue, Jul 23, 2002 at 03:05:47PM +0200, Maciej W. Rozycki wrote:

> > I intentionally have that 32-bit stuff in the 64-bit kernel so we can simply
> > have share identical CPU probing code between the 32-bit and 64-bit kernels.
> > This in anticipation of a further unification of the two ports which still
> > duplicate plenty of code with just minor changes.
> 
>  I suspected a maintability reason.

Right

> Thus as a temporary fix I'm checking in a version that provides the
> missing cpu_has_fpu() function (a copy from the trunk).

You've been a little bit too fast :) I've almost implemented my suggestion
of moving the probing code into cpu-probe.c.

> > To make sharing easier I suggest to move all the CPU probing code into it's
> > own file, probe.c or so?
> 
>  That might be a good idea in principle, but it won't solve the problem
> anyway.  I'd like to see the code for 32-bit processors get annihilated by
> the compiler if built for mips64.  I'll look at it soon.  The MIPS32/64
> crap needs to be fixed here as well.

If you find a nice way of implementing this I certainly won't object.

  Ralf

Re: [patch] linux: cpu_probe(): remove 32-bit CPU bits for MIPS64

[Maciej W. Rozycki]

On Tue, 23 Jul 2002, Ralf Baechle wrote:

> You've been a little bit too fast :) I've almost implemented my suggestion
> of moving the probing code into cpu-probe.c.

 What's the problem?  Now the branch and the trunk are in sync (I just did
a `cp' from the trunk as the missing function was the only difference), so
you may apply the same changes to both. :-)  Otherwise you'd have to deal
with the difference.

> >  That might be a good idea in principle, but it won't solve the problem
> > anyway.  I'd like to see the code for 32-bit processors get annihilated by
> > the compiler if built for mips64.  I'll look at it soon.  The MIPS32/64
> > crap needs to be fixed here as well.
> 
> If you find a nice way of implementing this I certainly won't object.

 The MIPS32/64 fix is obvious; the 32-bit CPU is not so, but I have a sort
of an idea.  I'd like to get rid of all ifdefs in the area.  Not a high
priority, though, sorry.

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

Re: [patch] linux: cpu_probe(): remove 32-bit CPU bits for MIPS64

[Ralf Baechle]

On Tue, Jul 23, 2002 at 03:31:30PM +0200, Maciej W. Rozycki wrote:

> > You've been a little bit too fast :) I've almost implemented my suggestion
> > of moving the probing code into cpu-probe.c.
> 
>  What's the problem?  Now the branch and the trunk are in sync (I just did
> a `cp' from the trunk as the missing function was the only difference), so
> you may apply the same changes to both. :-)  Otherwise you'd have to deal
> with the difference.

No real toy, just a merge conflict.  Doing this cleanup I also noticed that
the 2.4 and 2.5 cpu probing code is out of sync, so I took care of that
as well.  Any future clean and fix should new be easier as the merge between
32-bit and 64-bit, 2.4 and 2.5 can simply be done using cp.  Modern
technology rules :)

> > >  That might be a good idea in principle, but it won't solve the problem
> > > anyway.  I'd like to see the code for 32-bit processors get annihilated by
> > > the compiler if built for mips64.  I'll look at it soon.  The MIPS32/64
> > > crap needs to be fixed here as well.
> > 
> > If you find a nice way of implementing this I certainly won't object.
> 
>  The MIPS32/64 fix is obvious; the 32-bit CPU is not so, but I have a sort
> of an idea.  I'd like to get rid of all ifdefs in the area.  Not a high
> priority, though, sorry.

I was refering to the less obvious part, obviously ;-)

  Ralf

Re: [patch] linux: cpu_probe(): remove 32-bit CPU bits for MIPS64

[Jun Sun]

Maciej W. Rozycki wrote:
> On Tue, 23 Jul 2002, Ralf Baechle wrote:
> 
> 
>>I intentionally have that 32-bit stuff in the 64-bit kernel so we can simply
>>have share identical CPU probing code between the 32-bit and 64-bit kernels.
>>This in anticipation of a further unification of the two ports which still
>>duplicate plenty of code with just minor changes.
> 
> 
>  I suspected a maintability reason.  Thus as a temporary fix I'm checking
> in a version that provides the missing cpu_has_fpu() function (a copy
> from the trunk).
> 
> 
>>To make sharing easier I suggest to move all the CPU probing code into it's
>>own file, probe.c or so?
> 
> 
>  That might be a good idea in principle, but it won't solve the problem
> anyway.  I'd like to see the code for 32-bit processors get annihilated by
> the compiler if built for mips64.  I'll look at it soon.  The MIPS32/64
> crap needs to be fixed here as well.
> 

FWIW, I like to see CPU probing and setup done in a distributed, configurable 
fashion.  Here are some of my ideas which have been floating around for a while.

. There is a global table, where each entry in the table have (at least) four 
fields:
	uint company_id
	uint processor_id
	uint revision_id
	void (*setup_cpu)(void);

. cpu_probe() simply reads prid register and search through the table.  If it 
finds matching one, then issue the (setup_cpu) call.

. matching allows wildcard matching.  Apparently more specific entry should be 
checked before more generic entries.

. cpu cache routines and tlb routines are organized accordingly, so that 
static configurations can be done sensibly.

This structure allows maximum code sharing for conforming CPUs and also give 
an easy for unique ones or buggy, early-production ones.  It should also make 
it easy to add or remove support for particular CPU or CPU family.  Of course, 
more details need to be fleshed out.


Jun

Re: [patch] linux: cpu_probe(): remove 32-bit CPU bits for MIPS64

[Maciej W. Rozycki]

On Tue, 23 Jul 2002, Jun Sun wrote:

> This structure allows maximum code sharing for conforming CPUs and also give 
> an easy for unique ones or buggy, early-production ones.  It should also make 
> it easy to add or remove support for particular CPU or CPU family.  Of course, 
> more details need to be fleshed out.

 Go ahead, that sounds much reasonable.  Most of the hassle will be for
pre-MIPS32/64 processors, obviously.

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

Re: [patch] linux: cpu_probe(): remove 32-bit CPU bits for MIPS64

[Kevin D. Kissell]

>  There is no need to carry support for pure 32-bit CPUs around in
> cpu_probe() in arch/mips64/kernel/setup.c, since such CPUs are not
> supported by the port and likely won't ever reach that code due to a
> reserved instruction exception earlier.  The code is misleading and a
> possible cause of troubles, e.g. the 2.4 branch doesn't link now because
> of an unresolved reference to cpu_has_fpu() which is only needed for
> R2000/R3000. 
> 
>  The following patch removes the code for 2.4.  For the trunk
> cpu_has_fpu() would be removed as well.  Any objections?

I'm on the road and don't have ready access to the sources,
but if I understand you correctly, I object.  The MIPS 5Kc and 
the NEC Vr41xx are two examples of 64-bit CPUs which don't 
have FPUs, and I believe there is at least one other from
Toshiba. (Tx49-something-or-other).

My personal bleief is that the mips and mips64 trees 
should ultimately be merged, and that creating additional 
and gratuitous differences should be avoided.

Re: [patch] linux: cpu_probe(): remove 32-bit CPU bits for MIPS64

[Kevin D. Kissell]

>  There is no need to carry support for pure 32-bit CPUs around in
> cpu_probe() in arch/mips64/kernel/setup.c, since such CPUs are not
> supported by the port and likely won't ever reach that code due to a
> reserved instruction exception earlier.  The code is misleading and a
> possible cause of troubles, e.g. the 2.4 branch doesn't link now because
> of an unresolved reference to cpu_has_fpu() which is only needed for
> R2000/R3000. 
> 
>  The following patch removes the code for 2.4.  For the trunk
> cpu_has_fpu() would be removed as well.  Any objections?

I'm on the road and don't have ready access to the sources,
but if I understand you correctly, I object.  The MIPS 5Kc and 
the NEC Vr41xx are two examples of 64-bit CPUs which don't 
have FPUs, and I believe there is at least one other from
Toshiba. (Tx49-something-or-other).

My personal bleief is that the mips and mips64 trees 
should ultimately be merged, and that creating additional 
and gratuitous differences should be avoided.

Re: [patch] linux: cpu_probe(): remove 32-bit CPU bits for MIPS64

[Ralf Baechle]

On Tue, Jul 23, 2002 at 04:38:58PM +0200, Kevin D. Kissell wrote:

> My personal bleief is that the mips and mips64 trees 
> should ultimately be merged, and that creating additional 
> and gratuitous differences should be avoided.

A first attempt at building a unifying 32-bit and 64-bit kernel was so
ugly that I dumped all that as of 2.0.14.

  Ralf

Re: [patch] linux: cpu_probe(): remove 32-bit CPU bits for MIPS64

[Maciej W. Rozycki]

On Tue, 23 Jul 2002, Kevin D. Kissell wrote:

> >  The following patch removes the code for 2.4.  For the trunk
> > cpu_has_fpu() would be removed as well.  Any objections?
> 
> I'm on the road and don't have ready access to the sources,
> but if I understand you correctly, I object.  The MIPS 5Kc and 
> the NEC Vr41xx are two examples of 64-bit CPUs which don't 
> have FPUs, and I believe there is at least one other from
> Toshiba. (Tx49-something-or-other).

 The function is exclusively for R2000/R3000 (mostly based on your past
suggestion there are broken processors that lock up on CP1 instructions
when none is present) which may have an external FPU.  Vr41xx CPUs have
FPU absence hardcoded (as do others which can't have an FPU) and MIPS32/64
ones obtain the information from the CP0 Config1 register, obviously.  The
function is never reached on a mips64 kernel -- there is no need to bloat
binaries with it.

 The coincidence with the i386's cpu_has_fpu definition is misleading.  At
this point we check MIPS_CPU_FPU in mips_cpu.options directly and there is
no need to wrap it in a macro, at least not yet. 

> My personal bleief is that the mips and mips64 trees 
> should ultimately be merged, and that creating additional 
> and gratuitous differences should be avoided.

 I don't think it's possible to be fully achieved.  Some differences will
have to exist, at least in the headers, but likely within the arch tree as
well.  The reason is binary code size or perfomance -- having R3000
support code in mips64 binaries is simply ridiculous as is using 32-bit
operations with 64-bit data on a 64-bit CPU.  However, it is worth trying
to minimize visible differences where possible, e.g. by convincing the
compiler to optimize irrelevant bits away. 

  Maciej

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

Re: [patch] linux: cpu_probe(): remove 32-bit CPU bits for MIPS64

[Kevin D. Kissell]

> > My personal belief is that the mips and mips64 trees
> > should ultimately be merged, and that creating additional
> > and gratuitous differences should be avoided.
> 
>  I don't think it's possible to be fully achieved.  Some differences will
> have to exist, at least in the headers, but likely within the arch tree as
> well.  The reason is binary code size or perfomance -- having R3000
> support code in mips64 binaries is simply ridiculous as is using 32-bit
> operations with 64-bit data on a 64-bit CPU.  However, it is worth trying
> to minimize visible differences where possible, e.g. by convincing the
> compiler to optimize irrelevant bits away.

I am not interested in running R3000's with 64-bit
binaries - only in having common sources for both.
I fully expect that there will always be differences
between the platforms, but the last time I checked,
there were more identical or nearly identical source
modules across the two arch trees than there were 
distinctly different ones.  The result is that the 
two subtrees tend to drift out of sync.  For me, 
it's really a "Software Engineering 101" kind of 
thing that there should be exactly one instance 
in the source tree of any source module that is 
common to 32-bit and 64-bit MIPS kernels, and that 
where the code cannot be common, sensible rules should 
be applied in terms of when to put both sets of code 
in the same module as conditionally complied blocks and
when to split things out into seperately maintained
modules. Etc. Etc.

		Kevin K.

Re: [patch] linux: cpu_probe(): remove 32-bit CPU bits for MIPS64

[Ralf Baechle]

Maciej,

>  I don't think it's possible to be fully achieved.  Some differences will
> have to exist, at least in the headers, but likely within the arch tree as
> well.  The reason is binary code size or perfomance -- having R3000
> support code in mips64 binaries is simply ridiculous as is using 32-bit
> operations with 64-bit data on a 64-bit CPU.  However, it is worth trying
> to minimize visible differences where possible, e.g. by convincing the
> compiler to optimize irrelevant bits away.

In this particular case all the bloat is just in __init code, could that
convince you?

  Ralf

Re: [patch] linux: cpu_probe(): remove 32-bit CPU bits for MIPS64

[Maciej W. Rozycki]

Ralf,

> >  I don't think it's possible to be fully achieved.  Some differences will
> > have to exist, at least in the headers, but likely within the arch tree as
> > well.  The reason is binary code size or perfomance -- having R3000
> > support code in mips64 binaries is simply ridiculous as is using 32-bit
> > operations with 64-bit data on a 64-bit CPU.  However, it is worth trying
> > to minimize visible differences where possible, e.g. by convincing the
> > compiler to optimize irrelevant bits away.
> 
> In this particular case all the bloat is just in __init code, could that
> convince you?

 Nope, sorry.  I'm by all means for keeping any questionable but at least
remotely useful code under the __init justification.  But in this case,
the code will never, ever be used.

 As I stated, I'm going to look deeper at the issue.  Just let it exist as
is for now, until me (or someone else) invents an improvement.  To state
it explicitly: yes, I'm going to keep a single source for both paths and
convince the compiler somehow to rip unneeded bits in the 64-bit case.

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