See my previous post. I don't like to repeat.

Not for obvious ones, such as "the BSD people are masturbating monkeys".

I repeat (though I just said I don't like to repeat) -- I've never doubted the mechanism. You don't need to point that out to me.

I see a little bit increased power consumption for SU9300 and a little better performance than that of U2500. They are pretty much the same. So why do I invest for an SU9300 system with new CPU, mother board and memory module, while my U2500 system is wie neu? For the fun of polluting the environment?

I am now actually surprised at how many people confuse memory data width with instruction set and register width.

I never said you should replace your system with a new one, I merely pointed out that there are 64 bit capable systems in the same range of power consumption as your 32 bit system, something which you have denied.
Nothing more to say about that.

About the multilib topic: I would vote for adding slackpkg+ to /extra instead of a multilib tree, so that anyone who wants to go multilib can just install slackpkg+ and use it to convert the system.

There is no 64 bit memory addressing without PAE on x86. PAE is mandatory for 64 bit "Long Mode" used by native 64 bit operating systems. It is enabled and used on all modern PCs (required for NX), on UEFI machines since the moment of power-on.

As a multilib user, I don't think it's valuable to include multilib by default; of all my 64-bit machines, only one of them is actually running a multilib setup - the rest are pure 64-bit. It might, on the other hand, be worthwhile to include the relevant compat32/multilib tools (and/or slackpkg+) in, say, /extra, if only to streamline the installation process; let those users run those tools and download the multilib packages as needed, while sparing the non-multilib users the CD/DVD space. Perhaps sbopkg could be thrown in too while we're at it :)

On top of Wine, the two applications I use semi-routinely that require multilib are Steam and VirtualBox; the former requires it because of the non-universal nature of 64-bit support in (closed-source) games, and the latter seems to require it for proper x86 emulation or somesuch.

Virtualbox only needs multilib if you use the SlackBuild. If you use the installer instead multilib is not needed.

Why do you intentionally misread my posts again and again?

When I say "there is no A with B" I don't mean there's no A and no B. I mean there is "no combimation of A and B".

It was just an example. In fact, there are several 64 bit CPUs in the 10W range that would beat the crap out of your CPU, not only due being 64 bit, but due to much better IPC, advanced features like SSE4 and they even feature an inbuilt GPU, which can be used for OpenCL acceleration. Not to mention faster RAM and mainboard interfaces.

But I like building things from source; it's fun to watch all the GCC gibberish fly by.

More seriously, there used to be a licensing difference between the binary installer and compiling from source. Apparently this isn't the case anymore (hasn't been since 4.0; and here I've been thinking that it was still under the PUEL :P ), but sbopkg's more convenient anyway.