Re: adjusting cgen

[Johan Rydberg <jrydberg at rtmk dot org>]

On 2002.06.12 17:13 Frank Ch. Eigler wrote:

: : [...]
: 
: If nothing else, they could be detected within the branch instruction 
: semantics.  They could set some private simulator state that signals
: that the previously identified imem page is still valid.  Or even better,
: this logic could be put into the general instruction execution loop
: directly: if the new PC is on the same page as the old PC, then use
: the previous value.

The main idea behind GUSS is "decode once -- execute many".  To achive
this, the insn is decoded into a intermediate format (similar to argbuf).
And the simulator engine is using threaded code, implemented using 
GCC's computed goto's.  This means that there's really no general insn
execution loop.  

Another idea behind GUSS is that special cases, such as on-page branching
should be specialized and optimized.  These special cases are, to increase
performance, detected at decoding time.  

: > [...]
:
: Are you sure that this is a worthwhile thing to do?  You should mark
: up the generated sources by hand once, and see if it makes a positive
: or negative impact on performance.  If it's positive for interesting
: hosts, we should do this cgen-wide.

The reason for me to wanting this is that my intermediate format is
built of two words, one pointing to the insn semantics, and one containing
the insn arguments.  Trying to minimize the intermediate format gains
both memory bandwidth when simulting (just loading one word, and then
shift and mask), and will save memory.  And if the size of intermediate 
format is a power of two, you can eliminate the update of the PC for
every instruction, and instead use the difference between the PC and 
the intermediate format pointer.  example;

   PC = pc_diff + (vpc >> S);

Where S is the difference between the size of the intermediate format
and the insn length.  (for a architecture with 32-bit insn, and an
intermediate format of 64-bits, S is 1).

Many hosts also has insns to load 64-bit instructions into a register
pair.  
 
: > If you're intressted in the simulator, you can find information (ie
: > the sources) at http://savannah.gnu.org/projects/guss/ .
: 
: Not to be discouraging, but can you explain why you'd like to build a
: new simulator framework, when you're welcome to make contributions to
: established ones like sid and even the older gdb simulators?  (It's of
: course a good personal learning exercise to build things from scratch,
: but please realize that there is a *lot* of work involved in making a
: nice, fully featured framework.)

The main reason for doing this to gain more personal knowledge of
simulators, and what technices that can be used to increase the performance.

And to try out some of the ideas I have, I think it's easier to write
something from scratch than to learn all the internals of either SID
or GDB.

regards
johan

(sorry for the delayed reply, I've been at a music festival for the last
four days).