[NTLUG:Discuss] RE: x86_64 long and other modes -- WAS: AMD 64 Bit Distro

[Bryan J. Smith]

Justin M. Forbes wrote:  
> You will notice there are many issues with simply trying to rebuild
> upstream applications on a multilib system.  I am trying to push fixes
> upstream as I find them, other times I just fix it with packaging.  The
> Fedora packaging actually can handle multilib very well, unfortunately
> while the patches have been pushed upstream, they have not been merged.

I'm extremely impressed with what the Fedora project has done in so little
time.  People have been extremely critical of Red Hat and the Fedora
project, but that's typically because they don't look at what has really
gone on in less than a year!

> If rebuilding upstream source against a RHEL 3 or a Fedora system, if
> things dont work,try to libtoolize.

<Ignorance=ON>
"libtoolize"?
</Ignorance>

> AMD 64 can use PAE when in Legacy mode,

Yuck.  Now if the Athlon64/Opteron uses PAE, does it suffer the performance
hit?  Or does it just emulate it, but use the native 64-bit addressing
of the processor?

I heard a rumor that the Intel "Yamhill" design in the "Prescott" core
is actually using PAE, which is why even the new Xeon processors it has
been activated on will get killed by the Athlon64/Opteron in benchmarks.

Add in the Opteron's interconnect advantage and it's no contest, especially
on I/O intensive servers.  <Lust=On>God I've love to have one of those new
HP 4-way Opteron systems, with two AMD8131 HyperTransport dual-PCI-X tunnels,
each connected to their own processor.</Lust>

> and it can limit 32bit applications while in long mode, but 32bit
> applications could not use the 64bit memory model.

Right.  It's all very similar to what we had in the i386 model, coming
from i86 -- both a protected "Virtual 86" and the normal protected 386
mode.  Both actually used a protected 386 mode, but the former was so
i86 "real mode" programs could run, even those using EMS/XMS/DPMI.

> In addition, while in long mode, your registers are extended, and
> there are twice as many of them in long mode.

Right.  AMD's register design is most excellent in the x86_64 -- especially
the XMMs which feed both the traditional FPU and the SIMD instructions.

> While you may not notice the difference in programming for these in C
> or the like, the assembler and machine code is very different.

Of course, as the compiler uses register optimization and renaming.

> In order for a 64bit application to use a 32bit plugin/lib/etc, a
> thunking layer would have to be written, and the idea of writing that
> code is not something I like to think about after a meal.

You mean like the Windows-on-Windows (WoW) model?  Yeah, it's rather
ugly.

> Actually, this is not limited to FC.  The FHS calls for this, and I believe
> all PPC64/390x/x86-64 and other multilib systems use this.  Sym linking
> does not work for the reasons listed above.

Right.  I've been trying to inform people in my LUG about that.
 
> For Fedora, x86_64 is now a tier one arch, which means it is just as
> important as i386.  It is kind of interesting how some mindsets have
> changed since I began working on this port back in September.  

x86_64 has revolutionized x86.  AMD has really "cleaned up" the architecture,
and it's adding marketing-driven extensions *COUGH*Intel*COUGH*, but _real_ 
advantages.

As much as I'd prefer a "clean" RISC architecture like Power or (God I want to
cry) Alpha, AMD has proven that x86 can be extended with their acquired
NexGen (company) RISC86(R) engine far longer than anyone anticipated.

Intel has nothing that compares, because they have based _everything_ since
1993 on the fact that we'd be using IA-64 now.  Unfortunately, EPIC/Predication,
while a brilliant engineering idea, utterly _failed_ to deliver in silicon.

Now if we could only go back to 1997, and seen Intel just chuck IA-64 and go
with Alpha and FX!32 "binary translation" instead of the IA-64 path.  They
world _might_ be a whole different place now.

> Testing and feedback is most important. While we are in code freeze for
> Fedora Core 2, we will need testing on Extras (Fedora.us) as we roll out
> x86_64, and of course the FC3 development cycle will start up soon.  Bug
> reports are great, patches even better.

Unfortunately, I'm still on Athlon32 (again, AthlonMP to be exact).

I'm now a schoolteacher, no longer near 6-figures, and lower 5-figures, so
I can't simply go out and buy.  I guess I _could_ get a low-cost Athlon64
system, but I'd rather have a dual-Opteron.  So I'm waiting until the fall
before I assemble a new dual-Opteron for a workstation.

But I'll be sure to assist others as much as I can, and provide any help
I can.


-- 
Bryan J. Smith, E.I. -- Engineer, Technologist, School Teacher
b.j.smith at ieee.org