On 2006-01-18 17:40, Anthony Dematteo <[EMAIL PROTECTED]> wrote: > I have a couple questions about the AMD64 Project. > > 1. They page mentions that there is multiprocessor support. Does > this include the dual core processors? Will the OS dispatch processes > and threads to each core?
Not sure if I'm the right person to answer this in great technical detail, but I think the answer is 'yes' to both questions. > 2. While the OS will use the 64 bit mode, will the applications still > run in the compatibly mode? Not necessarily. By default the "base system" and any applications you compile yourself will be 64-bit too. The installed compiler and toolchain support building 32-bit binaries too, if you manually compile things yourself, but you don't have to if you don't feel like doing it. > Will the applications still only use 32 bits. No, 64-bit applications can use the full 64-bit address range. > 3. Also, will the OS take advantage of being 64 bit and load itself > into memory higher than the 32 bit addressable mark so that my 32 bit > applications can use the lower part? I'm not sure if I understand the question correctly, but why does the specific 'place' in the virtual 64-bit address space matter to an application? Some may argue that depending on such low level information is broken behavior and should be fixed in the application. > 4. If I enable 64 bit compilation on GCC prior to installing a port, > will the port then be 64 bit enabled? Ports do not support cross-compiling, as far as I know. If you build on a 64-bit machine, you get 64-bit binaries. If you build on a 32-bit machine, you get 32-bit binaries. > 5. If I stall an IDE and write my own applications on a 64 bit > machine, can a 32 bit machine still run them? No. The 64-bit binaries refer to registers, addresses and other parts of the 64-bit architecture that are not available in 32-bit hardware. The other way around works fine though. The 64-bit versions of FreeBSD include 32-bit libraries and runtime support too, so you can run 32-bit binaries seamlessly. In fact, this is exactly what enabled me to run a 32-bit binary of CMUCL, and experiment with LISP now that I've started learning about it: [EMAIL PROTECTED]:/home/keramida$ uname -v FreeBSD 7.0-CURRENT #0: Mon Jan 16 17:28:28 EET 2006 \ [EMAIL PROTECTED]:/home/build/obj/home/build/src/sys/FLAME [EMAIL PROTECTED]:/home/keramida$ which lisp /usr/local/bin/lisp [EMAIL PROTECTED]:/home/keramida$ file `!!` file `which lisp` /usr/local/bin/lisp: ELF 32-bit LSB executable, Intel 80386, \ version 1 (FreeBSD), for FreeBSD 6.0 (600100), \ dynamically linked (uses shared libs), not stripped [EMAIL PROTECTED]:/home/keramida$ lisp ; Loading #P"/home/keramida/init.lisp". CMU Common Lisp 19c Release (19C), running on flame.pc With core: /usr/local/lib/cmucl/lib/lisp.core Dumped on: Wed, 2005-11-30 01:04:28+02:00 on boomerang See <http://www.cons.org/cmucl/> for support information. Loaded subsystems: Python 1.1, target Intel x86 CLOS based on Gerd's PCL 2004/04/14 03:32:47 * _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"