|
Tigris.org
Open Source Software Engineering Tools
|
|
|
Developing BREW Application Using Pure C++Darklen caesarshen@gmail.com 9.8.2005
GOALThe goal of this research is to find a solution to develop BREW programs and extensions using pure C++ language without the lost of any speed and space efficiency.To achieve this, the resulting C++ program has to meet following criteria:
PROBLEMSQUALCOMM’s Binary Runtime Environment for Wireless® (BREW®) follows an object-oriented design, which exposes its functionality through BREW Interfaces. BREW Interfaces are conceptually equivalent to the interfaces in many object-oriented languages such as java and C++, which contains the definition of a set of member functions. BREW Interfaces, like their counterparts in Java and C++, support inheritance and polymorphism. However all these features are simulated because the official programming language of BREW is C which is not object-oriented. Due to this design, it is quite inconvenience to write code to manipulate BREW Interfaces in our programs.Access member functionsBREW declares its Interfaces in C structure and provides a set of MACROs to access their member functions. However, programmers who are familiar with JAVA or C++ are more like to access them in an object oriented way. For example, instead of use IBASE_Realse(pObj), we’d like to use pObj->Release().Cast between BREW InterfacesPolymorphism between BREW Interfaces is permitted by BREW. For example, we can cast an instance of an interface to an instance of its super interface. However, we have to cast it explicitly, for example:
The above code is not type safe and may cause problems when pModule is not actually an instance of IModule. The C compiler doesn’t understand inheritance and will not catch this error at compile time. It is better if we can write code like this:
Declare BREW ExtensionsIn order to write BREW extensions, we have to declare our own interface like below:
The above code is complicated and error-prone. To add a member function, we have to declare both a function pointer in the Interface and a macro that access it. It is better if we can write the equivalent code like this:
Instantiate BREW ExtensionsCreating instances of BREW Extensions includes following steps which have to be written by hand:
AEEApplet_New acts similar to the constructor of a C++ class but is quite complicated; any mistakes in it may cause subtle bugs that are hard to track. If we use C++, most code in AEEApplet_NEW() will be generated by the compiler and we only have to write following code:
BREW CallbacksBREW APIs only accept callbacks as C function pointers, not the pointers of C++ class member functions. In C++ program,s we have to write a wrapper function like this:
The above code works fine but the wrapper function itself consumes some CPU circle as it calls the actual member function. For applications, such as Games, performance is extremely important. I have seen many games have a huge main_loop function that contains a big switch statement with 3000 lines of code; I understand the time wasted on an extra function call is unacceptable for them. THE MEMORY LAYOUT OF BREW INTERFACESWhen we declares a BREW Interface using the QINTERFACE() macro, we actually declare two structures, the BREW Interface and its v-table. For example, if we declare an interface IObject that derives from IBase and has a single member function called GetHashCode, the following structures are declared:
The first element of instances of BREW Interface is always a pointer to the v-table. The v-table is an array that contains the absolute address of the interface’s member functions. In addition, if an interface is derived from other interfaces, its v-table must contain all the elements of the super interface’s v-table and its instance must contain all the fields of the instance of the super interface. Figure A shows the memory layout of an instance of the IBase Interface.  Figure A The memory layout of a BREW Interface C++ EQUIVALENCE OF BREW INTERFACESFor some experienced C++ programmer, they might have already found that this memory layout is identical to the memory layout of a C++ object generated by most modern C++. By this assumption, we can declare a C++ class whose instance has exactly the same memory layout as the BREW Interface and cast an instance of the BREW Interface into an instance of the C++ class.For example, if we define CFont as bellow, we can safely cast IFont * to CFont* and use the C++ way to access the member functions of IFont.
DIFFERENT BETWEEN C FUNCTIONS AND C++ MEMBER FUNCTIONSC++ member functions are identical to C functions except that they have an implicit argument called ‘this’ which points to the object and is the first parameter of the member function. If we declare a C++ member function like this:
It is equivalent to this C declaration:
We can cast a C++ member function into an ordinary C function and use it as a callback if we handle the ‘this’ parameter correctly:
SOLUTIONSBased on the fact that it is possible to declare C++ classes whose instances have the same memory layout as the instances of BREW Interfaces, we can re-declare BREW Interfaces into their C++ equivalences, and use the C++ equivalences instead of the BREW Interfaces in our C++ programs. By using the C++ equivalences, we can access BREW Interfaces as if they are C++ classes, and the C++ program will not consume extra memory or CPU circles comparing to the C implementation.After understanding the differences between C++ member functions and C functions, we can cast pointers of C++ member functions directly into pointers of C member functions and always put the ‘this’ pointer as the first parameter of the C function. We have written some demo programs to verify that above techniques work both on BREW emulators and real handsets. Also, the C++ programs are considerably shorter than their C counterparts (1/2 of the code length). Below is the statistics: C++ brewpp.cpp(142 lines ), brewpp.h (147 lines) main_app.cpp (123 lines) (Total 412 lines) C AEEAppGen.c (325 lines ), AEEAppGen.h(106 lines ), AEEModGen.c (400 lines), AEEModGen.h(109 lines) main.c( 62 lines ) (Total 1002 lines) VISUAL C++ ISSUESThere is no known issue in Visual C++ and any other windows desktop compilers. Demo programs runs perfectly in the BREW emulator.ADV1.2 ARM C++ COMPILER ISSUESUnfortunately, these demo C++ programs will not run in the real handset if they are compiled with the ADV1.2 ARM C++ Compiler. The reason is that class instances in ARM C++ compiled programs do not use the common memory layout that is compatible with the memory layout of the BREW Interfaces. If we declare a C++ class CBase which is equivalent to IBase:
And write following test code:
The above test code is assembled into this:
We find that IBASE_Release(b1) and b2->Release() generate different assembly instructions. The v-table of the object generated by ARM C++ does not contain the absolute address of the member function, it contains an offset value. To get the absolute address of a member function, we should add this offset value with the base address of the v-table. The advantage of this design is that v-tables in an ARM C++ compiled program can reside in a read only position independent segment (ropi) which can be loaded to any base addresses and don’t need to made any adjustment. However, the disadvantage is also obvious, the runtime speed of a virtual function is slower than other implementation and the memory layout of a C++ object is not compatible with BREW Interfaces. That’s why the BREW SDK ONLINE HELP has a note in the “Extending BREW APIs” section:
GNU ARM C++ ISSUESSo far, the gnude compiler (http://sourceforge.net/projects/gnude) is the only ARM C++ compiler, we have tried, that has a compatible object memory layout with BREW Interfaces. However, there is still some minor issue: When linking the program, the linker will report an unresolved link to __cxa_pure_virtual which is a dummy function that fills the v-table of an abstract class (class that has at one abstract member function). This function does nothing and will never be called at runtime. To solve this, you have to declare this function as an empty function in you code. If your program uses brewpp.h and brewpp.cpp, you don’t need to do it because is already done by brewpp.cpp. CONCLUSIONSWe have proved that we can write BREW applications or extensions using pure C++ language without lost any speed and memory. We can use BREW Interfaces as C++ classes and declare C++ classes and register it to BREW as extensions. We can use all windows desktop C++ compilers (VC++, BC++, GNU C++) to compile the executable on the emulator. However, due to the current limitation of the ADV 1.2 compilerwe can only use gnude ARM compiler to compile our C++ programs. Other ARM compilers are not tested yet, they might work or not. |
|||||||||||||||||||||||||||||||||||||||||||||
