Apple to expand CPU design group beyond iPad A4
appleinsider.com
appleinsider.com
I have no doubt that Apple had Mac OS X running on Intel from day 1, as well as PowerPC. That legacy gives them a lot of flexibility in processor choices.
It came with built in Sampler, one was able to debug with Visual Studio the compiled executables (there was a converter that took the dwarf debug info and converted it CV (CodeView) compatible one for Visual Studio).
The apps looked natively on Windows (unlike GNUStep), much like Cocotron, but you were able to develop them on the system.
That to be said, Apple's OS and the underlying Foundation/AppKit/UIKit are truly hameleonic - I'm sure they can migrate easily to new platforms.
Recent news item + A bunch of tangentially related, usually revisionist details about Apple's history + Some tangentially related, laughably biased, usually revisionist shots at Microsoft/Google + (Sometimes) An insane, impossible-to-read graph/chart = Unsubstantiated conclusion that reads like a wish list for what Daniel wants Apple to do, not what the evidence shows.
He recently wrote an article explaining that he thinks Apple is going to port Cocoa to Windows and release a Windows app store: http://www.roughlydrafted.com/2010/11/12/when-will-apple-rel...
Long live the Newton!
The iPad is the Newton ///, something interesting because, unlike the original Apple ///, this one is a huge success.
But I don't see how apps like Omnifocus can make use of it.
But surely it wouldn't be too hard (where too hard means technically infeasible) to create an application based on hand-written input (Graffiti or Rosetta/Inkwell-type technologies).
That's not to say it's the optimal method of input, but either is voice. There are use cases where writing or voice may be better than typing.
But I'm guessing drawing letterforms with your finger isn't a very enjoyable input method, and most of the iPad styluses available aim at replicating a finger (since that's what most applications expect).
I just wish the character recognition could be better.
Though I believe Japanese have a system for such a thing, which they use on regular QWERTY keyboard, my sister demonstrated it to me (you basically type phonetics and it builds graphemes/characters on the fly, something like that). For that reason (and because japanese people are used to that kind of input) iOS has a qwerty (romaji) and a 10key japanese keyboards but I don't think it has a handwritten one (it has 8 different Chinese keyboards, 3 simplified [with "handwriting" and "stroke" versions] and 3 Traditional [Handwriting, pinyin, zhuyin, cangjie and stroke]).
:-)
[Near as I can tell, the only association with Newton is the use of an ARM. I sure wouldn't use NewtOS on anything modern, even as cool as NewtOS was in its day.]
And while instruction predication does let you avoid a lot of branching nearly for free in the ARM architecture it makes out of order logic much less effective because now there are a lot more dependencies between instructions. That was the reason the Alpha team decided not to use predication, even though they were familiar with the idea. Its also why the Itanium, an in order architecture, used predication.
Consumer electronics is driven by volume & price, so all we are really seeing is small, low power cores becoming acceptably fast for mainstream computing.
All that is really pretty awesome if you're designing your processor to go in order, but if you want to try out of order execution it becomes more complicated. Now you have to check every instruction to see if its predicated, and if it is you now have a new dependency on the previous arithmetic instruction even if there isn't any data dependency between the two. Of course you could argue that if you find a predicated instruction in ARM code then its replacing a branch that would be in x86 code, and that overall your job is no harder. And you could go back and forth arguing over it.
The important thing to remember, though, is the things that give the ARM ISA inherent advantages when you're making low power, in order processors aren't necessarily advantages when you're talking about high performance, high power processors.
http://www.arm.com/products/processors/cortex-a/cortex-a15.p...
A typical improvements for microarchitecture is a factor of 2, spread between different units. For example, we could speed up full word adder (most common roadblock for higher clock frequency in current CPU's) by 10 percents, add scoreboard that allow us to issue 1.3 instructions in average load, add bypass logic that allows us to cut delay by 1/5 (5 cycles for pipeline) and we get 1.11.31.2=1.72 of our previous speed.
I assume that ARM already have all those fancy bypasses and scoreboards. So how would they get that 5 times speed up?
I think it will be true for some special cases, like Javascript interpreter or video decoding. I bet on JS.
It is hard to speed up a mature architecture by five times.
It seems to me that in order for an ARM processor to be viable for something like the MacBook Air (which is already using all the easy power-reduction measures like LED backlights and SSDs), the ARM chip will have to be twice as fast and draw half as much power as an Atom.
x86 has always been predicted to fall behind competing architectures, and it's always kept up--at least for personal computers--because of the large vested interest in keeping all that x86 code running. History is littered with better-architected CPUs that couldn't beat x86. ARM survived because ARM is an embedded processor, and PPC survives as an embedded processor, but Apple's been down the road of trying to shoehorn an embedded processor design into Macs before, and ended up migrating to x86.
One of the factors that help people move across to OSX seems to be the knowledge that they can still install Windows if they need/desire. Perhaps Apple will buy Parallels and include it as part of the OS (although VMWare will have a case if they see this as being anti-competitive)?