Please note: I have posted a copy of my message to comp.lang.c++.  They
suggest me to post here comp.std.c++.  You might be able to read my
interesting article below.
    I use Intel C/C++ Compiler 7.1.  In fact, Intel C/C++ Compiler DOES NOT
ignore "inline" unless I tell Intel C/C++ Compiler to obey my desire unlike
other generic C/C++ Compiler such as Microsoft, GCC, G++, or other Unix
compilers.  Please read according to my idea and suggestion below.

    You may notice that switch (...) is much faster than function that can
gain a big improved performance because it only use JMP instruction however
function is required to use CALL, PUSH, and POP instruction that can be
slower.
    I created three functions in an array.  Array is called
pArray_Func[xx]().  pArray_Func[xx]() contains three functions.  "xx" can be
used to point each function.
    Let say, I have over 1,000 functions.  I would put "inline" to each
functions.  It does not matter that each function may contain more than 50
lines.  It is really BIG that C/C++ compiler tells "inline" is used for
short like 3-5 lines ONLY.  I have decided to tell C/C++ compiler by forcing
"inline" there because I don't care if my code is getting bigger and bigger.
I allow 50 lines to be copied to each functions.  CALL, PUSH, and POP
instructions can always be removed automatically by the C/C++ compiler
before JMP instruction can always be placed each function.
    It is very neat according to my design that I wanted.  If I care to keep
small code rather than big code, "inline" should not be used.
    Right now, there is a big problem.  I can't place "inline" into
pArray_Func[xx]().  I can see why.  JMP can show "JMP [EAX+EDX*4] that will
work fine.  C/C++ compiler can only place "CALL [EAX+EDX*4] into
pArrayFunc[xx]().  It is not designed to replace from "CALL [EAX+EDX*4]" to
"JMP [EAX+EDX*4] if "inline" is there.  C/C++ compiler will always ignore
"inline".
    Another option is to place 1,000 functions inside switch (...).  Look
like below.

switch (xx)
{
    case 1:
        Func1();
    case 2:
        Func2();
    case 3:
        Func3();
}

    C/C++ compiler can see this code above before it can place "inline" to
each functions inside switch (...).  It is very annoying me because I have
to read switch (...) from line to line by scrolling up/down.  It is very
long for me to read.  It is not HARD to FIND BUG (off my point).
    I would want to see only 3 or 4 lines there instead of over 20,000 lines
that contains switch (...).  pArrayFunc() may be very useful.  We should
tell the C/C++ authors to add keyword like __USE_JMP_INLINE instead of
__inline, _inline, or inline.
    Newest version of C/C++ compiler like Intel Compiler can accept
__USE_JMP_INLINE.  "__USE_JMP_INLINE" will be added to pArrayFunc[xx](), but
"inline" will always be same for 1,000 functions.  After you compile your
C++ source code, it will recognize "__USE_JMP_INLINE", it will rename from
"CALL [EAX+EDX*4]" to "JMP [EAX+EDX*4]" so each functions' PUSH and POP
instructions will be removed.  It will look like real JMP Table inside
pArrayFunc[xx]().  It would be perfect for easy reading.
    Please state your opinion what you think about my idea to modify C/C++
compiler's source code.  ***Do not tell that there is no __USE_JMP_INLINE to
all C/C++ compiler.  Please ask the authors to add __USE_JMP_INLINE keyword.
It would be perfect and neat C++ coding.***

    I have put pArrayFunc[xx]() inside C++ class example below.  It gives
you an idea however "__USE_JMP_INLINE" does not EXIST, but should be added
near the future.

#include <stdio.h>



class Test

{

public:

            inline void Get_a() { printf("A: %d\n", _a); }

            inline void Get_b() { printf("B: %d\n", _b); }

            inline void Get_c() { printf("C: %d\n", _c); }



            inline void Set_a(unsigned int a) { _a = a; }

            inline void Set_b(unsigned int b) { _b = b; }

            inline void Set_c(unsigned int c) { _c = c; }



            typedef void (Test::*Action)();

            static const Action Menu[3];



            inline void Call();



private:

            unsigned int _a;

            unsigned int _b;

            unsigned int _c;

};



const Test::Action Test::Menu[3] =

{

            &Test::Get_a,

            &Test::Get_b,

            &Test::Get_c

};



inline void Test::Call()

{

            for (int a = 0; a <= 2; a++)

                        (this->*Menu[a])();

}



void main(void)

{

            Test test;

            test.Set_a(1);

            test.Set_b(2);

            test.Set_c(3);

            test.Call();



            return;

}

--
Bryan Parkoff

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

bryan.nospam.parkoff@nospam.com ("Bryan Parkoff") writes:

>    Right now, there is a big problem.  I can't place "inline" into
>pArray_Func[xx]().  I can see why.  JMP can show "JMP [EAX+EDX*4] that will
>work fine.  C/C++ compiler can only place "CALL [EAX+EDX*4] into
>pArrayFunc[xx]().  It is not designed to replace from "CALL [EAX+EDX*4]" to
>"JMP [EAX+EDX*4] if "inline" is there.

I think that on x86 architectures GNU C/C++ versions 3.4 and greater will
generate a JMP instruction for that sort of code .  This is done by what
GCC calls "sibcall optimization", which is an example of what is more
generally known as tail call optimization.

However, it is true that there are some circumstances in which it is difficult
for compilers to perform such optimizations, in particular when the calling
function has local variables whose address has been taken.

For this reason, I proposed an extension to GNU C to allow the user
to tell the compiler when it should perform tail call optimization.
See <http://gcc.gnu.org/ml/gcc/2000-11/msg01120.html> and the thread which
follows, in particular <http://gcc.gnu.org/ml/gcc/2000-11/msg01126.html>.

The language C-- has a similar feature, as does the .NET Intermediate Language.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Bryan Parkoff"" <bryan.nospam.parkoff@nospam.com> wrote in message
news:K0uHb.25610$V23.21669@fe1.texas.rr.com...

Is your only motivation to this whole <stuff> to replace some CALLs with
JMPs? Can you show us some profiler data that compares the run times of your
design vs. the traditional way?

IMHO if you can show a 2-fold speed gain probably someone will consider to
think about your article. However if data shows below-measurable difference,
or a slowdown [for what (the latter two summed) I see 99.999% probability],
you may reconsider it's usefullness yourself.

Paul



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]