The Symbian OS (779886), страница 71
Текст из файла (страница 71)
So it’s notsurprising they went for it.Martin Budden, already a veteran at that time, was an early C++advocate.Martin Budden:I was actually advocating C++ fairly early on, but I wasn’t the only one, therewere other people advocating C++ too. There was a debate about whetherto move to C++ or stay with C and, fairly quickly, the C++ argument won.Since Colly was doing the first cuts of the operating system, once he had beenconvinced, it followed from there.Geert Bollen arrived at Symbian in the early summer of 1995 withimpeccable credentials in object orientation and a significant backgroundwith C++, specifically.
While others in the company were still learningC++, Bollen already had three to four years heavy-duty implementationexperience behind him. By the time he arrived, the decision to go withC++ had already been made and the team was six months into theproject.Geert Bollen:C++ seemed the obvious choice from my perspective. But I suppose I hadn’treally been exposed so much to some of the issues in an operating-systemcontext.
But consider, it’s only in the last few years that the C++ ABI (Application Binary Interface) has been standardized, so that completely determinesthe interoperability of different toolsets. That gives you an idea of how youngthe language was, at least as an industrial tool. All that had been taken forgranted in the C world since the ’80s; they just weren’t issues. In the C++world they were wide-open problems.PIONEERING THE OBJECT APPROACH IN PSION341When Bollen joined the project, the lack of standardized low-leveltools meant that no code was yet running on ARM hardware, and alldevelopment was still emulator-based.
The project was still feeling itsway, climbing the language-learning curve while throwing its energy intothe object-oriented design opportunities of a clean, from-the-ground-up,re-engineered system.Geert Bollen:Moving to C++ was a very brave decision. I don’t know if it seemed so at thetime, but in hindsight it was a very, very brave decision. They had selectedC++ to build this system, with some trepidation, as a leap of faith.Challenges of Switching LanguagesSwitching incurs costs. There were what David Wood might call the‘sociological’ issues, the questions of what tools developers knew, theproblems of bringing in new developers familiar with C++ but not with thein-house object-oriented style, while training up the seasoned in-housedevelopers in a new language; and all this, of course, as the design itselfevolved fairly freely.But there were other problems too.
Performance problems, perhapsinevitably, quickly became apparent.Howard Price:C++ was slow and big in various situations. For example, the OPL VM grewby about six times when it was ported from S3 8086 Assembler to C++. Therewas some argument, to the point where there was talk of dropping C++ andmoving back to the faster, leaner, meaner approach – just sticking to C. But,thankfully, David Wood and Charles Davies were really strongly committedto C++ and object orientation, and they persuaded the rest that this was theway to go.But the biggest practical headache almost certainly was the lack of asuitable, stable toolchain.Geert Bollen:The target tools were not in place when I arrived, so whatever the system was,it was emulator-only.
The kernel implementation was an emulator implementation. The on-the-metal version of the kernel was started and delivered afterI arrived. Colly Myers assembled a team for that. Before that, he had been aone-man band.342THE USE OF OBJECT-ORIENTED DESIGN IN SYMBIAN OSThere was no standard toolset capable of targeting both Intel and ARM.Or rather there was, of course, the GNU GCC toolchain, but not onethat would work naturally in a Microsoft Windows development environment. Since most development took place on Microsoft Windows for theemulator targets, a productive Microsoft Windows programming environment was essential.
Microsoft’s compiler and toolchain targeted only Intelprocessors. Because there was no standard Application Binary Interface(ABI), Intel binaries were in a world apart from the GCC ARM binaries.4In the short term, this meant that bespoke tools had to be written toenable dual-target compile and build using two different compilers, eachwith its own make and link tools and other utilities, but in a way thatintegrated reasonably well enough with the Microsoft Windows-basedIDE so as not to cripple developer productivity.The longer-term legacy is that this bespoke system still persists, inessentials unchanged, to this day, a source of low-level discomfort for theexternal developer community. (Internally, it is as it is and you get usedto it.
Externally, it is reasonable to ask why you should have to get usedto something that causes development pain.)The underlying problem of course is that phones now, and PDAsthen, are essentially embedded devices, and the development processfor embedded systems is inherently more complex (typically in arcaneand opaque ways) than development for desktop systems. A crosscompilation model is natural and inevitable in an embedded-systemscontext.
For Symbian OS now, as then, initial development is based onan emulator hosted by Microsoft Windows and only later (when the basicimplementation is running) moves to a cross-compilation model targetingreal hardware, either prototype or production devices or reference boards.Another lasting legacy of the early tools problems is the nature ofthe emulator implementation. Essentially, the emulator consists of theuser libraries (the base-level services and utilities above the kernel itself)and higher-level kernel services implemented on top of native MicrosoftWindows libraries. This is nominally transparent to the higher layersof the system, but key kernel services and hardware-level services arereally being provided by the host operating system, in this case MicrosoftWindows, to which the low-level calls of the hosted system are mapped.Historically, the problem with this solution is that for anything beneathapplication-level programming, the true behavior of the code is obscuredby the underlying Microsoft Windows implementation.
This was not anissue in the early development of the operating system, since the wholepoint of the emulation was to allow the application developers to geton with work on the application suite, but it rapidly became a problemboth for internal and external developers. While the worst problems have4Standardization at the binary level is only now appearing across the toolchain with thestandardization and adoption of ARM’s EABI, enabling interoperation of tools from differentvendors.PIONEERING THE OBJECT APPROACH IN PSION343been fixed for some time, some awkward issues have remained even upto the most recent releases of the operating system.
Those challenges canbe traced all the way back to those first problems of early adoption of apre-standard C++.As the kernel moved onto real hardware and began to exercise theARM-targeted toolchain, yet more challenges emerged.David Wood:We hit various quite significant obstacles along the way, for example we werecalling C++ functions from one DLL into another DLL in a way that I don’tthink had been widely done before, and certainly this required lots of changesin the GCC compiler that we used. So several times, the implementation forARM as opposed to the emulator got held up because we were using C++to the limit, with the DLLs, and we needed to get Cygnus (who were at thatstage under contract from us, maintaining GCC) to issue numerous fixes.
Sowe were pushing it to the limit.Again the issue was the immaturity of the C++ development environment and the lack of standardization of the low-level interfaces.Yet another area in which early adoption proved to be costly was thelack of standardization at the level of the basic language libraries.David Wood:There was no sufficiently agreed standard library that covered the things thatwe wanted. There was no text-handling library that Colly Myers was satisfiedwould provide either the necessary degree of security or the necessary degreeof efficiency and performance.This is the reason that descriptors were invented as type-safe, memorysafe, string and binary-data container classes. The alternative wouldhave been to use standard C++/C-subset strings, which provided neitherprotection against overruns nor type-safety.5 For a system with pretensionsto robustness, they were out of the question.Error handling was another unstandardized area of the C++ language.Again, a solution was invented, specifically aimed at the needs of theclass of device that the operating system targeted, based on the notionsof ‘leaving’ functions and a cleanup stack.65C-style strings are just arrays of raw data bytes, which can be accessed as eithercharacter data or raw binary data, and as bytes or multi-bytes.
Indeed, that very versatility istheir point, but it makes them both error prone and open to accidental or deliberate abuse.6The cleanup stack is used to hold pointers to automatic (i.e., stack-based and, therefore,function-scoped) objects, so that if the function should fail (‘leave’) the objects are deletedand not left allocated but inaccessible (which is a memory leak).344THE USE OF OBJECT-ORIENTED DESIGN IN SYMBIAN OSOther features of the language were treated with caution.Andrew Thoelke:We were very cautious in our adoption of advanced C++ features, partlybecause not all compilers supported them or did them well, but also becauseyou just don’t know whether you’re using a feature which has lots of powerbut has a lot of background overhead to it.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
