88open’s world shrinks painfully with every defection from the Motorola Inc 88000 RISC camp, or the adoption of a dual-architecture strategy by a formerly loyal vendor. Members of the not-for-profit support organisation, other hardware developers and independent software vendors that have passed through its binary testing and certification schemes are nevertheless full of praise for the work 88open has done. Now reduced to a shell with news that members are believed to ave backed out of providing their $3.5m dues (CI No 2,143), the organisation must now offer its testing services on other chip architectures if it is to survive in any form. Last year, on the back of industry acclaim for its work, 88open took some first steps beyond the 88000 horizon by offering its binary testing suites to other manufactuers and bodies.
Precision RISC
It netted only Hewlett-Packard Co and the Precision Architecture RISC Organisation as a customer. Potential users apparently wanted 88open to undertake the difficult job of converting and administering the test suites for their architectures too, something not possible under 88open’s current charter. The 88open offshoot will come into being in or around May, provided it doesn’t get itself bought outright before that happens. It will bring with it some very focused ideas about binary compatibility and implementation issues that face the industry, derived from its experience with the 88000. The problem with source code for example – even standardised and tested source code – is that it always ends up going through a variety of different compilation systems. This process means, inevitably, that the code will get different calls when running under different operating systems. So one of the first issues to be resolved, as Steve Heath, director of 88open operations in Europe sees it, is to define the ways in which different compilers interpret source code and how, in turn, operating systems use different compilers and compilation techniques. At this level, the number of bits used, alignment and requirement for there being no reserved bits in the mechanisms becomes important. This is processor-independent stuff, according to Heath, who says most Reduced Instruction Set Computing architectures already share common notions in these areas and most are now able to deal with software that is written to either Big Endian or Little Endian byte ordering styles. Once terms of reference for the way code, compilers and operating systems work together are established, things that prevent software being implemented for different systems need to be addressed. There is a collection of these miscreants – Heath identifies file formats, disk formats and install scripts as notable examples.
By William Fellows
Next, Heath argues, CPU-specific issues such as register stacks and context switching need to be standardised. Although this stuff is low-level, if instructions are correctly coded and subtitled, there’s no reason why software can’t be implemented across standardised, low-level mechanisms. After all this is done then you have a standard, says Heath. That’s easy. But how do you test for it? X/Open Co Ltd has some two or three thousand tests for conformance to its XPG portability guide. Static testing to check, for example, that all system calls are correct is fine, says Heath. But for real compatibility, software needs to be tested dynamically, as it is being executed. You need a test harness for testing stuff dynamically. That’s the killer. Lack of dynamic testing can mean that for some independent software vendors less than 20% of their application code is relevant, which can lead to any number of unforseen problems when the application is run under different environments. Heath’s example is a hypothetical software firm’s development team, which claims to have developed the latest all singing, all dancing application, which of course is portable. The marketing team goes out and finds 20 odd systems on which to sell it. However, only 20% of the code gets tested and when the software is recompiled a
nd run under these other environments, it often doesn’t work properly. The company gets burned by the cost of extra development time and resources needed to correct or re-write the application for each architecture. Thereafter the firm might carefully choose one or two systems and do a thorough conversion job, probably thinking at the same time ‘there must be another way.’
Ever more critical
Moreover, as revenue derived from upgrades and add-on sales becomes increasingly important to the software industry’s business model, binary compatibility across different systems and between old and new versions of application software becomes ever more critical. A company needs extremely good conversion and testing tools for these jobs – of just the kind that are available for the 88000, argues Heath – even more so given that some end-user customers are even demanding certification as part of their acquisition and procurement process, 88open says. 88open uses 5,000 tests for compliance with the 88000 application binary interface and has both static and dynamic test harnesses. Its verification programme demands a minimum 80% of binary code is tested dynamically – 100% statically – before certification is awarded. X/Open’s XPG suites test source code. That’s fine, argues Heath, for what X/Open has set out to do. The problem is that XPG is like defining an English language. The English will get interpreted one way in the UK, differently in the US, and in other ways elsewhere. The point is, argues Heath, that the industry is developing more binary-to-binary compatibility and emulation techniques. As these technologies mature, underlying architectures matter less. Software costs a lot and it should be re-usable across different systems. The key to 88open’s future, as he sees it, is being able to test and certify binary compatibility across systems that do not include an 88000 processor or application. The more architectures on which 88open is able to offer its testing and certification technologies, the more hardware and software suppliers will come knocking on it door.
