64 Bit Questions

[Giorgos Keramidas]

On 2006-01-18 17:40, Anthony Dematteo <adematteo at gmail.com> 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:

    keramida at flame:/home/keramida$ uname -v
    FreeBSD 7.0-CURRENT #0: Mon Jan 16 17:28:28 EET 2006     \
    build at flame.pc:/home/build/obj/home/build/src/sys/FLAME

    keramida at flame:/home/keramida$ which lisp
    /usr/local/bin/lisp

    keramida at flame:/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

    keramida at flame:/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
    *