This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] sh-sim: free up some room in jump_table
- From: Michael Snyder <msnyder at redhat dot com>
- To: Joern Rennecke <amylaar at fairadsl dot co dot uk>
- Cc: joern dot rennecke at superh dot com, gdb-patches at sources dot redhat dot com
- Date: Mon, 09 Feb 2004 12:34:24 -0800
- Subject: Re: [RFA] sh-sim: free up some room in jump_table
- Organization: Red Hat, Inc.
- References: <200402071831.i17IVRLD001695@meolyon.local>
Joern Rennecke wrote:
! printf (" if (target_dsp && \n");
! printf (" (iword & 0xf000) == 0xf000)\n");
! printf (" switch (sh_dsp_table[iword & 0xfff]) {\n");
gensim_caselist (movsxy_tab);
! printf (" else switch (jump_table[iword]) {\n");
You have changed a straight dispatch into an if-then-else with
two dispatches, and the integer and fpu arithmetic path goes the long way
round the dsp dispatch; this seems to be a surefire way to make the
simulator slower.
We don't relly care much about the total size of the simulator, but
we care about its working set size, so why don't you generate two
separate simulator main loops, to be compiler into separate *.o
files, one with the FPU instructions, and the other one with the
dsp instructions?
OK, I need to catch up with you here. So, your concern is not
with the time it takes to execute the if condition, but with the
size and/or distribution of the working set? I'm not very used
to programming around such considerations, so I'll look to you
for guidance.
I can see the sense of making two loops, but why would it
be necessary for them to be in two separate compilation units?
Would you be willing to specify a performance test that I can
use, and a test criterion for me to meet? It might save time,
given that we seem to have a 24 hour email cycle.