P.A. Semiconductor to focus on the iPhone
June 11th, 2008The New York Times reports that P.A. Semicondutor will be making systems on a chip for the iPhone platform. So I got this wrong.
The New York Times reports that P.A. Semicondutor will be making systems on a chip for the iPhone platform. So I got this wrong.
Slides, a mac like tool in JS. It uses Objective-J, a Objective-C like language. And according to the authors, the framework will be open-sourced.
Intel’s managing director responsible for Germany has apparently revealed that there will be 2 iPhones, one based on an ARM processor and the other on Intel’s Atom processor.
Perhaps this explains this WWDC picture:

(image courtesy of computer world)
As you may know, Find It! Keep It! is not yet self-supporting, so I also work part-time on a 3D geo-browser called earthscape. Its outing party was yesterday (video)
One of the applications is to help helicopter pilots (e.g. search and rescue) figure out where they are.
There’s also a desktop version which should be available real-soon-now ™. Unlike competing products, it is highly programmable in Javascript. Although there’s no Mac port yet, there is an early iPhone port.
At the time Macs started using x86 cores, an alternative to stay PowerPC was to use P.A. Semiconductor’s chip. At the time (2005), it would have been a risky move as P.A. Semiconductor didn’t yet have working silicon. Today however, Apple bought P.A. Semiconductor.
What’s interesting is that P.A. Semiconductor’s part, the PA6T, is a desktop part, not something that would fit into an I-Phone.
Wattage: The IPhone’s CPU uses quarter of a watt (it’s either a Samsung S3C6400 or a close derivative). The PA6T uses between 5 and 13 watts, and in the worst case 25W. While this is lower than an Intel desktop chip, it would take too large a battery to fit in a phone.
Memory Bus: The PA6T has two CPUs, each with its own DDR2 bus. That’s a lot of pins, and a lot of memory chips — not something that fits into a phone.
I/O: 8 PCIe controllers, 2×10Gb ethernet controllers, 4×1Gb ethernet controllers. None of this is needed by a phone.
CPU: Two 2GHz PPCs for the 5-13 Watt Core… Apparently future versions will run at 2.5 Ghz, and provide up to 8 cores on a die. Again overkill for a phone.
Although it’s possible that P.A. Semiconductor has another IPhone specific chip in the works, my guess is that the next MacBook Air will use this part. The MacBook Air uses a 20W part, and a 37W hour battery. As a rough calculation, 17W for the system, 20W for the CPU becomes 22W with a 5W CPU, and 20W for a system with a solid state drive. That gives you almost 10 hours of battery life.
This is another step in Apple’s strategy of owning the whole system, letting it chart its own course, although I expect it to continue using commodity x86 chips for lower end systems. For developers, it means we’ll be making FAT binaries for some time yet, even if it does mean more work.
The latest flutter on the internet is concern about the reflection in Dick Cheney’s glasses.
United Press International (UPI) just published a story of an expert who used the latest digital technology to conclude “In one lens of his sunglasses you can clearly tell it is a sleeved arm of Cheney or a fishing companion”.
Reddit published a link to the full-sized version two days ago (of course the comments leave much to be desired).
…I find this video rather prescient. (British humour warning).
Apple designers try 10 different mockups for each new feature. That explains a lot.
I stumbled upon the the news that the Clean compiler will support Haskell. While Haskell is not in the Beta version of Find It! Keep It!, it will be after 1.0 (see The Haskell Communities and Activities Report).
Why am I excited? Clean’s compiler produces faster code than GHC making it real competition. But in the longer term, because I personally still feel IO is an unresolved problem in Pure Lazy Functional Languages:
I don’t really like using Monads. I’m hoping that making Clean & Haskell linkable will lead to advances in this area. Perhaps some combination of Monads for some problems, and Uniqueness Typing and Implicit Parameters for other problems, will improve the situation.
When I was a child, my father would quote the Victorian era expression “Small children should be seen, not heard” when I became overly boisterous. At that time I was not sure whether or not he meant it. I do however believe it should apply to computers…
Safari’s URL and form autocompletion really irritate me: they always add their guess to the end of what I’m typing a third of a second later. That means I press enter, only to find incorrect data was added to the field, and then submitted. Others have the same complaint. Nevertheless people do want some form of autocompletion.
For Find It! Keep It! I added an almost identical interface: the same popup window, the same use of up and down keys to choose, the same ability to click or double click on a choice, but crucially, you’re always in control. Nothing is added behind your cursor until you use the up and down keys to choose a selection. Type a new character in, and your selection is cleared.
Spotlight invariably updates its window the instant before I click the file I want to open, causing me to open the wrong thing.
A different solution is to use colour to show which page contain the search term. Although it does mean more information on the screen, it lets users click on pages as soon as the search term is found. That’s what I’m doing in Find It! Keep It! when searching pages by content.
An application’s icon will bounce automatically when the application opens a modal panel if it is running in the background. It is possible for each application to remove this effect on a per-application basis. The problem then is that either one has to set a preference in each app to override default behaviour, or apps behave inconsistently. Apple could system wide preference for this to alleviate the problem.
Software Updaters are another source of interruption that I don’t believe is necessary: as long as I don’t adversely notice the change when I use the tool, I don’t need to know that it’s updated the moment I use it. Web applications change constantly, but no one complains unless they stop working. Desktop applications will, I believe, adopt a similar model. How then, will the user know about the latest improvements? By email! People are in the mood for reading things when reading their email, not when working. Apple’s Software Updater is the worst in this category: it interrupts you and then asks you to drop everything and restart your computer.
It is difficult to hold a conversation when someone continually interrupts: one can’t organize one’s thoughts while being bombarded with new information. Using a computer is a similar situation. When the user talks, the computer should just listen.