extreme mem usage under amd64 arch ?

Oliver Fromme olli at lurza.secnetix.de
Sat Apr 8 10:21:53 UTC 2006


Astrodog <astrodog at gmail.com> wrote:
 > Oliver Fromme <olli at lurza.secnetix.de> wrote:
 > > If a specific size is needed, then one of the standard
 > > types int64_t, int32_t etc. should be used which are
 > > defined appropriately by the OS.
 > > 
 > > Or, or course, use a higher-level programming language
 > > where you don't have to care about integer sizes at all,
 > > such as Python ("print 999**999" will fill the screen
 > > nicely).  ;-)
 > 
 > I suspect a python kernel would be painfully slow.......

Certainly.  I wasn't implying that Python would be well-
suited to write an OS kernel in.  Unless someone builds
a processor that executes Python bytecode natively.

 > > I guess this is the most important reason:  If ints were 64
 > > bits, there would be no easy way to handle 32 bit entities.
 > > Not being able to handle 32 bit objects with a native data
 > > type whould be a major problem, especially for an OS kernel,
 > > I think.
 > 
 > Can an AMD64 processor actually handle 32 bits of data natively, or
 > does it just knock off the last 32 bits of a 64-bit version, when its
 > not in long mode?

Yes, it can do both natively.  It's actually quite similar
to the way the 32bit registers are extensions of the 16bit
registers on the i386 platform, e.g. the %ax register (16bit)
just becomes the lower half of the %eax register (32bit).
Both variantes are handled with exactly the same opcodes,
but special prefix bytes are used to select between the two
data modes (16bit vs. 32bit).

On the amd64 platform, it's somewhat similar, except that
you get a further level:  The %eax register (32bit) becomes
the lower half of the %rax register (64bit).  The processor
can still handle both data types natively.

Best regards
   Oliver  (right now busy writing a boot manager in assembler)

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"C++ is to C as Lung Cancer is to Lung."
        -- Thomas Funke


More information about the freebsd-amd64 mailing list