adjusting cgen

adjusting cgen

[Johan Rydberg]

Hi!

I'm hacking my way through the CGEN sources to adopt them to generate
targets to a simulator I'm working on.  What I have done is to clone 
the SID-part of CGEN and adjust it to generate code that suits my
simulator.  I better let you know that I know neither Scheme or Lisp.

And I have some questions;

1)  Is it possible to adjust CGEN to recognize on-page branches?
    This could be a huge optimization for me, since this will eliminate
    the full tlb+mmu lookup for (near) branches.  

2)  Is it possible to adjust the -gen-argbuf-elm fn in sid-decode.scm to
    generate bit fields instead of full integers?  Currently it generates
    code similar to this;

    struct { /*  */
      UINT f_rd;
      UINT f_sr;
    } sfmt_mfsr;

    What I would like to do is to reduce the size of the sem_fields union
    to a total of 32-bits (for a 32-bit architecture).  I guess this is
    best done by emitting bit fields, like;

    struct { /*  */
      UINT f_rd : 8;
      UINT f_sr : 8;
    } sfmt_mfsr;
   
    The bit field size should be the length of the ifield, rounded up to
    the next multiple of eight, but only for fields longer than 3 bits.
    (I assume that fields longer than 3 bits is normally either used as 
     indexes in for example the register file, or immediates)

    Is this possible?

I hope some of you understand what I'm trying to communicate (it's
4 am here).

If you're intressted in the simulator, you can find information (ie
the sources) at http://savannah.gnu.org/projects/guss/ .

regards
johan

Re: adjusting cgen

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 1666 bytes --]

Hi -


> [...]
> 1)  Is it possible to adjust CGEN to recognize on-page branches?
>     This could be a huge optimization for me, since this will eliminate
>     the full tlb+mmu lookup for (near) branches.  

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.


> 2)  Is it possible to adjust the -gen-argbuf-elm fn in sid-decode.scm to
>     generate bit fields instead of full integers?  [...]
>     What I would like to do is to reduce the size of the sem_fields union
>     to a total of 32-bits (for a 32-bit architecture).  [...]

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.


> 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.)


- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: adjusting cgen

[Johan Rydberg]

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).