Date: Thu, 29 Jan 2004 09:10:35 -0600 (CST) From: James Van Artsdalen <james-freebsd-amd64@jrv.org> To: taob@risc.org Cc: freebsd-amd64@freebsd.org Subject: Re: New AMD64 owner Message-ID: <200401291510.i0TFAZU3012283@bigtex.jrv.org> In-Reply-To: <Pine.GSO.4.21.0401290757580.26036-100000@tor-adm1.nbc.attcanada.ca> (message from Brian Tao on Thu, 29 Jan 2004 08:13:16 -0500 (EST)) References: <Pine.GSO.4.21.0401290757580.26036-100000@tor-adm1.nbc.attcanada.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Thu, 29 Jan 2004 08:13:16 -0500 (EST) > From: Brian Tao <taob@risc.org> > AMD64 CPU's are supposed to have "seamless" backwards > compatibility with 32-bit x86 code... I've confirmed this by watching > Windows 98 boot up on my new system (it was what the integrator had > installed to do some burn-in testing, presumably). If this is the > case, why am I seeing references to broken ia32 compatibility? > Shouldn't that "just work"? Or is this a kernel/loader issue with a > 64-bit aware install? The AMD64 processors start up in an Intel x86 compatible mode. If nobody puts it in 64-bit mode then it will stay x86 compatible. Once FreeBSD puts the processor in 64-bit mode things are a little different. Now 32-bit must be run with special provisions. The situation is very analogous to the early 32-bit operating systems running 16-bit software. I'm not sure what the issues blocking 32-bit software in FreeBSD/AMD64 are. The kernel needs a 32-bit syscall & thunk layer, various kernel calls need to know about the constricted address space, the loader and shared lib linker need to know, and the build process needs to know to compile both 32-bit and 64-bit versions of the shared libraries, etc. There are a lot of details. Some are no doubt done: I don't know if Peter has given a status report or stated where others might be able to help. > Related to the previous question: should I be able to install > either freebsd-i386 or freebsd-amd64, and both will work? Obviously > the i386 install will run in 32-bit mode, but at least it will run > (and act as a really fast Intel box, I'm hoping) Yes, either work, and as an x86 it is as fast as any Intel x86. It is a myth that AMD64 competes with the Itanic. That is beside the point. The AMD64 chips are designed to beat the Xeon and Pentiums, because that is where the money is. There is no money to be made by building a chip that sinks Itanic, but there certainly is by beating Xeon/P-4, and AMD knows it. A lot of AMD64 architecture tradeoffs are best understood by realizing that AMD64 is focused squarely on Intel's 32-bit market, with any 64-bit/server wins icing on the cake but not the site of the real battle for a profit. Nowhere that I know of has AMD sacrificed 32-bit functionality or performance to get even one iota of 64-bit advantage. (for that matter having 64-bit pointers and integers is minor to me compared to adding the extra int & float registers) > The Tyan motherboard has an onboard Silicon Image 3114 S-ATA > adapter. I have two WD Raptor drives attached. The aforementioned > Windows 98 appears to boot and recognize the drives just fine (this is > only booting to the command prompt, so there are no third-party > drivers being loaded, AFAICT). This leads me to believe that the BIOS > or the S-ATA adapter itself is able to dumb itself down to look like a > normal IDE drive. Win9x is probably booting in compatibility mode. There is some magic called the Real Mode Mapper that switches the processor back to real mode, does BIOS calls in real mode, and then switches back to protected mode. In any case, testing Win9x in this way doesn't really tell you anything about a disk controller with an option ROM unless you look carefully to see how Win9x is accessing the drive. > Is it possible to subsequently do a source build upgrade to amd64? > Or do we not have the tools to do that yet? I think Peter has said he has no plans to try to do an upgrade-in-place from a 32-bit to 64-bit FreeBSD environment.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200401291510.i0TFAZU3012283>