Wednesday, April 30, 2008

VIRTUAL REALITY

Virtual functions are a key feature of C++. Via dynamic binding( Late Binding ), they provide a powerful mechanism to change the semantics of a function at run time. To support the virtual function mechanism, different schema's have been adopted. I shall discuss the method used by Microsoft Visual C++ compiler (Model proposed by Martin O' Riordan).
Whenever a class declares a virtual function or is derived directly or indirectly from a class which declares a virtual function, the complier adds an extra hidden member variable which points to the virtual table. A virtual table is nothing but an array of pointers to the virtual functions. The entries in the virtual table are changed at run time to point to the correct function.Consider the following class :
    class Base
    {
    public :
    Base() { }
    ~Base() { }
    virtual void VirtualFunc() { cout << "Base::VirtualFunc()" << endl ; }

    };

    Base defines a trivial virtual function VirtualFunc(). Let us derive a new class 'Derived' from 'Base'.

      class Derived : public Base
      {
      public :
      Derived() { }
      ~CDerived() { }
      void VirtualFunc() { cout << "Derived::VirtualFunc()" << endl ; }

      };

As you can see, Derived has overriden VirtualFunc(). When we create an instance of Derived, typical object layout is shown below :

0064FDE0 84 30 41 00 E8 FD 64 „0A.èýd
0064FDE7 00 54 30 41 00 28 FE .T0A.(þ
0064FDEE 64 00 CF 10 40 00 01 d.Ï.@..
0064FDF5 00 00 00 38 FE 64 00 ...8þd.
0064FDFC D9 27 40 00 01 00 00 Ù'@....
0064FE03 00 48 02 76 00 98 02 .H.v.˜.
0064FE0A 76 00 68 F1 59 81 48 v.hñY.H

The first four bytes are pointer to the virtual table. The virtual table itself contains pointers to the virtual functions of the object. In our case, it is a pointer to VirtualFunc().

Memory layout of the virtual table is :

00413084 32 10 40 00 FF FF FF 2.@.ÿÿÿ
0041308B FF DE 2D 40 00 EB 2D ÿÞ-@.ë-
00413092 40 00 00 00 00 00 FF @.....ÿ
00413099 FF FF FF 00 00 00 00 ÿÿÿ....

The first four bytes are pointer to VirtualFunc().

With this information, we can tweak an object and make it do weird things !! (just for fun)
Let us change the virtual table pointer and point it to our own table !!!.

    ////////////////////////////////////////// Modify.cpp ///////////////////////////////////////////////////
    #include "iostream.h"
    #include "memory.h"

    //Pointer to a function returning void
    typedef void (*PFN)();

    typedef struct
    {
    PFN Fn;
    } VTable;

    //The function which will replace VirtualFunc
    void ModifyFunc() { cout << " Modified the vitual table !!!" << endl ; }

    int main()
    {
    Derived DerivedObj;

    Base *pBase = &DerivedObj;

    //Create our own virtual table
    VTable MyOwnTable;

    //Point Fn to ModifyFunc
    MyOwnTable.Fn = ModifyFunc;

    //Holder for pointer to virtual table
    VTable *pVTable = &MyOwnTable;

    //Modify the virtual table pointer by changing the first 4 bytes (assuming a long holds a pointer)
    memcpy(&DerivedObj, &pVTable , sizeof(long));

    //Call the virtual function
    pBase->VirtualFunc();

    //Strange !! ModifyFunc() is called ... enjoy playing :)
    return 0;
    }

A similar though slightly complex technique is used for multiple inheritance and virtual inheritance. Might as well write about them sometime....

Thursday, April 24, 2008

FLAVOURED RTOS

  • Operating systems. Nothing cuts to the heart of a development project like the choice of OS. Whether it's a tiny scheduler or kernel, an open-source distribution, a tightly wound real-time operating system, a fully featured commercial RTOS, or no OS at all, it drives all downstream software decisions and many hardware decisions as well. There isn't much that all embedded systems have in common but some clear trends is revealed nonetheless.First off, more than a quarter of embedded systems now in development won't have an OS at all. Predictably ,larger organizations tend to use operating systems in their products more often than smaller companies do.
It's easy to think of many products, such as thermostats or microwave ovens, that might not need an OS so this isn't overly surprising. It's frustrating for operating-system vendors, though, who'll have a tough time converting that large portion of the market into potential candidates for their wares.
In our 2005 , only 44% of respondents were using a commercial OS, so commercial OS usage has grown significantly. Moreover, that growth is coming at the expense of in-house code.
Both commercial and noncommercial distributions of open-source OSes (mostly Linux) has declined sharply from last year.

  • For most, real-time performance is the big issue. Right behind is processor compatibility. In other words, we can't use an OS that hasn't been ported to our preferred microprocessor, microcontroller, or DSP. That makes sense; compatibility is a pass/fail criterion for most developers.

  • So it all comes down to this, the all-important ranking of commercial OSes. Among commercial embedded operating systems, Wind River's VxWorks was the undisputed leader, as shown in Figure.

Tied for second place are the Microsoft twins, Windows XP for Embedded and Windows CE (there were separated by one vote). In a predictable reversal, WinXP and WinCE were most popular where VxWorks was weakest: industrial and computer-related applications. XPe was especially strong in manufacturing industries, where VxWorks also made a good showing.

In the number four spot we have Texas Instruments' DSP/BIOS, a product with obvious hardware ties. That's followed by Red Hat's Linux, the first of the many Linux variants to make the list.

  • The chart shows the delta between the "would consider" responses and the "using now" responses from the previous graph. In brief, the winners lose and the losers win. How is that possible and what does it all mean?
First, the responses don't necessarily mean that VxWorks users are unhappy with their current RTOS and are ready to jump to (for example) LynxOS or Wind River's Platform NE Linux.
What we can say with certainty is that about 8% fewer people said they'd consider VxWorks compared with the number using it now. Whether or not those are the same people is impossible to tell.Reflecting a kind of Zen balance, almost all of the middle and low scorers gained share of mind in roughly equal proportion to the share lost by the big players. Whether accidentally or by design, the numbers reflect a zero-sum game.

The overall picture is therefore good for commercial OS suppliers. As the number and type of embedded systems increase, so will the total available market.And although open-source operating systems are well and truly established, with one-fifth of developers using one now, their growth seems to have flattened.What's certain is that the variety of embedded systems—and the operating systems that serve them—will continue to flourish.

Thursday, April 3, 2008

Grains of Linux


More Useful Info in next session ....

Semi Industry Prediction

Happy New Year! 2008 is just beginning to unfold in the electronics industry and there is already uncertainty in the air based on recent industry data.
Industry forecasters seem to have different opinions about the overall outlook for the semiconductor and IC-equipment markets in 2008 and beyond.