Date: Sat, 8 Apr 2006 13:36:15 +0800 From: Astrodog <astrodog@gmail.com> To: freebsd-amd64@freebsd.org, "John-Mark Gurney" <gurney_j@resnet.uoregon.edu> Subject: Re: extreme mem usage under amd64 arch ? Message-ID: <2fd864e0604072236p2ee54649ld9d328f429005d6a@mail.gmail.com> In-Reply-To: <200604072116.k37LGQhQ071637@lurza.secnetix.de> References: <20060407172618.GC72485@funkthat.com> <200604072116.k37LGQhQ071637@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4/8/06, Oliver Fromme <olli@lurza.secnetix.de> wrote:
> John-Mark Gurney <gurney_j@resnet.uoregon.edu> wrote:
> > Astrodog wrote this message on Fri, Apr 07, 2006 at 21:28 +0800:
> > > and pointer, you use 4 Bytes. On a 64-bit processor, all ints, and
> > > pointers take up 64-bits of memory. So, for every int and pointer, y=
ou
> > > use 8 bytes. (Assuming its a 64-bit app, of course) That means
> >
> > Not quite... FreeBSD/amd64 like all? the other arches are LP64...
> > that means longs and pointers are 64bits, while ints remain at 32bits.=
..
>
Gotcha
> I think longs are 32 bits on /i386, and 64 bits on /amd64
> (On /i386, "long longs" are 64 bits.)
>
> A programmer should not rely on specific sizes of longs,
> ints etc. anyway. In particular, he should not assume
> that a long is larger than an int, that a pointer has
> the same size as an int or a long, and similar things.
>
Heh. Shouldn't and won't are different, sadly. Myself included.
> 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.......
> > This was primarily done because too many people assumed ints were
> > 32bits for things like disk structures and network protocol layout,
> > and to break less code, LP64 was decided upon...
>
Glad to know I'm not the only one...
> 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?
> Best regards
> Oliver
>
> PS: The random quote in my signature below fits pretty well.
> It really is random, I swear. :-)
>
> --
> 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 quirky, flawed, and an enormous success."
> -- Dennis M. Ritchie.
> _______________________________________________
> freebsd-amd64@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-amd64
> To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2fd864e0604072236p2ee54649ld9d328f429005d6a>