force jump table with switch statement (visual c)

Discussion in 'C Programming' started by paul c, Dec 9, 2005.

  1. paul c

    paul c Guest

    Apologies if I'm sending this to the wrong group. If so I'd be grateful
    if somebody could point me to the right one.


    I'm using microsoft visual c++ 6.0 compiler. My code is C, I just use
    the c++ compiler for easier positioning of declarations here and there.


    I am putting together a small interpreter that will do a great deal of
    iteration and I'd like to avoid using function pointers to my opcode
    code because I don't need any machine-level stack pushing, popping,
    calling and returning and these seem quite expensive compared to simple
    goto's.


    Can anybody advise what compile options I might use to force a jump
    table when a switch statement is compiled? If I have to use a different
    compiler, I will. Also, is there a disassembler or somesuch that will
    let me confirm that a jump table was produced?


    thanks,
    pc
     
    paul c, Dec 9, 2005
    #1
    1. Advertising

  2. paul c

    Skarmander Guest

    paul c wrote:
    > Apologies if I'm sending this to the wrong group. If so I'd be grateful
    > if somebody could point me to the right one.
    >
    > I'm using microsoft visual c++ 6.0 compiler. My code is C, I just use the
    > c++ compiler for easier positioning of declarations here and there.


    Try microsoft.public.vc or one of its subgroups.

    > I am putting together a small interpreter that will do a great deal of
    > iteration and I'd like to avoid using function pointers to my opcode
    > code because I don't need any machine-level stack pushing, popping,
    > calling and returning and these seem quite expensive compared to simple
    > goto's.
    >
    >
    > Can anybody advise what compile options I might use to force a jump
    > table when a switch statement is compiled? If I have to use a different
    > compiler, I will. Also, is there a disassembler or somesuch that will
    > let me confirm that a jump table was produced?
    >

    You definitely want a compiler-specific ng. Standard C says nothing about this.

    S.
     
    Skarmander, Dec 9, 2005
    #2
    1. Advertising

  3. paul c <> writes:
    [...]
    > I'm using microsoft visual c++ 6.0 compiler. My code is C, I just use
    > the c++ compiler for easier positioning of declarations here and there.


    If you're mixing declarations and statements, your code isn't legal C
    according to the C90 standard, but it probably is according to the C99
    standard.

    But note that compiling C code with a C++ compiler might cause some
    problems. C isn't a strict subset of C++. The most obvious
    difference is that C++ has some extra keywords; a variable called
    "class" is perfectly legal in C, but not in C++. A more subtle
    difference is the handling of void*. In C, a void* value can be
    implicitly converted to any pointer-to-object type; in C++, it can't.
    In particular, this:

    some_type *ptr = malloc(sizeof *ptr);

    is legal (and good style) in C, but a C++ compiler will complain about
    a type mismatch.

    If you don't have a C compiler that allows mixing declarations and
    statements, you might consider just not mixing declarations and
    statements. You can bring declarations closer to where they're used
    with nested blocks.

    [...]

    > Can anybody advise what compile options I might use to force a jump
    > table when a switch statement is compiled? If I have to use a
    > different compiler, I will. Also, is there a disassembler or somesuch
    > that will let me confirm that a jump table was produced?


    I don't have an answer to that question (and if I did it would be
    off-topic here). But it's probably not worth worrying about. If your
    compiler is at all decent, it should do a reasonably good job of
    generating the best possible code for a swtich statement. That might
    not necessarily be a jump table. Use a command-line option to
    increase the optimization level, and measure the actual speed of your
    code; if it's fast enough, don't worry about it.

    If you're sufficiently curious, most compilers have an option to
    generate an assembly listing so you can examine the generated code.
    Just remember that there's a good chance that the compiler knows more
    than you do about the best code to generate.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Dec 9, 2005
    #3
  4. paul c

    paul c Guest

    Thanks to Keith T and Skarmander for those answers. (Although I'm not
    an Intel assembler expert, even vc's debug output sometimes produces a
    jump table but not always - my target is a single process through which
    hundreds of users will access memory one at a time but potentially
    millions of memory accesses each time a user calls it - function
    pointers are safer from a coding point of view but my measurements
    suggest they are pretty expensive for my limited use of their capabilities.)


    cheers,
    pc
     
    paul c, Dec 9, 2005
    #4
  5. paul c

    Malcolm Guest

    "Keith Thompson" <> wrote
    > If you're sufficiently curious, most compilers have an option to
    > generate an assembly listing so you can examine the generated code.
    > Just remember that there's a good chance that the compiler knows more
    > than you do about the best code to generate.
    >

    You can still normally beat a compiler with hand-optimised assembly. It's
    quite a long time since I've had to do this, however.
     
    Malcolm, Dec 10, 2005
    #5
  6. paul c

    paul c Guest

    Malcolm wrote:
    > "Keith Thompson" <> wrote
    >
    >>If you're sufficiently curious, most compilers have an option to
    >>generate an assembly listing so you can examine the generated code.
    >>Just remember that there's a good chance that the compiler knows more
    >>than you do about the best code to generate.
    >>

    >
    > You can still normally beat a compiler with hand-optimised assembly. It's
    > quite a long time since I've had to do this, however.
    >
    >



    Could be an option, as I think there are only a couple of possible
    processors for this program, basically generic Intel and Mac (which I
    assume is still Motorola) and although I'd have to learn a bit of
    assembler, for my purpose only a couple of dozen assembler lines are
    needed provided they can be macro-ized.


    Made up some more tests and the Visual C++ 6.0 jump table performance
    didn't really outshine the function pointer alternative. Will have to
    look more closely at the generated machine code.


    thanks,
    pc
     
    paul c, Dec 11, 2005
    #6
  7. paul c

    Chris Torek Guest

    >"Keith Thompson" <> wrote
    >> If you're sufficiently curious, most compilers have an option to
    >> generate an assembly listing so you can examine the generated code.
    >> Just remember that there's a good chance that the compiler knows more
    >> than you do about the best code to generate.


    In article <dnffh0$3ma$-infra.bt.com>
    Malcolm <> wrote:
    >You can still normally beat a compiler with hand-optimised assembly. It's
    >quite a long time since I've had to do this, however.


    It has, however, become quite a bit more difficult lately (in my
    experience at least). This is not so much because the compilers
    are better -- although they are -- but rather because the machines
    are much worse, in terms of predictability. An "obvious" optimization
    that results in half the number of instructions in the innermost
    loop sometimes results in twice the number of cycles in the innermost
    loop.

    Worse, sometimes the most significant optimization is to place the
    branch that closes a loop at a particular position within the cache
    line(s), which can require counting up the bytes of instructions
    leading up to that point. "Counting" is something computers are,
    in general, better at than people.
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
     
    Chris Torek, Dec 11, 2005
    #7
  8. On 2005-12-11, Chris Torek <> wrote:

    > Worse, sometimes the most significant optimization is to place the branch
    > that closes a loop at a particular position within the cache line(s), which
    > can require counting up the bytes of instructions leading up to that point.
    > "Counting" is something computers are, in general, better at than people.


    Cue the story of Mel, who, I am lead to understand, was a *real* programmer.

    --
    Nathan Wagner
     
    Nathan Wagner, Dec 11, 2005
    #8
  9. paul c

    Flash Gordon Guest

    paul c wrote:
    > Malcolm wrote:
    >> "Keith Thompson" <> wrote
    >>
    >>> If you're sufficiently curious, most compilers have an option to
    >>> generate an assembly listing so you can examine the generated code.
    >>> Just remember that there's a good chance that the compiler knows more
    >>> than you do about the best code to generate.

    >>
    >> You can still normally beat a compiler with hand-optimised assembly.
    >> It's quite a long time since I've had to do this, however.

    >
    > Could be an option, as I think there are only a couple of possible
    > processors for this program, basically generic Intel and Mac (which I
    > assume is still Motorola) and although I'd have to learn a bit of
    > assembler, for my purpose only a couple of dozen assembler lines are
    > needed provided they can be macro-ized.


    If the algorithm is optimised already, and the code is written sensibly
    but still not fast enough, then this is probably the only reliable way
    to get the required performance. After all, the next patch to the
    compiler might change the way it handles the code you've written.

    > Made up some more tests and the Visual C++ 6.0 jump table performance
    > didn't really outshine the function pointer alternative. Will have to
    > look more closely at the generated machine code.


    Which just goes to show why it is so often pointless trying to outsmart
    the compiler with micro-optimisations.
    --
    Flash Gordon
    Living in interesting times.
    Although my email address says spam, it is real and I read it.
     
    Flash Gordon, Dec 11, 2005
    #9
  10. Flash Gordon <> writes:
    > paul c wrote:
    >> Malcolm wrote:
    >>> "Keith Thompson" <> wrote
    >>>
    >>>> If you're sufficiently curious, most compilers have an option to
    >>>> generate an assembly listing so you can examine the generated code.
    >>>> Just remember that there's a good chance that the compiler knows more
    >>>> than you do about the best code to generate.
    >>>
    >>> You can still normally beat a compiler with hand-optimised
    >>> assembly. It's quite a long time since I've had to do this, however.

    >> Could be an option, as I think there are only a couple of possible
    >> processors for this program, basically generic Intel and Mac (which
    >> I assume is still Motorola) and although I'd have to learn a bit of
    >> assembler, for my purpose only a couple of dozen assembler lines are
    >> needed provided they can be macro-ized.

    >
    > If the algorithm is optimised already, and the code is written
    > sensibly but still not fast enough, then this is probably the only
    > reliable way to get the required performance. After all, the next
    > patch to the compiler might change the way it handles the code you've
    > written.


    And the next version of the CPU might change the performance
    tradeoffs. The patch to the compiler might be designed to generate
    better code for the newer CPU; if you use assembly language, you can't
    take advantage of the better generated code.

    Use assembly if you must, but be prepared to throw it away later on.
    If your assembly code is actually faster than the code generated by
    the compiler, consider letting the compiler authors know about the
    optimization they're missing (if it's likely to be generally useful).

    >> Made up some more tests and the Visual C++ 6.0 jump table
    >> performance didn't really outshine the function pointer alternative.
    >> Will have to look more closely at the generated machine code.

    >
    > Which just goes to show why it is so often pointless trying to
    > outsmart the compiler with micro-optimisations.


    Indeed.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Dec 11, 2005
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. z-man
    Replies:
    7
    Views:
    427
    Tor Iver Wilhelmsen
    Oct 5, 2006
  2. Replies:
    21
    Views:
    1,088
    Giannis Papadopoulos
    Aug 2, 2005
  3. switch case to a jump table

    , May 7, 2007, in forum: C Programming
    Replies:
    9
    Views:
    751
    ¬a\\/b
    May 10, 2007
  4. bthumber
    Replies:
    5
    Views:
    436
    Alexey Smirnov
    Jan 29, 2009
  5. Eadwine Rose
    Replies:
    2
    Views:
    230
    Eadwine Rose
    Oct 15, 2006
Loading...

Share This Page