Not only that you doubled the RAM and SSD -- and you can access both over the super-fast S-Beam (NFC - WiFi Direct) connect with a 6-10 access time and Hi-Speed battery drain.
Is it possible that, while manufacturing and testing the A7, Sammy didn't know it was 64-bit?
Very unlikely.
Unless the die size increases significantly (and it hasn't), you can't really tell much about a chip as you manufacture it.
I could look at a wafer and tell you if it's DRAM, FLASH, logic or an image sensor, but not much beyond that.
There's not a cat in hells chance Apple will have allowed Samsung to do the probe testing while they were developing the chip. Furthermore, while a lot of people here dislike Samsung, and for very good reason, they have dropped billions of dollars trying to get into foundry manufacturing. If customers got even a sniff that Samsungs foundry would steal their designs and share with other Samsungs divisions, they would lose all their foundry business within six months.
They would need to sell a hell of a lot of phones with the stolen tech to make the $5bn+ fabs that are sat idle worth it.......
You got all wrong, Apple is also doing business with TSMC. Apple initially invested in ARM and licence ARM design ever since the Newton back in the early 90. Intrinsity was the R&D shop for Samsung ARM processor until Apple bought them in 2010, and now part of the internal team at Apple responsible for the Ax and Mx development. Beside saying there is absolutely no need for 64 bit on mobile is as dump as Bill Gate infamous quote: 640ko is more than enough for anyone. I'm pretty sure Apple internal developers already put the 64 bit CPU in good use for video and image processing on iOS.
Sure, the rumor has been around for at least 3-4 years now; with no confirmation with Apple or TSMC.
Yes, Apple took a large stake in ARM Ltd in the early 90's under Scully, but Jobs sold them all for a huge loss in 1998 after his return.
Intrinsity was an independent company who developed low-power/high-performance technology, most notable for F14. The ARM SOCs used in the first two generations of Apple iPhones were vanilla Samsung SOCs -- the A4 was the first SOC Samsung collaborated with Intrinsity to compete with Qualcomm.
Sure, perhaps one day when the iPhone comes with 8TB of memory or storage with a decent sized display. Until then, this 64bit brouhaha is nothing more than a marketing ploy.
Samsung are an embarrassing company. I'm surprised more people in the western world buy into their garbage.
I've worried about Samsung products in my Apple hardware ever since I put their 256k memory chips into my Apple 2. They would always fail the first time I booted the system.
Intrinsity was an independent company who developed low-power/high-performance technology, most notable for F14. The ARM SOCs used in the first two generations of Apple iPhones were vanilla Samsung SOCs -- the A4 was the first SOC Samsung collaborated with Intrinsity to compete with Qualcomm.
Apple started to build the internal team for designing a custom ARM back in 2008 with the acquisition of P.A. Semi, Intrinsity team helped for the design of the A4 and then being acquired by Apple before sending the A4 design to production. Samsung as not be implicated into the A4 design.
Quote:
Sure, perhaps one day when the iPhone comes with 8TB of memory or storage with a decent sized display. Until then, this 64bit brouhaha is nothing more than a marketing ploy.
I don't know from how long you are using a computer, but I've heard those denial for so many time before. My first mac was 24/32 bit (not 32 bit clean) and the A7 will be my third transition to 64bit platform (other was the G5 and Intel C2D). And at each new generation, I hear people having the exact same critics as yours,
You're narrowing you mind on the over 4GB limit which is merely one consequence of 64 bit addressing. Just like the G5 or the Athlon 64 before, going 64bit will bring performance boost on many levels which every apps gain benefit from things like doubling internal I/O bandwidth, we don't know yet all the specs of the A7, no one as got a chance buy one yet. I can't wait to read Chipworks analysis.
True you need to optimize the software to get it going with the hardware something apple does well another copy!
Correction: True you need to optimize your software to get most benefits of a new platform, also true most softwares gain some benefits without being optimize for a new platform.
If we where talking about an Apps, of course Samsung could ported them self. But the issue here is more than make android run on a 64 bit CPU, you need to port the IDE and developer tool and gives access to those tool, Samsung doesn't control the Android ecosystem, they can't bypass Google and goes alone without Google for distributing developers tools.
Beside no other OS than OSX as capitalize on multiple arch binary, since Android apps can be Java apps or NDK its even more difficult without braking compatibility to come out with a 32/64 bit universal apps systems. Even Microsoft doesn't comes out with a solution as good as OSX.
Agreed. Not only do they not control the IDE, the IDE doesn't have a clue on what architectures are coming out next week (in theory), and if they did, they'd have to compromise across the 20 odd HW variations to make them all work.
The key on making binary architectures work, is to control the software, and design the hardware to exploit it. And then Visa Versa. Apple is doing that in spades. Microsoft… maybe in 20 years.
32 bit OSes have the ability to see more than 4GB of RAM, however, many can't because of restrictions placed on them by the OS vendor/maker
The Intel PAE features enable 32 bit CPU to address more than 4GB of physical ram. While most Linux distribution and every Intel version of OSX support this feature, Microsoft artificially limit the functionality to high-end Windows Server Datacenter licence only.
Samsung does software.. Haven't you seen the Touch Wiz / Tizen ?
True they are all super shitty.
Yeah, I know,
Samsung is does software at the same level as other asian hardware maker, I don't consider much a replacement shell as high grade software engineering, beside Samsung development team are Indians sweatshop, not OS architects.
Since the only legitimate way to code on iOS apps is thru the high level Objective-C language, developer never get down to the silicon assembly, and like any POSIX OS, porting an apps on different arch for the same OS only required a recompilation of the same code. Xcode IDE makes things easier by making multi-segment executable, this tech doesn't yet exist on Windows, Linux or Android
Now, I will definitely disagree on the Objective-C part. Actually, Apple provides quite a nicely structured hierarchy of APIs.
Low-level - pure C API and libraries
Mid-level - CoreFoundation, still C API, wrapping and extending lower-level APIs.
High-level - Cocoa/Objective-C wrappers and extensions of mid-level APIs.
This structure actually makes it very easy for a developer to add code at any level and seamleslly make it work with all other levels. That is something I've never seen on other platforms. Apple provides greater consistency than anyone else. Even C and C++ libraries are totally inconsistent compared to Apple's approach.
And that consistency actually makes transitioning between 32-bit and 64-bit architectures easy, even when talking about low-level C code.
Now, I will definitely disagree on the Objective-C part. Actually, Apple provides quite a nicely structured hierarchy of APIs.
Low-level - pure C API and libraries
Mid-level - CoreFoundation, still C API, wrapping and extending lower-level APIs.
High-level - Cocoa/Objective-C wrappers and extensions of mid-level APIs.
This structure actually makes it very easy for a developer to add code at any level and seamleslly make it work with all other levels. That is something I've never seen on other platforms. Apple provides greater consistency than anyone else. Even C and C++ libraries are totally inconsistent compared to Apple's approach.
And that consistency actually makes transitioning between 32-bit and 64-bit architectures easy, even when talking about low-level C code.
Thank you clearing this up for me. I was much more old school in my reply to TheOtherGeoff about getting done to sillicon with assembly. Still the only legitimate way to create iOS apps is thru pure objective-C or wrapping C or C++ code in objective-C project, which provide like you said a much more consistent IDE.
Thank you clearing this up for me. I was much more old school in my reply to TheOtherGeoff about getting done to sillicon with assembly. Still the only legitimate way to create iOS apps is thru pure objective-C or wrapping C or C++ code in objective-C project, which provide like you said a much more consistent IDE.
Well, there are a few alternatives: MonoTouch and Apache Cordova. I think there are others, but who cares
Comments
Brilliant!
Samsung: "But this one goes to eleven!"
Samsung: "We're going to start our OWN 64 bit CPU, with hookers, and blackjack!"
Is it possible that, while manufacturing and testing the A7, Sammy didn't know it was 64-bit?
Very unlikely.
Unless the die size increases significantly (and it hasn't), you can't really tell much about a chip as you manufacture it.
I could look at a wafer and tell you if it's DRAM, FLASH, logic or an image sensor, but not much beyond that.
There's not a cat in hells chance Apple will have allowed Samsung to do the probe testing while they were developing the chip. Furthermore, while a lot of people here dislike Samsung, and for very good reason, they have dropped billions of dollars trying to get into foundry manufacturing. If customers got even a sniff that Samsungs foundry would steal their designs and share with other Samsungs divisions, they would lose all their foundry business within six months.
They would need to sell a hell of a lot of phones with the stolen tech to make the $5bn+ fabs that are sat idle worth it.......
You got all wrong, Apple is also doing business with TSMC. Apple initially invested in ARM and licence ARM design ever since the Newton back in the early 90. Intrinsity was the R&D shop for Samsung ARM processor until Apple bought them in 2010, and now part of the internal team at Apple responsible for the Ax and Mx development. Beside saying there is absolutely no need for 64 bit on mobile is as dump as Bill Gate infamous quote: 640ko is more than enough for anyone. I'm pretty sure Apple internal developers already put the 64 bit CPU in good use for video and image processing on iOS.
Sure, the rumor has been around for at least 3-4 years now; with no confirmation with Apple or TSMC.
Yes, Apple took a large stake in ARM Ltd in the early 90's under Scully, but Jobs sold them all for a huge loss in 1998 after his return.
Intrinsity was an independent company who developed low-power/high-performance technology, most notable for F14. The ARM SOCs used in the first two generations of Apple iPhones were vanilla Samsung SOCs -- the A4 was the first SOC Samsung collaborated with Intrinsity to compete with Qualcomm.
Sure, perhaps one day when the iPhone comes with 8TB of memory or storage with a decent sized display. Until then, this 64bit brouhaha is nothing more than a marketing ploy.
Samsung are an embarrassing company. I'm surprised more people in the western world buy into their garbage.
I've worried about Samsung products in my Apple hardware ever since I put their 256k memory chips into my Apple 2. They would always fail the first time I booted the system.
Sure, the rumor has been around for at least 3-4 years now; with no confirmation with Apple or TSMC.
Yes, Apple took a large stake in ARM Ltd in the early 90's under Scully, but Jobs sold them all for a huge loss in 1998 after his return.
You got great imagination, Apple didn't sold all participation in ARM Holdings and they didn't sold at loss: http://news.cnet.com/Short-Take-Apple-sells-ARM-shares/2110-1001_3-221149.html
Intrinsity was an independent company who developed low-power/high-performance technology, most notable for F14. The ARM SOCs used in the first two generations of Apple iPhones were vanilla Samsung SOCs -- the A4 was the first SOC Samsung collaborated with Intrinsity to compete with Qualcomm.
Apple started to build the internal team for designing a custom ARM back in 2008 with the acquisition of P.A. Semi, Intrinsity team helped for the design of the A4 and then being acquired by Apple before sending the A4 design to production. Samsung as not be implicated into the A4 design.
I don't know from how long you are using a computer, but I've heard those denial for so many time before. My first mac was 24/32 bit (not 32 bit clean) and the A7 will be my third transition to 64bit platform (other was the G5 and Intel C2D). And at each new generation, I hear people having the exact same critics as yours,
You're narrowing you mind on the over 4GB limit which is merely one consequence of 64 bit addressing. Just like the G5 or the Athlon 64 before, going 64bit will bring performance boost on many levels which every apps gain benefit from things like doubling internal I/O bandwidth, we don't know yet all the specs of the A7, no one as got a chance buy one yet. I can't wait to read Chipworks analysis.
He's mostly talk, because he's a tool.
"Oh, Man! I got Osborned!!!" - Samsung CEO
True you need to optimize the software to get it going with the hardware something apple does well another copy!
Correction: True you need to optimize your software to get most benefits of a new platform, also true most softwares gain some benefits without being optimize for a new platform.
With the RAM increases nearing 4 GBs they just about have to go 64-bit.
32 bit OSes have the ability to see more than 4GB of RAM, however, many can't because of restrictions placed on them by the OS vendor/maker
If we where talking about an Apps, of course Samsung could ported them self. But the issue here is more than make android run on a 64 bit CPU, you need to port the IDE and developer tool and gives access to those tool, Samsung doesn't control the Android ecosystem, they can't bypass Google and goes alone without Google for distributing developers tools.
Beside no other OS than OSX as capitalize on multiple arch binary, since Android apps can be Java apps or NDK its even more difficult without braking compatibility to come out with a 32/64 bit universal apps systems. Even Microsoft doesn't comes out with a solution as good as OSX.
Agreed. Not only do they not control the IDE, the IDE doesn't have a clue on what architectures are coming out next week (in theory), and if they did, they'd have to compromise across the 20 odd HW variations to make them all work.
The key on making binary architectures work, is to control the software, and design the hardware to exploit it. And then Visa Versa. Apple is doing that in spades. Microsoft… maybe in 20 years.
32 bit OSes have the ability to see more than 4GB of RAM, however, many can't because of restrictions placed on them by the OS vendor/maker
The Intel PAE features enable 32 bit CPU to address more than 4GB of physical ram. While most Linux distribution and every Intel version of OSX support this feature, Microsoft artificially limit the functionality to high-end Windows Server Datacenter licence only.
One thing wrong with your view... Samsung doesnt do software, which is 50% of the user experience.
Samsung does software.. Haven't you seen the Touch Wiz / Tizen ?
True they are all super shitty.
Samsung does software.. Haven't you seen the Touch Wiz / Tizen ?
True they are all super shitty.
Yeah, I know,
Samsung is does software at the same level as other asian hardware maker, I don't consider much a replacement shell as high grade software engineering, beside Samsung development team are Indians sweatshop, not OS architects.
http://www.linkedin.com/vsearch/p?orig=TSEO_SN&company=samsung+software+center&companyScope=C&title=chief+engineer&trk=TSEO_SN
When Samsung offers its annual buy one Galaxy product get one free promotion then you will have 64 bits.
Since the only legitimate way to code on iOS apps is thru the high level Objective-C language, developer never get down to the silicon assembly, and like any POSIX OS, porting an apps on different arch for the same OS only required a recompilation of the same code. Xcode IDE makes things easier by making multi-segment executable, this tech doesn't yet exist on Windows, Linux or Android
Now, I will definitely disagree on the Objective-C part. Actually, Apple provides quite a nicely structured hierarchy of APIs.
Low-level - pure C API and libraries
Mid-level - CoreFoundation, still C API, wrapping and extending lower-level APIs.
High-level - Cocoa/Objective-C wrappers and extensions of mid-level APIs.
This structure actually makes it very easy for a developer to add code at any level and seamleslly make it work with all other levels. That is something I've never seen on other platforms. Apple provides greater consistency than anyone else. Even C and C++ libraries are totally inconsistent compared to Apple's approach.
And that consistency actually makes transitioning between 32-bit and 64-bit architectures easy, even when talking about low-level C code.
Now, I will definitely disagree on the Objective-C part. Actually, Apple provides quite a nicely structured hierarchy of APIs.
Low-level - pure C API and libraries
Mid-level - CoreFoundation, still C API, wrapping and extending lower-level APIs.
High-level - Cocoa/Objective-C wrappers and extensions of mid-level APIs.
This structure actually makes it very easy for a developer to add code at any level and seamleslly make it work with all other levels. That is something I've never seen on other platforms. Apple provides greater consistency than anyone else. Even C and C++ libraries are totally inconsistent compared to Apple's approach.
And that consistency actually makes transitioning between 32-bit and 64-bit architectures easy, even when talking about low-level C code.
Thank you clearing this up for me. I was much more old school in my reply to TheOtherGeoff about getting done to sillicon with assembly. Still the only legitimate way to create iOS apps is thru pure objective-C or wrapping C or C++ code in objective-C project, which provide like you said a much more consistent IDE.
Thank you clearing this up for me. I was much more old school in my reply to TheOtherGeoff about getting done to sillicon with assembly. Still the only legitimate way to create iOS apps is thru pure objective-C or wrapping C or C++ code in objective-C project, which provide like you said a much more consistent IDE.
Well, there are a few alternatives: MonoTouch and Apache Cordova. I think there are others, but who cares