site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Jun 4, 2005, at 12:27 PM, Tony Scaminaci wrote: PowerPC, as the Mac uses it, is a big endian platform. Thus say you have a memory buffer at location 0x1000. Make sense? e.g.: 0xfeedfacedeadbeefULL is represented in memory as: 0x1000: 0xfe 0x1001: 0xed 0x1002: 0xfa 0x1003: 0xce 0x1004: 0xde 0x1005: 0xad 0x1006: 0xbe 0x1007: 0xbf 0xc0edf00d as an unsigned int would be: 0x1000: 0xc0 0x1001: 0xed 0x1002: 0xf0 0x1003: 0x0d But in general, you want to use the 64-bit interfaces, which leads to: William Kucharski kucharsk@mac.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... Why wouldn't it fill in the lower four bytes instead? I ask this because when I print out mac_pagesize, I do get 4096 as expected so the lower bytes must have the correct value. If the buffer is to be an unsigned int, the value goes into the four bytes starting at 0x1000, MSB at 0x1000. If the buffer is to be an unsigned long long, the value goes into the eight bytes starting at 0x1000, MSB at 0x1000. If the kernel thinks it's filling in an unsigned int at location 0x1000, it just writes those first four bytes, which happen to be the most significant four bytes of an unsigned long long as seen from that address. Why does it print correctly? Assuming you're just doing the printf with an unsigned specifier, the printf will only read those first four bytes as the value to be printed, so the printf will print the value 0x1000, but the system sees the value as the 64-bit quantity 0x100000000000ULL. This would defeat the purpose of running a 64-bit executable - to test more than 4 GB of memory. The memory address pointers have to be 64 bits if they're going to be able to access all the memory a user has installed. You're confusing virtual and physical addresses here; as long as the operating system can access physical memory with 64-bit addresses, a user could use a 32-bit address to access that memory, though not more than 4G at a time. Think of it as a sliding 32-bit window accessing the full 64-bit memory space. This is definitely an option if the 64-bit compiler will allow it. Even worse, I could just set the page size to 4096 and be done with it. Not a good idea in case it ever changes but it seems to be 4K on most modern OS's these days. There is "nothing wrong" with passing host_page_size the address of a 32-bit variable as long as the kernel isn't compiled with __ppc64__ set and as such won't try and write a 64-bit quantity to the 32-bit variable's address. As I said, this is somewhat of a hole in the current implementations, and Apple DTS should really be the ones to resolve it one way or the other. I'd consider host_page_size() to be part of libSystem if anything. If we can't address more than 4 GB of memory, what's the point of having a 64-bit OS and a PPC G5? At the very least, Tiger should be able to get at all of the user's installed memory assuming the user runs a 64-bit app. How can the kernel handle more than 4 GB of address space if it's not 64-bit? See above; you're not grasping the concept of a 32-bit virtual address addressing memory via a 64-bit physical address. This is how the kernel dealt with memory pre-Tiger; apps could access memory mapped with a 64-bit physical address space, an app just couldn't access more than 4GB at a time. There's got to be a simple workaround to this problem. I can't be the only person trying to use more than 4GB of memory at one time. Any application that bills itself as 64-bit has to address these issues. 32-bit applications CAN 'use' more than 4GB of memory at a time, but not via the standard malloc() interfaces in continuous virtually mapped buffers more than 4GB at a time. If you think this is fun, PCI devices can only address a 32-bit memory space, so when using PCI devices on a 64-bit architecture, memory address translation must be done if you want to allow those devices to access the entire memory space. This is what the DART is all about, as described here: <http://developer.apple.com/documentation/Darwin/Conceptual/ KernelProgramming/vm/chapter_7_section_8.html> So, bottom line, you're correct in wanting to compile your app in 64- bit mode, but there's a hole in this particular call that causes things to break due to Darwin's current mixed 32/64-bit nature. If Apple would move to a full 64-bit kernel, like Solaris or, as of 2.6, Linux, a lot of these issues would go away at the cost of compatibility with existing device drivers and some kernel code bloat as opcodes got wider. In theory IOKit should insulate even the driver level from the implementation details of the kernel itself, but in practice it's a lot more complex and MacOS X remains astraddle the 32/64-bit line... This email sent to site_archiver@lists.apple.com