Re: GCC does not cope with my code

Gunnar Braun <braung@ert.rwth-aachen.de>
31 May 2000 23:03:15 -0400

          From comp.compilers

Related articles
[3 earlier articles]
Re: GCC does not cope with my code chrisd@reservoir.com (Chris Dodd) (2000-05-28)
Re: GCC does not cope with my code rus@tamu.edu (Silvius Rus) (2000-05-28)
Re: GCC does not cope with my code bonzini@gnu.org (2000-05-28)
Re: GCC does not cope with my code gnb@itga.com.au (Gregory Bond) (2000-05-28)
Re: GCC does not cope with my code J.Scheerder@cwi.nl (2000-05-28)
Re: GCC does not cope with my code Wilco.Dijkstra@arm.com (Wilco Dijkstra) (2000-05-28)
Re: GCC does not cope with my code braung@ert.rwth-aachen.de (Gunnar Braun) (2000-05-31)
Re: GCC does not cope with my code bosch@nile.gnat.com (Geert Bosch) (2000-06-04)
| List of all articles for this month |

From: Gunnar Braun <braung@ert.rwth-aachen.de>
Newsgroups: comp.compilers
Date: 31 May 2000 23:03:15 -0400
Organization: ISS, RWTH Aachen
References: 00-05-091
Keywords: GCC, summary

Hi.


First of all, thanks for all the responses to my posting. I received
lots of answers to my question and they were all quite helpful.


The most frequent opinion was that the main function containing the
big switch statement was simply too large, since most compiler
optimize function-wise, an so the memory demand grows up with the
power of 2 or even more. That was probably the cause of the SIG11
crash. I think the compiler (or better the optimizer) has internal
limits concerning the memory allocation, since the memory of my system
should be sufficient (1GB real + 4 GB swap memory).


So I broke up that function into small pieces which was gladly
accepted by the compiler. I pursued two approches: a) to generate one
function for each case in the switch statement and b) to split the
statement into blocks of about 300 cases and then call one function
for each block. The second approch turned out to be the faster one
(which is pretty important for me, since I am - as you might have
guessed - generating fast processor simulators out of a processor
description *). So I think Paolo's idea would be fastest solution.


Furthermore, most of you discovered the useless PC
increment/decrement/comparision. Surely, you are right, but
unfortunately that's a thing I can't change, since that's up to the
guy who did the processor description. It's my job to get the best out
of it, but of course I can't generate nice, clean, highly optimized
C++ code out of it.


I received lots of useful ideas I'm currently "playing" with I didn't
even considered before.


So long and thanks for all the fish,


Gunnar


*) See http://www.ert.rwth-aachen.de/lisa if you like


PS: A switch-case statment does _not_ behave like if-else with lots of
comparisions. The compiler generates a kind of function table
containing all the cases and then uses a map function to switch to a
particular case in the table. So it is *much* faster than if-else and
almost as fast as building up such a function table by hand.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.