Re: Re: Macworld NY Rumors
Originally posted by wizard
The issue with panther is to be expected to a certain extent. People are looking at this as an applications issue, its not the PPC should be able to support 32 bit and 64 bit applications at the same time. It appears that they just hacked panther enough to permit booting of tthe 970.
To support 64-bit applications, there has to be support for 64-bit memory spaces. That requires the entire system to be able to handle 64-bit pointers which involves verifying that lots of code is 64-bit clean. I doubt that support for the 970 was just 'hacked' in, but that the job of fully supporting a 64-bit environment is a tough one.
I'm still wondering if Panther is a bridge implementation. That is will it allow the use of the extended addressing capabilities of the G4 in a way that is also compatable with the G5. A G4 powerbook capable of handling large memory systems would be nice. That is until a good implementation of the 970 in a portable can be offered.
A Powerbook simply isn't going to have more than 4 memory slots, and that itself is a stretch. And AFAIK 1GB SO-DIMMs in the profile required for the PowerBook still aren't available and probably won't be for a while. So if they are able to engineer 4 slots into a PowerBook you may see 4GB by next year. But I doubt that, so I wouldn't expect huge memory systems regardless of the processor on the PowerBook.
Regardless, it's often the memory controller that has more to do with the amount of RAM that a system supports than anything else.
Originally posted by rpkrajewski
- 64-bitness ... can in fact bloat the memory footprint of a program
Not that much, at least not on the PowerPC. The only bloat you would see would be that function entry points and other pointers would double in size. Assuming the average program has about 4000 functions that's 16K on disk. Assuming about 10,000 pointers makes for 40K in memory. Neither bit of bloat is particularly mind blowing.
- Not only does the code need to work, but all the external data formats (especially the binary ones) need to be supported carefully. In addition, 64-bit code often performs differently depending on the way structures are laid out in memory.
External data formats are not a big concern, and neither is the way that data is laid out in memory because the same smaller sized memory loads are all available. The only performance impact would have to do with alignment and that hit is already being taken on 32-bit PowerPCs. The bigger concern is code that assumes that a pointer is 32-bits and stuffs one into a 32-bit integer. This and other issues comprises how 64-bit clean a section of code is (anyone who was around 10 years ago may have heard the phrase 32-bit clean when the Mac was moving from 24-bit addressing to 32-bit addressing).
- All or at least certain classes of device drivers MUST be ported to 64-bit.
Everything in the kernal must be 64-bit clean. Anything running in user land can stay 64-bit ignorant (but only run in 32-bit programs).
- If Apple is not going to force everybody to compile two versions of their program, then they've got to implement a coexistence scheme where 32- and 64- bit applications that need to share things (streams, memory, locks, etc.) can actually do so. It's not easy ! Anybody who programmed Windows during the 16 to 32-bit transition knows this is true.
First I doubt that Apple will force developers to compile their programs as 64-bit, that would be absurd given that 90+% of the programs out there would make no use of the extra memory space.
Second, anything that is shared between programs has to go through the kernal, and thus it can be handled there, once. The difference between MacOS X 32/64 and Windows 16/32 is that MacOS X never had an implicit shared memory space. By default all applications have their own unique memory space and cannot touch each other at all, while on Windows the upper 2GB of each programs' memory space is shared. So for two prorgams to share something there has to be arbitration through the kernal which is the only entity that knows about other memory spaces. Basically, sharing under MacOS X (and I presume other unicies) doesn't involve direct pointer access, or even the same memory address in each memory space for the shared resource.
