The Symbian OS (779886), страница 70
Текст из файла (страница 70)
It also improved run-time performance, another importantdriver.Peter Jackson:All in all, it made for some very lean and mean code and it was also a veryelegant system. It was precisely targeted to meet the requirements of the objectspace you would need to have for a PDA.Throughout the system, assembly code was also extensively usedto achieve speed and small code size. Again, this code was writteninside an object framework which integrated with the C-based objectmodel.PIONEERING THE OBJECT APPROACH IN PSION337Martin Budden:The assembler stuff was written to the same kind of interface, so it waseffectively object-oriented assembler, and it fitted in the same framework, atleast at the application level.While object-oriented techniques were used extensively in the higherlevels of the system, the lower levels of the system were more conventional.
The kernel implementation, for example, and the lower-levelsystem services, such as the file server, were written in conventional C.Geert Bollen:It was a layered OO [object-oriented] mechanism, using message dispatch ontop of a C system. That was the Psion tradition. Underneath was a classicC-API-based operating system with a small number of system calls exposed asC functions.This is exactly how it should have been, in David Wood’s view.Object orientation was a pragmatic choice, not an ideological one. Itwas intended to achieve some clearly defined benefits without undue riskeither to the system (in terms of size and performance, for example: codebloat was the big fear) or time-to-market (which a wholesale jump to C++might have jeopardized).David Wood:OO came in stages, which is how all large software systems should evolve.One of the very important rules of software, or indeed of anything else in life,is, If you’re not sure what you’re doing, don’t do it on a large scale. I thinkthe phrase is attributable to Tom Gilb.
What it means is that you should goand experiment, and you should evolve through iterations. So we introducedobjects first of all just for the user interface, and then we realized that we couldapply those ideas elsewhere too. So we proceeded through iterations.C++ Language Choice and AdoptionAt the outset of the 32-bit project the team assumed that a straightforwardsoftware migration effort would suffice to move the major part of thesoftware base to the new hardware architecture.
In fact, the first planwas for automated migration. Since the move up to a 32-bit system338THE USE OF OBJECT-ORIENTED DESIGN IN SYMBIAN OSinvolved a switch from Intel to ARM processor architectures, the focusfor rework was on the hardware interfaces of the low-level system and onthe operating system kernel itself, for example to migrate to new processand thread models and a new MMU architecture.David Wood:In 1994, we had at first a plan that we would do a quick project to convertfrom 16-bit to 32-bit. We assumed we would keep more or less the samesyntax and that we would actually write a tool to read in everything and thenspit out 32-bit versions.There were a number of reasons for moving from Intel.
The Intel x86architecture was primarily aimed at desktop computers. It had no realpower management features, making it power hungry and giving it muchworse MIPS per Watt performance than ARM. Just as importantly, even asearly as 1994 Psion had identified mobile phones as the most promisingfuture mass market for handheld devices.
ARM had established itself asan ambitious and successful semiconductor player in the mobile devicemarket. In contrast, Intel had little or no mobile device presence.The plan for automated migration did not last long. The languagequestion quickly came to be seen as an important strategic choice, notjust a practical one, in much the way that the processor choice wasboth pragmatic and strategic. One consideration was the nature of theintended platform so far as third-party applications were concerned. TheSeries 3 had provided a run-time support system similar to Visual Basicfor installable third-party applications, and a thriving hobbyist culturehad grown up around it. However, this was far from offering a nativelyprogrammable platform (which would imply that the system-level APIswere open to third-party applications as native calls rather than servicedthrough the run-time language support).
Native programmability wasemerging as a key requirement for the 32-bit system.The more general question was how far Psion could afford to ignorethe mainstream. Continuing with a home-grown system involved morethan software maintenance costs (supporting the toolchain and keepingit fit for purpose). It would incur the larger, negative opportunity cost oflocking the 32-bit system out of the mainstream. As ambitions for the newoperating system scaled up, with its design life projecting well beyond2000, moving with the mainstream became an increasingly importantconsideration.David Wood:As we saw the scale and longevity of the 32-bit system we thought, ‘Wait, wedon’t want to be stuck in some custom programming system, we want to goPIONEERING THE OBJECT APPROACH IN PSION339with the mainstream’, and increasingly the mainstream was C++. That’s whatsoftware engineers were learning at university, that’s what they would knowabout.
We thought it would be harder to recruit people if they then had to goand learn this comparatively arcane technology which we had. So we adoptedC++ for sociological reasons as well as technical reasons. But the technicalreasons were important too. As we studied C++ more over the years we sawthere were benefits in it being, quotes, a better C, rather than just being anobject-oriented C.While not everyone was convinced by this line of argument, it wascertainly clear that the alternative to C++ was an in-house system; thatC++ was almost certainly going to be one of the dominant object-orientedlanguages for the foreseeable future; and that the mainstream would bethere if it was anywhere. Dialects such as Objective-C were beingrelegated to the margins by the momentum which was gathering behindC++. Arguably, even Smalltalk, which had some claims to priority, waslosing ground to the C++ juggernaut.2While C++ was still the same language which the company hadpreviously rejected as too big, too complex, and insufficiently constraining, the context had changed.
Looked at more positively, C++ not onlyretained many of the advantages of C as a systems programming language (its ability to get ‘close to the metal’) it was indeed by design ‘abetter C’.Stroustrup characterizes this aspect of the language as includingstronger type checking; more convenient and less error-prone memory allocation (operator new) and release (operator delete); functionoverloading; the ability to initialize variables with values as well as toassign values; references; and, in general, less reliance on exploiting tricksneeded to get the best from the language.
(Type casting, for example,was a ubiquitous pattern in C that was only rarely necessary in C++[Stroustrup 1994, p. 171].3 )2A 1995 survey conducted at Object World identified 77% of respondents as C++ userscompared with 28% as Smalltalk users [CIO Magazine, www.cio.com/archive/110195/object.html].3It is also worth considering Stroustrup’s views on what programming languages are for.A language does two things, as he sees it: it provides a vehicle for specifying actions to beexecuted and it ‘provides a set of concepts for the programmer to use when thinking aboutwhat can be done.’ [Stroustrup 1993, p.
8] In other words, on the one hand, it providesa model which abstracts a programmable machine (a ‘machine model’) and, on the otherhand, it provides a conceptual model for translating real-world problems into programsolutions. Arguably, the history of the evolution of programming languages is the historyof the stretching of the gap between the two, so that the conceptual model is increasinglydistanced from the underlying machine model, as well as of the increasing abstraction of themachine model away from a literal physical interpretation toward a logical interpretation.340THE USE OF OBJECT-ORIENTED DESIGN IN SYMBIAN OSAndrew Thoelke:I remember hearing about the discussions, but I was too junior in the companyreally to be directly involved or influence them. But C++ was still quite youngat that point. This must have been 1994.
It was way off being standardized,probably four or five years before the first pass at standardization. But it clearlyhad most of the elements of object orientation that had been put into theSeries 3 system, and clearly it was going to be standardized, it was going tobe much more mainstream, it was important. And the experience of using anobject-oriented language and having an event-based application environmentwas one they didn’t want to lose (because the 16-bit system already had that)by migrating to a new hardware architecture and going 32-bit.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
