Thank you for the explaination, and I read your response 4 or 5 times trying to understand, but I just do not have the background. I kind of get a feel for what you and Programmer are saying but really don't understand.
Don't sweat it. I got my first job as a system guy in '94. That was a mainframe computer I was supposed to work with. My boss made me read a book about the system's architecture and memory management, paging and all this stuff. It took about 3-4 times reading that book (with nice IBM pictures) to get it, and that was with a degree in computer science and about 10 years of geekness.
Reading that thing you quoted took me back. IBM apparently uses the same terms for the PPC range that it uses for the mainframe processors: PTE, STE, TLB, they're all there.
The short version of the thing is this: An OS can work in either of two modes: 32-bit or 64-bit.
When working in 32-bit, all programs work in 32-bit and everything's the same as it was in G4. To work in this mode, the OS has to execute a few machine instructions at startup. Even when working in 32-bit the OS can use more than 4GB of RAM (up to 16) as long as each programs gets only 4. IMO, this is what's in Smeagol.
When working in 64-bit, programs can be either 32-bit or 64-bit. To work in this mode the OS has to execute some machine instructions at startup and make segment and page tables in the new format. I believe that is what Panther does. To allow 64-bit apps to really run, you need to have 64-bit APIs. I don't know how much of that Apple has done.
When working in 64-bit, programs can be either 32-bit or 64-bit. To work in this mode the OS has to execute some machine instructions at startup and make segment and page tables in the new format. I believe that is what Panther does. To allow 64-bit apps to really run, you need to have 64-bit APIs. I don't know how much of that Apple has done.
You're missing what the special "bridge" hardware does, however. It allows 32-bit software that happens to find itself in a 64-bit address space to work properly. Basically the "lowest" 4 GB are setup so that 32-bit software thinks it is in a standard 32-bit address space. This allows a 64-bit app to call the 32-bit software as long as it follows a few rules (i.e. keep the pointers where the 32-bit software can see them, and mode switch when calling into/returning from the 32-bit code).
You're missing what the special "bridge" hardware does, however. It allows 32-bit software that happens to find itself in a 64-bit address space to work properly. . .
I wonder about the impact of this bridge hardware on the software. For now, there will be the need to use the bridge for 64-bit applications. Later, when the OS has 64-bit APIs, maybe in Mac OS 10.4, the bridge will not be necessary. I don't understand enough to know how this will affect applications, and I see several possible impacts.
1. Maybe no visible impact. Application will automatically use the bridge if necessary. However, I suspect such a programming technique would be inefficient, and have too much overhead.
2. Upon restart, an application will check the OS to determine whether to load the bridge code.
3. Upon installation, an application will install the bridge version only for OS 10.3. This requires reinstalling applications when updating from OS 10.3 to 10.4.
4. (This one cannot be true.) The application checks the hardware and always uses the bridge for the 970.
Call me a worry wart, but I wonder about these things.
Apple is very good at this kind of migration -- I wouldn't worry about it.
The bridge will remain in use until all APIs have 64-bit versions. At that point old software can be supported by keeping a "bridged" version of the API around that just turns around and calls the new 64-bit API. It will introduce a small amount of overhead, but it will be completely insignificant compared to the overhead in the 68K->PPC transition.
. . . The bridge will remain in use until all APIs have 64-bit versions. At that point old software can be supported by keeping a "bridged" version of the API around that just turns around and calls the new 64-bit API. . .
Ah ha! Thank you. It is yet another alternative, and it makes more sense than all of mine. If I understand correctly, developers today will not even have to consider 64-bit APIs. They will write all 64-bit applications just using bridge hardware. When Mac OS 10.4 arrives, it will (likely) have 64-bit APIs plus a means to run older 64-bit applications, as you suggested. At that time, developer can begin to use 64-bit APIs, and these applications will require OS 10.4 or higher to run. This is not too different from applications now that require OS 10.2, and will not run on 10.1. You're right. Apple is good at this kind of thing.
Ah ha! Thank you. It is yet another alternative, and it makes more sense than all of mine. If I understand correctly, developers today will not even have to consider 64-bit APIs. They will write all 64-bit applications just using bridge hardware. When Mac OS 10.4 arrives, it will (likely) have 64-bit APIs plus a means to run older 64-bit applications, as you suggested. At that time, developer can begin to use 64-bit APIs, and these applications will require OS 10.4 or higher to run. This is not too different from applications now that require OS 10.2, and will not run on 10.1. You're right. Apple is good at this kind of thing.
No. Unless you're a developer writing something with a peculiar need for 64-bitness you won't.
Any 64-bit application will not run on any currently delivering hardware, nor any iMac, PowerBook, eMac or iBook. Even PowerMacs will still be available in G4 versions for the near future. Adobe, Microsoft and all the rest will not produce a 64-bit up unless either:
1. There is a real need, or
2. Even the iBooks have had a G5 for the last two years.
1 is true for very few. 2 will not be true for about 4 years.
Kickaha and Amorph couldn't moderate themselves out of a paper bag. Abdicate responsibility and succumb to idiocy. Two years of letting a member make personal attacks against others, then stepping aside when someone won't put up with it. Not only that but go ahead and shut down my posting priviledges but not the one making the attacks. Not even the common decency to abide by their warning (afer three days of absorbing personal attacks with no mods in sight), just shut my posting down and then say it might happen later if a certian line is crossed. Bullshit flag is flying, I won't abide by lying and coddling of liars who go off-site, create accounts differing in a single letter from my handle with the express purpose to decieve and then claim here that I did it. Everyone be warned, kim kap sol is a lying, deceitful poster.
Now I guess they should have banned me rather than just shut off posting priviledges, because kickaha and Amorph definitely aren't going to like being called to task when they thought they had it all ignored *cough* *cough* I mean under control. Just a couple o' tools.
Don't worry, as soon as my work resetting my posts is done I'll disappear forever.
. . . I wouldn't worry about the "bridge" either. Nothing I have seen or read leads me to think it will affect or even be accessible to Userland in the least. . .
If I understand what Programmer has been saying, those who develop 64-bit applications will need the bridge to call 32-bit APIs in Panther.
What I do not know, now that you mention it, is whether Panther code will do it all automatically. My gut feeling is that such an approach would not work when you consider future versions of Mac OS, which will have 64-bit APIs. I think developers will have to include something relating to the bridge today, for making 64-bit applications. That is pure opinion however. I'll bow to the facts when they are presented.
No. Unless you're a developer writing something with a peculiar need for 64-bitness you won't. . .
Well, 64-bitness, and the bridge, was the only topic in my postings. The bridge is totally unnecessary for 32-bit applications. And yes, I agree with you that most applications will remain 32-bit.
What I do not know, now that you mention it, is whether Panther code will do it all automatically. My gut feeling is that such an approach would not work when you consider future versions of Mac OS, which will have 64-bit APIs. I think developers will have to include something relating to the bridge today, for making 64-bit applications. That is pure opinion however. I'll bow to the facts when they are presented.
As I alluded to above, I think this as well -- developers who are writing 64-bit code and want to call a 32-bit API will need to do something slightly special to do so. This something special is probably quite minor like using a special memory allocator function for anything that is going to be passed to the 32-bit API.
Kickaha and Amorph couldn't moderate themselves out of a paper bag. Abdicate responsibility and succumb to idiocy. Two years of letting a member make personal attacks against others, then stepping aside when someone won't put up with it. Not only that but go ahead and shut down my posting priviledges but not the one making the attacks. Not even the common decency to abide by their warning (afer three days of absorbing personal attacks with no mods in sight), just shut my posting down and then say it might happen later if a certian line is crossed. Bullshit flag is flying, I won't abide by lying and coddling of liars who go off-site, create accounts differing in a single letter from my handle with the express purpose to decieve and then claim here that I did it. Everyone be warned, kim kap sol is a lying, deceitful poster.
Now I guess they should have banned me rather than just shut off posting priviledges, because kickaha and Amorph definitely aren't going to like being called to task when they thought they had it all ignored *cough* *cough* I mean under control. Just a couple o' tools.
Don't worry, as soon as my work resetting my posts is done I'll disappear forever.
. . . The bridge will remain in use until all APIs have 64-bit versions. At that point old software can be supported by keeping a "bridged" version of the API around that just turns around and calls the new 64-bit API. . .
It just occurred to me that AirSluf could be correct, that developers need not be concerned about the bridge. What if Apple took the opposite approach to the one you suggest. What if Apple put the 64-bit API calls into Panther, but there would be no 64-bit API code. Rather, these APIs would simply activate the bridge and make an appropriate 32-bit API call. Off hand, I don't see why this would not work.
The advantage, if it can be done, is that developers need know nothing about the bridge, and future versions of OS X would not need to have special code to take care of older software. It looks like a cleaner approach, if it works. Possible? (I know, I should simply wait to see what Apple really does.)
Access to the hardware bridge is done in the OS and used to configure the application address space so that whatever API-level tricks Apple uses will work. There still needs to be something in the API to ensure that 64-bit applications can call 32-bit code, and that can be called a "software bridge" (or thunk, or whatever). It is this piece of magic that appliction developers need to use.
Kickaha and Amorph couldn't moderate themselves out of a paper bag. Abdicate responsibility and succumb to idiocy. Two years of letting a member make personal attacks against others, then stepping aside when someone won't put up with it. Not only that but go ahead and shut down my posting priviledges but not the one making the attacks. Not even the common decency to abide by their warning (afer three days of absorbing personal attacks with no mods in sight), just shut my posting down and then say it might happen later if a certian line is crossed. Bullshit flag is flying, I won't abide by lying and coddling of liars who go off-site, create accounts differing in a single letter from my handle with the express purpose to decieve and then claim here that I did it. Everyone be warned, kim kap sol is a lying, deceitful poster.
Now I guess they should have banned me rather than just shut off posting priviledges, because kickaha and Amorph definitely aren't going to like being called to task when they thought they had it all ignored *cough* *cough* I mean under control. Just a couple o' tools.
Don't worry, as soon as my work resetting my posts is done I'll disappear forever.
True, there are ways to make this quite painless though. Almost to the point of seeming transparent and not "special" in any appreciable way until you start getting into performance considerations.
That's what I've been saying. This little piece of API magic will be very trivial to use, although it usually requires some developer knowledge and use of specific types, functions or macros.
After a little study, I see my last post is unclear, and I called some things by the wrong name. So I'll try one more time. I don't claim to be right, but I think this scheme may work.
As I understand the situation, an API is a collections of function calls for a certain set of services. I think one of them is called CoreAudio, for example, and OS X has a bunch of them. The set of function calls for an API are kept in a library for use by applications. Right now, these libraries are 32-bit for 32-bit applications. For running 64-bit applications, there would normally be another bunch of libraries that are 64-bit. Each 64-bit set of function call works in 64-bit address space, while each 32-bit set works in 32-bit address space.
Today, Apple likely has some 64-bit APIs, which may come from BSD 5 if I understand correctly. However, most of the Apple grown APIs are only available in as 32-bit. The special bridge hardware in the 970 allows a software bridge to pass things back and forth between the 64-bit application space and the 32-bit functions. And this is what much of this discussion is about. What is the impact on those who program for Panther when they make 64-bit applications? How do they interface with the 32-bit APIs?
Okay, here is the idea. Apple simply provides all the 64-bit API libraries for the developers. There will be two libraries, giving two sets of function calls, for each and every API. One 64-bit and the other 32-bit. Now, to be able to do this in a reasonable time frame, Apple will use the bridge in many of these APIs. The set of function calls for such an API would be a set of dummy interfaces that call the corresponding 32-bit function, making use of the bridge hardware and passing things between different address spaces.
If this scheme can be made to work, it has advantages. APIs can be updated one at a time, when 64-bit code for these functions is available. Also, it is completely transparent to developers. They use 64-bit function calls right from the start. Who cares what is in the library, whether it is working with 64-bit code or using the bridge hardware? Lastly, since nothing will be in 64-bit applications relating to 32-bit APIs, future versions of OS X will not need to take care of legacy 64-bit applications.
Now, if such a scheme will not work it's a shame, but I'll gladly accept the realities of the computer world.
After a little study, I see my last post is unclear, and I called some things by the wrong name. So I'll try one more time. I don't claim to be right, but I think this scheme may work...
There is a problem that you are overlooking, and I'll take another shot at explaining it.
Many functions in an API take a memory location as a parameter. This can be the location of some input data, or a location for output data to be placed. In a 32-bit application there are only ~4 billion possible locations that an application can specify, and these happen to be the same ~4 billion locations that the library understands. In a 64-bit app there are 2^64 locations that the app can specify, and a 64-bit library can understand all 2^64 of them.
The problem arises when the 64-bit app can specify any of 2^64 locations, but the 32-bit library only knows about 2^32 locations. Somehow the application must restrict itself to using only the 2^32 locations that the library can see.
The 32-bit library can understand any address from 0 to 4294967295, and if the 64-bit app passes one of those locations to the library then everything is fine. If the app passes in any location from 4294967296 to ~18446744070000000000 then the library cannot access that location. This means for things to work properly, the application must take care to use one of the smaller addresses and it is a mechanism to control the selection of address that Apple will likely provide.
The hardware bridge in the 970 is a mechanism to allow 32-bit mode code to correctly translate the addresses it gets while running in a 64-bit address space. Normally 32-bit mode code doesn't run in a 64-bit address space, but the 970 has this bridge to ensure that it works properly.
This function opens a file. The parameters are two strings, the first is the file name (like "/Users/synp/Desktop/myfile.txt") and the second is the mode ("r" for read, "w" for write). The function returns a pointer which is called a "file handle".
In a 32-bit system, all these pointers are 32-bit. In a 64-bit system, they are 64-bit.
Since Panther will be 32-bit, we need some kind of software bridge, known as "glue code". Here is a simple way I would code the 64-bit fopen. I'm assuming I have a malloc32 function that behaves like the regular malloc, but always allocates small addresses.
Of course, a real implementation will have more error-checking, but that's about it. The good thing is that a developer doesn't need to think about it. It is up to Apple to make this glue code.
Of course, a real implementation will have more error-checking, but that's about it. The good thing is that a developer doesn't need to think about it. It is up to Apple to make this glue code.
Three problems here (at least):
1) You don't always know the size of the things you are pointing at, and sometimes they are things that contain other pointers so copying them is non-trivial.
2) Sometimes the location is important for more than just the duration of the function. Example: if you are establishing a communications buffer that both caller and callee will repeatedly access. If you copied it invisibly they wouldn't be using the same buffer.
3) This would be extremely slow! Apple is putting a lot of emphasis on speed, and doing this would put them under a big disadvantage.
No, the better solution is to give the user "malloc32" and make sure that they follow the rule that says they must use that if using a 32-bit API. The API can both check the pointers and mode switch internally.
No. Unless you're a developer writing something with a peculiar need for 64-bitness you won't.
Any 64-bit application will not run on any currently delivering hardware, nor any iMac, PowerBook, eMac or iBook. Even PowerMacs will still be available in G4 versions for the near future. Adobe, Microsoft and all the rest will not produce a 64-bit up unless either:
1. There is a real need, or
2. Even the iBooks have had a G5 for the last two years.
1 is true for very few. 2 will not be true for about 4 years.
Not true in the slightest. The iBook is not Adobe's suggested hardware setup. Also, Adobe is willing to maintain different builds of their code for different hardware. THey support both Altivec and non Altivec machines. Adobe supported both PPC and 68k machines. Adobe will not wait until 64bit CPU's are everywhere before unveiling a 64 bit photoshop. At the very least, Adobe has a wonderful financial incentive to come out with 64 bit versions of their apps: instant customer upgrades. Adobe makes a killing off of their apps without a significant rewrite of their code. Low development costs and high demand make for good profit.
And besides, there is a real need. People do want to address lots of RAM. 4GB just doesn't cut it for some applications (mine in particular).
Comments
Originally posted by rickag
synp
Thank you for the explaination, and I read your response 4 or 5 times trying to understand, but I just do not have the background. I kind of get a feel for what you and Programmer are saying but really don't understand.
Don't sweat it. I got my first job as a system guy in '94. That was a mainframe computer I was supposed to work with. My boss made me read a book about the system's architecture and memory management, paging and all this stuff. It took about 3-4 times reading that book (with nice IBM pictures) to get it, and that was with a degree in computer science and about 10 years of geekness.
Reading that thing you quoted took me back. IBM apparently uses the same terms for the PPC range that it uses for the mainframe processors: PTE, STE, TLB, they're all there.
The short version of the thing is this: An OS can work in either of two modes: 32-bit or 64-bit.
When working in 32-bit, all programs work in 32-bit and everything's the same as it was in G4. To work in this mode, the OS has to execute a few machine instructions at startup. Even when working in 32-bit the OS can use more than 4GB of RAM (up to 16) as long as each programs gets only 4. IMO, this is what's in Smeagol.
When working in 64-bit, programs can be either 32-bit or 64-bit. To work in this mode the OS has to execute some machine instructions at startup and make segment and page tables in the new format. I believe that is what Panther does. To allow 64-bit apps to really run, you need to have 64-bit APIs. I don't know how much of that Apple has done.
Originally posted by synp
When working in 64-bit, programs can be either 32-bit or 64-bit. To work in this mode the OS has to execute some machine instructions at startup and make segment and page tables in the new format. I believe that is what Panther does. To allow 64-bit apps to really run, you need to have 64-bit APIs. I don't know how much of that Apple has done.
You're missing what the special "bridge" hardware does, however. It allows 32-bit software that happens to find itself in a 64-bit address space to work properly. Basically the "lowest" 4 GB are setup so that 32-bit software thinks it is in a standard 32-bit address space. This allows a 64-bit app to call the 32-bit software as long as it follows a few rules (i.e. keep the pointers where the 32-bit software can see them, and mode switch when calling into/returning from the 32-bit code).
Originally posted by Programmer
You're missing what the special "bridge" hardware does, however. It allows 32-bit software that happens to find itself in a 64-bit address space to work properly. . .
I wonder about the impact of this bridge hardware on the software. For now, there will be the need to use the bridge for 64-bit applications. Later, when the OS has 64-bit APIs, maybe in Mac OS 10.4, the bridge will not be necessary. I don't understand enough to know how this will affect applications, and I see several possible impacts.
1. Maybe no visible impact. Application will automatically use the bridge if necessary. However, I suspect such a programming technique would be inefficient, and have too much overhead.
2. Upon restart, an application will check the OS to determine whether to load the bridge code.
3. Upon installation, an application will install the bridge version only for OS 10.3. This requires reinstalling applications when updating from OS 10.3 to 10.4.
4. (This one cannot be true.) The application checks the hardware and always uses the bridge for the 970.
Call me a worry wart, but I wonder about these things.
The bridge will remain in use until all APIs have 64-bit versions. At that point old software can be supported by keeping a "bridged" version of the API around that just turns around and calls the new 64-bit API. It will introduce a small amount of overhead, but it will be completely insignificant compared to the overhead in the 68K->PPC transition.
Don't sweat it.
Originally posted by Programmer
. . . The bridge will remain in use until all APIs have 64-bit versions. At that point old software can be supported by keeping a "bridged" version of the API around that just turns around and calls the new 64-bit API. . .
Ah ha! Thank you. It is yet another alternative, and it makes more sense than all of mine. If I understand correctly, developers today will not even have to consider 64-bit APIs. They will write all 64-bit applications just using bridge hardware. When Mac OS 10.4 arrives, it will (likely) have 64-bit APIs plus a means to run older 64-bit applications, as you suggested. At that time, developer can begin to use 64-bit APIs, and these applications will require OS 10.4 or higher to run. This is not too different from applications now that require OS 10.2, and will not run on 10.1. You're right. Apple is good at this kind of thing.
Originally posted by snoopy
Ah ha! Thank you. It is yet another alternative, and it makes more sense than all of mine. If I understand correctly, developers today will not even have to consider 64-bit APIs. They will write all 64-bit applications just using bridge hardware. When Mac OS 10.4 arrives, it will (likely) have 64-bit APIs plus a means to run older 64-bit applications, as you suggested. At that time, developer can begin to use 64-bit APIs, and these applications will require OS 10.4 or higher to run. This is not too different from applications now that require OS 10.2, and will not run on 10.1. You're right. Apple is good at this kind of thing.
No. Unless you're a developer writing something with a peculiar need for 64-bitness you won't.
Any 64-bit application will not run on any currently delivering hardware, nor any iMac, PowerBook, eMac or iBook. Even PowerMacs will still be available in G4 versions for the near future. Adobe, Microsoft and all the rest will not produce a 64-bit up unless either:
1. There is a real need, or
2. Even the iBooks have had a G5 for the last two years.
1 is true for very few. 2 will not be true for about 4 years.
Now I guess they should have banned me rather than just shut off posting priviledges, because kickaha and Amorph definitely aren't going to like being called to task when they thought they had it all ignored *cough* *cough* I mean under control. Just a couple o' tools.
Don't worry, as soon as my work resetting my posts is done I'll disappear forever.
Originally posted by AirSluf
. . . I wouldn't worry about the "bridge" either. Nothing I have seen or read leads me to think it will affect or even be accessible to Userland in the least. . .
If I understand what Programmer has been saying, those who develop 64-bit applications will need the bridge to call 32-bit APIs in Panther.
What I do not know, now that you mention it, is whether Panther code will do it all automatically. My gut feeling is that such an approach would not work when you consider future versions of Mac OS, which will have 64-bit APIs. I think developers will have to include something relating to the bridge today, for making 64-bit applications. That is pure opinion however. I'll bow to the facts when they are presented.
Originally posted by synp
No. Unless you're a developer writing something with a peculiar need for 64-bitness you won't. . .
Well, 64-bitness, and the bridge, was the only topic in my postings. The bridge is totally unnecessary for 32-bit applications. And yes, I agree with you that most applications will remain 32-bit.
Originally posted by snoopy
What I do not know, now that you mention it, is whether Panther code will do it all automatically. My gut feeling is that such an approach would not work when you consider future versions of Mac OS, which will have 64-bit APIs. I think developers will have to include something relating to the bridge today, for making 64-bit applications. That is pure opinion however. I'll bow to the facts when they are presented.
As I alluded to above, I think this as well -- developers who are writing 64-bit code and want to call a 32-bit API will need to do something slightly special to do so. This something special is probably quite minor like using a special memory allocator function for anything that is going to be passed to the 32-bit API.
Now I guess they should have banned me rather than just shut off posting priviledges, because kickaha and Amorph definitely aren't going to like being called to task when they thought they had it all ignored *cough* *cough* I mean under control. Just a couple o' tools.
Don't worry, as soon as my work resetting my posts is done I'll disappear forever.
Originally posted by Programmer
. . . The bridge will remain in use until all APIs have 64-bit versions. At that point old software can be supported by keeping a "bridged" version of the API around that just turns around and calls the new 64-bit API. . .
It just occurred to me that AirSluf could be correct, that developers need not be concerned about the bridge. What if Apple took the opposite approach to the one you suggest. What if Apple put the 64-bit API calls into Panther, but there would be no 64-bit API code. Rather, these APIs would simply activate the bridge and make an appropriate 32-bit API call. Off hand, I don't see why this would not work.
The advantage, if it can be done, is that developers need know nothing about the bridge, and future versions of OS X would not need to have special code to take care of older software. It looks like a cleaner approach, if it works. Possible? (I know, I should simply wait to see what Apple really does.)
Now I guess they should have banned me rather than just shut off posting priviledges, because kickaha and Amorph definitely aren't going to like being called to task when they thought they had it all ignored *cough* *cough* I mean under control. Just a couple o' tools.
Don't worry, as soon as my work resetting my posts is done I'll disappear forever.
Originally posted by AirSluf
True, there are ways to make this quite painless though. Almost to the point of seeming transparent and not "special" in any appreciable way until you start getting into performance considerations.
That's what I've been saying. This little piece of API magic will be very trivial to use, although it usually requires some developer knowledge and use of specific types, functions or macros.
As I understand the situation, an API is a collections of function calls for a certain set of services. I think one of them is called CoreAudio, for example, and OS X has a bunch of them. The set of function calls for an API are kept in a library for use by applications. Right now, these libraries are 32-bit for 32-bit applications. For running 64-bit applications, there would normally be another bunch of libraries that are 64-bit. Each 64-bit set of function call works in 64-bit address space, while each 32-bit set works in 32-bit address space.
Today, Apple likely has some 64-bit APIs, which may come from BSD 5 if I understand correctly. However, most of the Apple grown APIs are only available in as 32-bit. The special bridge hardware in the 970 allows a software bridge to pass things back and forth between the 64-bit application space and the 32-bit functions. And this is what much of this discussion is about. What is the impact on those who program for Panther when they make 64-bit applications? How do they interface with the 32-bit APIs?
Okay, here is the idea. Apple simply provides all the 64-bit API libraries for the developers. There will be two libraries, giving two sets of function calls, for each and every API. One 64-bit and the other 32-bit. Now, to be able to do this in a reasonable time frame, Apple will use the bridge in many of these APIs. The set of function calls for such an API would be a set of dummy interfaces that call the corresponding 32-bit function, making use of the bridge hardware and passing things between different address spaces.
If this scheme can be made to work, it has advantages. APIs can be updated one at a time, when 64-bit code for these functions is available. Also, it is completely transparent to developers. They use 64-bit function calls right from the start. Who cares what is in the library, whether it is working with 64-bit code or using the bridge hardware? Lastly, since nothing will be in 64-bit applications relating to 32-bit APIs, future versions of OS X will not need to take care of legacy 64-bit applications.
Now, if such a scheme will not work it's a shame, but I'll gladly accept the realities of the computer world.
Originally posted by snoopy
After a little study, I see my last post is unclear, and I called some things by the wrong name. So I'll try one more time. I don't claim to be right, but I think this scheme may work...
There is a problem that you are overlooking, and I'll take another shot at explaining it.
Many functions in an API take a memory location as a parameter. This can be the location of some input data, or a location for output data to be placed. In a 32-bit application there are only ~4 billion possible locations that an application can specify, and these happen to be the same ~4 billion locations that the library understands. In a 64-bit app there are 2^64 locations that the app can specify, and a 64-bit library can understand all 2^64 of them.
The problem arises when the 64-bit app can specify any of 2^64 locations, but the 32-bit library only knows about 2^32 locations. Somehow the application must restrict itself to using only the 2^32 locations that the library can see.
The 32-bit library can understand any address from 0 to 4294967295, and if the 64-bit app passes one of those locations to the library then everything is fine. If the app passes in any location from 4294967296 to ~18446744070000000000 then the library cannot access that location. This means for things to work properly, the application must take care to use one of the smaller addresses and it is a mechanism to control the selection of address that Apple will likely provide.
The hardware bridge in the 970 is a mechanism to allow 32-bit mode code to correctly translate the addresses it gets while running in a 64-bit address space. Normally 32-bit mode code doesn't run in a 64-bit address space, but the 970 has this bridge to ensure that it works properly.
FILE *fopen(const char *filename, const char *mode);
This function opens a file. The parameters are two strings, the first is the file name (like "/Users/synp/Desktop/myfile.txt") and the second is the mode ("r" for read, "w" for write). The function returns a pointer which is called a "file handle".
In a 32-bit system, all these pointers are 32-bit. In a 64-bit system, they are 64-bit.
Since Panther will be 32-bit, we need some kind of software bridge, known as "glue code". Here is a simple way I would code the 64-bit fopen. I'm assuming I have a malloc32 function that behaves like the regular malloc, but always allocates small addresses.
<!-- php buffer start --><code><span style="color: #000000">
<span style="color: #0000BB">FILE </span><span style="color: #007700">*</span><span style="color: #0000BB">fopen64</span><span style="color: #007700">(const </span><span style="color: #0000BB">char </span><span style="color: #007700">*</span><span style="color: #0000BB">filename</span><span style="color: #007700">, const </span><span style="color: #0000BB">char </span><span style="color: #007700">*</span><span style="color: #0000BB">mode</span><span style="color: #007700">)
<br />{
<br /> </span><span style="color: #0000BB">char </span><span style="color: #007700">*</span><span style="color: #0000BB">fn32</span><span style="color: #007700">, *</span><span style="color: #0000BB">mode32</span><span style="color: #007700">;
<br /> </span><span style="color: #0000BB">u_int32 fp</span><span style="color: #007700">;
<br /> </span><span style="color: #0000BB">fn32</span><span style="color: #007700">=</span><span style="color: #0000BB">malloc32</span><span style="color: #007700">(</span><span style="color: #0000BB">strlen</span><span style="color: #007700">(</span><span style="color: #0000BB">filename</span><span style="color: #007700">)+</span><span style="color: #0000BB">1</span><span style="color: #007700">);
<br /> </span><span style="color: #0000BB">strcpy</span><span style="color: #007700">(</span><span style="color: #0000BB">fn32</span><span style="color: #007700">, </span><span style="color: #0000BB">filename</span><span style="color: #007700">);
<br /> </span><span style="color: #0000BB">mode32</span><span style="color: #007700">=</span><span style="color: #0000BB">malloc32</span><span style="color: #007700">(</span><span style="color: #0000BB">strlen</span><span style="color: #007700">(</span><span style="color: #0000BB">mode</span><span style="color: #007700">)+</span><span style="color: #0000BB">1</span><span style="color: #007700">);
<br /> </span><span style="color: #0000BB">strcpy</span><span style="color: #007700">(</span><span style="color: #0000BB">mode32</span><span style="color: #007700">, </span><span style="color: #0000BB">mode</span><span style="color: #007700">);
<br />
<br /> </span><span style="color: #0000BB">fp</span><span style="color: #007700">=</span><span style="color: #0000BB">fopen32</span><span style="color: #007700">((</span><span style="color: #0000BB">u_int32</span><span style="color: #007700">)</span><span style="color: #0000BB">fn32</span><span style="color: #007700">, (</span><span style="color: #0000BB">u_int32</span><span style="color: #007700">)</span><span style="color: #0000BB">mode32</span><span style="color: #007700">);
<br /> return (</span><span style="color: #0000BB">FILE</span><span style="color: #007700">*)</span><span style="color: #0000BB">fp</span><span style="color: #007700">;
<br />}
<br /></span><span style="color: #0000BB"></span>
</span>
Originally posted by synp
Of course, a real implementation will have more error-checking, but that's about it. The good thing is that a developer doesn't need to think about it. It is up to Apple to make this glue code.
Three problems here (at least):
1) You don't always know the size of the things you are pointing at, and sometimes they are things that contain other pointers so copying them is non-trivial.
2) Sometimes the location is important for more than just the duration of the function. Example: if you are establishing a communications buffer that both caller and callee will repeatedly access. If you copied it invisibly they wouldn't be using the same buffer.
3) This would be extremely slow! Apple is putting a lot of emphasis on speed, and doing this would put them under a big disadvantage.
No, the better solution is to give the user "malloc32" and make sure that they follow the rule that says they must use that if using a 32-bit API. The API can both check the pointers and mode switch internally.
Originally posted by synp
No. Unless you're a developer writing something with a peculiar need for 64-bitness you won't.
Any 64-bit application will not run on any currently delivering hardware, nor any iMac, PowerBook, eMac or iBook. Even PowerMacs will still be available in G4 versions for the near future. Adobe, Microsoft and all the rest will not produce a 64-bit up unless either:
1. There is a real need, or
2. Even the iBooks have had a G5 for the last two years.
1 is true for very few. 2 will not be true for about 4 years.
Not true in the slightest. The iBook is not Adobe's suggested hardware setup. Also, Adobe is willing to maintain different builds of their code for different hardware. THey support both Altivec and non Altivec machines. Adobe supported both PPC and 68k machines. Adobe will not wait until 64bit CPU's are everywhere before unveiling a 64 bit photoshop. At the very least, Adobe has a wonderful financial incentive to come out with 64 bit versions of their apps: instant customer upgrades. Adobe makes a killing off of their apps without a significant rewrite of their code. Low development costs and high demand make for good profit.
And besides, there is a real need. People do want to address lots of RAM. 4GB just doesn't cut it for some applications (mine in particular).