“Application”
At which point we try to wrap up some loose threads, explain why some clock- cycles are more equal than others. And wonder about what sort of direction smartphones are really heading (if anywhere at all).
Part IV: “Application”
In part I, we looked at the how the phones are constructed. Part II and part III dealt with how the parts of the phone fit together, from an abstract point of view. And how the lack of a good philosophy on constructing these phones is a very serious problem. In this part, we’ll look more closely at how the software really is fitted on top of the phone, and what the issues in general are - as well as what the limitations and possibilities are when retrofitting devices with high level library support.
But - why would anyone want to retrofit a phone with anything, other than ring- tones and new pictures and games? Why not simply choose an up to date component array, and then directly use these for all operations? Why, for example, go through the trouble of creating an OS, when you’re intent on using the same platform forever, or otherwise to a large extent scrap the existing implementations whenever you do change platform? Now that’s a good question some of us ask ourselves very often.
And the answer typically appears to be “Youtube”. Or, that as long as a specific application exists on the phone, the rest doesn’t matter, except as a selling point. For example, “fundamental improvements to GUI customization and a re-drawn static memory handling that enable object- exchange” - who cares about that?
Another reason is that lack of variety on the market (there’s only a few chip designers), has made retrofitting devices with software- optimisations necessary. This has also given rise to an entire industry of “system on chip” designs, as well as the more “flexible” DSP (digital signal processing) solutions. Simply because the requirement to support multiple formats and standards was growing.
But why bother with the extra component arrays at all, then? Why not just use atomic instructions and high clock- speeds like any PC does now? Because the main idea on mobile devices in general is “parallelism”. To get as much done at the same time, in order to save clock- cycles or processor time and power. Which means that moving certain common operations from a time- shared “multitask”, and to pre- processed data areas independent of the bus suddenly seems like an incredibly good idea. Take a look at “DMA” on any computer, for example - you program the bus to read in chunks without interruption from the storage device, and then the OS picks up the full chunk when it’s ready. Quick and efficient, right?
Unfortunately, translating that theory to a mobile device is less successful. Since when a device performs more complex operations, with more varied instruction sets at the same time - any type of hardware- support runs into trouble, sooner or later. This is the case for even the most strict format and instruction set - simply because the memory- transport operations involved will incur overheads compared to the ideal and theoretical scenario. It’s also a problem that an energy- drain based on a fixed decoding process, for example, will rarely be as effective as an opportunistic variable software- algoritm. In addition, it’s not like the hardware solution doesn’t use any power on it’s own. Something that put together defeats the point of attempting to save power through direct hardware- support for even the most common tasks - such as mp3 playback or certain hardware- accelerated video formats.
But splitting functionality in this way is nevertheless chosen. Because with few clock- cycles to go on on a mobile phone chip, this was the only way to have acceptable response- times (though syncronisation issues certainly exist - popping sound, bad quality, noise - typical problems). Externalising certain instruction sets also would give the developer of that technology some “security” - as well as give the OS manufacturer the possibility to provide the specifications and the interface - and then just provide these to any 3rd party.
And this setup has been kept, with the system- on- chip designs, even though the parts of these chips now come in generic versions with programmable data- areas.
Where, then, does RISC (reduced instruction set computer) fit in this backwards summary? This is the other approach to increasing parallel processing, which, due to lack of small and flexible enough chipsets, have never taken off (even if it has been used successfully in fairly complex commercial platforms, for example PlayStation One and 2). Because in order to use a RISC system effectively - so it can save clock- cycles - the system needs to perform many similar instructions repeatedly at the OS kernel level, as well as be fundamentally based on parallelism. …!
In other words, we’ve just found the perfect use for a risc- system. A mobile phone or a pda platform, where the point is to save clock- cycles while avoiding syncronisation issues, because parallel processing is the fundamental idea - and where you want to lower the transport- overhead on the bus, as well as increase the life- span of the battery as much as possible.
And, with a well constructed system - no more would it be necessary to scrap the phone to upgrade the voice- filter, or incur enormous overhead on post- processing algoritms. Since you would be able to exploit soft DSPs for certain tasks, and then transport that data effectively. While it would still be neceesary to develop external chips for the fundamental tasks such as voice- recording or display- buffers and screens, and so on..
So - why don’t we have programmable risc- systems and a blooming multiplatform operating system industry in motion already? That is, I suppose, a good question.
—
The practical solution that was chosen, was to fit certain functionality to external chips where that would be useful (such as voice- processing, noise filters), and then employ risc- technology to the memory- transport areas. What we’ve seen mostly, however, is a generic implementation of close to atomic operations, and collections of often performed instructions that are not necessarily tailored to the tasks the device is supposed to perform. So, while increasing the amount of instructions processed each clock- cycle by large amounts, it still remains an underused technology, in an application type that is evidently perfect for it.
This practical solution is also the reason the systems released at the present are time- shifted multitask systems that draw on processor speed, more than instruction set optimisation. And, we see that increased processor speed is the number one requirement on new devices - while it really should be quite a long way down on the list, if parallel computing was more than a funny- sounding concept. Because, as mentioned, the huge gains it’s possible to achieve in reducing the power- consumption in lesser processors, and the decreased cpu time used for any amount of processing, is well worth it.
But - no doubt it’s easier to deploy a high level (or program level) instruction set for certain technology, since this can be retrofitted to the device more easily. So Flash lite 3 will be supplied through software on the new UIQ devices, and it will be a high- level implementation using generic OS functionality to operate. Not a low- level implementation, though it might be using some instruction sets specifically tailored for generic vector- graphics. Something that of course would make it suitable for deployment on all UIQ3 devices, and so on. As well as exploit the architecture that has been there for some time. But executing the code will not be nearly as efficient as it could’ve been.
Cost efficiency also has something to do with this - it’s much cheaper to fix and expand on the platform independent of the phone construction and market deployment process. So programming a solution independent of the hardware- mess is an increasingly tempting option. But the question is really one of organisation, and of applying the available technology in a strategic way.
So two directions seem to be staked out:
1. To choose functional and programmable risc- solutions that still can be expanded upon after deployment of the device. And on the other hand -
2. to choose a component platform on beforehand, and ensure the unit is obsolete before the newer (and infinitely more customer - as well as developer- friendly) software and OS is ever thought of.
..I wonder - what sort of strange compromise will we end up with in the end?
Leave a Reply