Re: Mac Memory Models

Sherm Pendley wrote: 
From Apple's "64-bit Transition Guide", at:

     <http://tinyurl.com/dgs6j>
     <http://developer.apple.com/documentation/Darwin/Conceptual/64bitPorting/transition/chapter_3_section_2.html>

     "Initially, only libSystem, the Accelerate framework, and a few other
     low-level support libraries are available in a 64-bit format. This means
     that only basic, command-line functionality is available to 64-bit
     applications. GUI applications that need more than 4 GB of memory will
     have to split their functionality into a 64-bit back end and a 32-bit GUI
     that communicate using interprocess communication."

But that's a very nontechnical warning. I assume they say it just to be safe, because:

* malloc(3) returns whatever it can find, not just memory under 4GB. (and of course that's what you want most of the time if you go 64bit)

* Cocoa and other libraries use 32bit instructions, meaning they can't correctly follow 64bit pointers (as might be returned by malloc(3)) and maybe they even malloc() themselves, resulting in truncated (and wrong) object addresses.

All that would be needed, IMHO, is to have a 32bit malloc() that always returns memory from the low 4GB, and have all 32bit libraries (like Cocoa) use that. In what way COULD they even notice the difference? Their memory is in 4GB, and their instructions work with 32bit values.

The rest of the application could use 64bits, and nobody (esp. Cocoa) would EVER notice (unless you want to pass a 64bit pointer to a Cocoa object, such as a list, but I suppose if you need 64bits, you don't do it to create NSArrays ;) ).

My point is that you have to be careful, and Apple doesn't want to explain memory-agnostic C programmers what they have to take care of.

Unfortunately I can't test my assumptions, as I only have a Mac mini (and no intention to get anything more expensive right now). And next year there's Intel anyway. AFAIK the way the crappy x86 is designed, indeed you CAN'T mix 32bit and 64bit mode, unlike PPC which was architectured as 64bit from the very beginning. That was one of the reasons I went Mac back then, but it seems in the consumer world all that doesn't count anymore. Well, I hope Macs will get faster and cheaper at least ;)

There are many other notes in that guide that strongly imply that there is a
distinction made between 64- and 32-bit applications. For example, 32-bit apps
can't load 64-bit plugins, and vice-versa. All of the libraries used by a 64-
bit app must be 64-bit. Etc.

All pointers you pass to the library must be 32bit safe, and the malloc that's used by library must be 32bit safe.

For whatever reason, the OS puts up a hard wall between 64- and 32-bit apps.
Binaries are flagged as one or the other - the linker won't even let you link
mixed object files, much less attempt to run them.

Oh. Now that's unfortunate. After all there's no "64bit mode" on PPC. All code compiled for the G4 IS 64bit code, it just doesn't use the high 32bit in all those registers (in fact, zeroes them so it works correctly on CPUs like the G5 that do have those upper bits).

That doesn't necessarily mean you're wrong about the PPC's capabilities. It's
quite possible - likely, in fact - that the G5 chip has capabilities that Mac
OS X doesn't take advantage of. I've heard it said that Linux actually has
better support for 64-bit userland than Mac OS X, but I don't know to what
extent that might be true.

I think that maybe Linux was developed in a way that's cleaner and more portable, and it simply compiles as 100% 64bit code. With enough cheap volunteers to test 64bit stuff (most of them running AMD I guess, but probably some PPCs and Alphas) that wasn't too hard. I suspect that Objective C's runtime is pretty 32bit reliant right now (while most of Linux is simple C), so that rearchitecting that is a bit harder. I wonder if they will ever do it. For most uses I would even argue the IPC model Apple advertises is better for applications that need 64bit.

4GB (plenty of space, right?).

640KB should be enough for anyone. :-) 

Well, 4GB for the GUI layer... :D

--
I believe in Karma.  That means I can do bad things to people
all day long and I assume they deserve it.
	Dogbert
.

Relevant Pages

  • Re: Can MS listen to customers?
    ... IE is comprised of a set of libraries that other applications use. ... a HUGE portion of even a minimal install of Windows (or even in ... For Windows, Notepad, Paint, IE, OE, msconfig, Wordpad, Hearts, NT ...
    (microsoft.public.windowsxp.general)
  • [Full-Disclosure] Overflow in SunRPC-derived XDR libraries
    ... Applications using vulnerable implementations of SunRPC-derived XDR ... BSD-derived libraries with XDR/RPC routines ... Note that this vulnerability is similar to, but distinct from, ... Because SunRPC-derived XDR libraries are used by a variety of vendors ...
    (Full-Disclosure)
  • Re: Reading great code
    ... not aware of any mission-critical applications that use .NET, ... and libraries) or no operating system at all (except perhaps ... The C language, for example, can't be used ... more than Java is a prototyping platform. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Reading great code
    ... aware of any mission-critical applications that use .NET, and the more critical applications use specialist operating systems (and compilers, and libraries) or no operating system at all, for just the reason you've spotted. ... And even when the languages used do have code libraries available, those libraries are generally not used unless they have been specifically designed with mission-critical applications in mind. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: [Lit.] Buffer overruns
    ... >>safe application difficult and secure applications impossible. ... >>libraries can be shrunk to fit and C's RTL is one of those. ... applications it might be (I suspect the performance-sensitive apps are ...
    (sci.crypt)