CGEN: RFA: Fast vs Full with scache-pbb

CGEN: RFA: Fast vs Full with scache-pbb

[Dave Brolley]

Hi,

The simulator port I'm working on was crashing when the sim was
run without -t. It is configured with-scache-pbb. 

It turns out that the call to <cpu>_pbb_begin in the generated
<cpu>_sem_x_begin was passing STATE_RUN_FAST_P (CPU_STATE
(current_cpu)) as the 'fast_p' argument. Now this flag will be 0
if -t is specified and 1 otherwise. However the rest of the
generated code (mloop.c, sem.c) is not set up for dynamic
fast/full switching (although it looks like some work was done
toward this goal in the past). As a result, only the 'sem_full'
function in the idesc_table is initialized for my build. Passing
fast_p==1 causes the semantic engine to attempt to use 'sem_fast'
function which is not initialized.

The attached patch changes <cpu>_sem_x_begin to honour any FAST_P
macro which may be defined and to otherwise assume that
FAST_P==0. I #if'd out the orignal code since it will apply
someday when dynamic fast/full switching is enabled in the rest
of the cgen-generated code.

OK to commit? Once again I tested on fr30, m32r and 2 internal
ports which cover a range of sem-switch/non sem-switch/scache/pbb
configurations.

Dave
Index: sim.scm
===================================================================
RCS file: /cvs/src/src/cgen/sim.scm,v
retrieving revision 1.3
diff -c -p -r1.3 sim.scm
*** sim.scm	2000/08/24 15:35:47	1.3
--- sim.scm	2000/09/01 18:38:15
*************** struct scache {
*** 1884,1895 ****
        "--begin--" () () '(c-code VOID "\
    {
  #if WITH_SCACHE_PBB_@CPU@
! #ifdef DEFINE_SWITCH
      /* In the switch case FAST_P is a constant, allowing several optimizations
         in any called inline functions.  */
      vpc = @cpu@_pbb_begin (current_cpu, FAST_P);
  #else
      vpc = @cpu@_pbb_begin (current_cpu, STATE_RUN_FAST_P (CPU_STATE (current_cpu)));
  #endif
  #endif
    }
--- 1884,1899 ----
        "--begin--" () () '(c-code VOID "\
    {
  #if WITH_SCACHE_PBB_@CPU@
! #if defined DEFINE_SWITCH || defined FAST_P
      /* In the switch case FAST_P is a constant, allowing several optimizations
         in any called inline functions.  */
      vpc = @cpu@_pbb_begin (current_cpu, FAST_P);
  #else
+ #if 0 /* cgen engine can't handle dynamic fast/full switching yet.  */
      vpc = @cpu@_pbb_begin (current_cpu, STATE_RUN_FAST_P (CPU_STATE (current_cpu)));
+ #else
+     vpc = @cpu@_pbb_begin (current_cpu, 0);
+ #endif
  #endif
  #endif
    }

Re: CGEN: RFA: Fast vs Full with scache-pbb

[Ben Elliston]

Hi Dave,

   OK to commit? Once again I tested on fr30, m32r and 2 internal ports
   which cover a range of sem-switch/non sem-switch/scache/pbb
   configurations.

It looks okay to me.

Ben

Re: CGEN: RFA: Fast vs Full with scache-pbb

[Dave Brolley]

Approved by Frank and Ben and committed.

Dave

Dave Brolley wrote:
> 
> Hi,
> 
> The simulator port I'm working on was crashing when the sim was
> run without -t. It is configured with-scache-pbb.
> 
> It turns out that the call to <cpu>_pbb_begin in the generated
> <cpu>_sem_x_begin was passing STATE_RUN_FAST_P (CPU_STATE
> (current_cpu)) as the 'fast_p' argument. Now this flag will be 0
> if -t is specified and 1 otherwise. However the rest of the
> generated code (mloop.c, sem.c) is not set up for dynamic
> fast/full switching (although it looks like some work was done
> toward this goal in the past). As a result, only the 'sem_full'
> function in the idesc_table is initialized for my build. Passing
> fast_p==1 causes the semantic engine to attempt to use 'sem_fast'
> function which is not initialized.
> 
> The attached patch changes <cpu>_sem_x_begin to honour any FAST_P
> macro which may be defined and to otherwise assume that
> FAST_P==0. I #if'd out the orignal code since it will apply
> someday when dynamic fast/full switching is enabled in the rest
> of the cgen-generated code.
> 
> OK to commit? Once again I tested on fr30, m32r and 2 internal
> ports which cover a range of sem-switch/non sem-switch/scache/pbb
> configurations.
> 
> Dave
> 
>   -----------------------------------------------------------------
> Index: sim.scm
> ===================================================================
> RCS file: /cvs/src/src/cgen/sim.scm,v
> retrieving revision 1.3
> diff -c -p -r1.3 sim.scm
> *** sim.scm     2000/08/24 15:35:47     1.3
> --- sim.scm     2000/09/01 18:38:15
> *************** struct scache {
> *** 1884,1895 ****
>         "--begin--" () () '(c-code VOID "\
>     {
>   #if WITH_SCACHE_PBB_@CPU@
> ! #ifdef DEFINE_SWITCH
>       /* In the switch case FAST_P is a constant, allowing several optimizations
>          in any called inline functions.  */
>       vpc = @cpu@_pbb_begin (current_cpu, FAST_P);
>   #else
>       vpc = @cpu@_pbb_begin (current_cpu, STATE_RUN_FAST_P (CPU_STATE (current_cpu)));
>   #endif
>   #endif
>     }
> --- 1884,1899 ----
>         "--begin--" () () '(c-code VOID "\
>     {
>   #if WITH_SCACHE_PBB_@CPU@
> ! #if defined DEFINE_SWITCH || defined FAST_P
>       /* In the switch case FAST_P is a constant, allowing several optimizations
>          in any called inline functions.  */
>       vpc = @cpu@_pbb_begin (current_cpu, FAST_P);
>   #else
> + #if 0 /* cgen engine can't handle dynamic fast/full switching yet.  */
>       vpc = @cpu@_pbb_begin (current_cpu, STATE_RUN_FAST_P (CPU_STATE (current_cpu)));
> + #else
> +     vpc = @cpu@_pbb_begin (current_cpu, 0);
> + #endif
>   #endif
>   #endif
>     }

Re: CGEN: RFA: Fast vs Full with scache-pbb

[Doug Evans]

Dave Brolley writes:
 > > It turns out that the call to <cpu>_pbb_begin in the generated
 > > <cpu>_sem_x_begin was passing STATE_RUN_FAST_P (CPU_STATE
 > > (current_cpu)) as the 'fast_p' argument. Now this flag will be 0
 > > if -t is specified and 1 otherwise. However the rest of the
 > > generated code (mloop.c, sem.c) is not set up for dynamic
 > > fast/full switching (although it looks like some work was done
 > > toward this goal in the past). As a result, only the 'sem_full'
 > > function in the idesc_table is initialized for my build. Passing
 > > fast_p==1 causes the semantic engine to attempt to use 'sem_fast'
 > > function which is not initialized.

What do you mean by "dynamic fast/full switching".

Re: CGEN: RFA: Fast vs Full with scache-pbb

[Dave Brolley]

Doug Evans wrote:
> 
> Dave Brolley writes:
>  > > It turns out that the call to <cpu>_pbb_begin in the generated
>  > > <cpu>_sem_x_begin was passing STATE_RUN_FAST_P (CPU_STATE
>  > > (current_cpu)) as the 'fast_p' argument. Now this flag will be 0
>  > > if -t is specified and 1 otherwise. However the rest of the
>  > > generated code (mloop.c, sem.c) is not set up for dynamic
>  > > fast/full switching (although it looks like some work was done
>  > > toward this goal in the past). As a result, only the 'sem_full'
>  > > function in the idesc_table is initialized for my build. Passing
>  > > fast_p==1 causes the semantic engine to attempt to use 'sem_fast'
>  > > function which is not initialized.
> 
> What do you mean by "dynamic fast/full switching".

As far as I can tell, one can supply two versions of the semantic
functions: 'fast' or 'full'. It looks like the intent was that
the use of fast vs full semantics could be switched on the fly at
simulation time via the 'fast_p' parameter to 'extract' and
'execute', however this capability is currently thwarted by at
least three things:

1) The generated code in mloop.c contains '#define FAST_P 0' or
'#define FAST_P 1' which is then passed to extract and execute.

2) Only one of 'sem_fast' or 'sem_full' is initialized in the
idesc_table based on the FAST_P macro(sem.c)

3) sc->argbug.semantic contains sem_fast and sem_full members,
but is a union so you really only get one or the other.

My patch simply forces the call to <cpu>_pbb_begin to honour the
definition of FAST_P like the rest of sem.c does.

Dave

Re: CGEN: RFA: Fast vs Full with scache-pbb

[Doug Evans]

Dave Brolley writes:
 > Doug Evans wrote:
 > > 
 > > Dave Brolley writes:
 > >  > > It turns out that the call to <cpu>_pbb_begin in the generated
 > >  > > <cpu>_sem_x_begin was passing STATE_RUN_FAST_P (CPU_STATE
 > >  > > (current_cpu)) as the 'fast_p' argument. Now this flag will be 0
 > >  > > if -t is specified and 1 otherwise. However the rest of the
 > >  > > generated code (mloop.c, sem.c) is not set up for dynamic
 > >  > > fast/full switching (although it looks like some work was done
 > >  > > toward this goal in the past). As a result, only the 'sem_full'
 > >  > > function in the idesc_table is initialized for my build. Passing
 > >  > > fast_p==1 causes the semantic engine to attempt to use 'sem_fast'
 > >  > > function which is not initialized.
 > > 
 > > What do you mean by "dynamic fast/full switching".
 > 
 > As far as I can tell, one can supply two versions of the semantic
 > functions: 'fast' or 'full'. It looks like the intent was that
 > the use of fast vs full semantics could be switched on the fly at
 > simulation time via the 'fast_p' parameter to 'extract' and
 > 'execute',

There are two separate things here.  Don't get them confused.
1) ability to select fast/full when the user invokes the simulator
   - this is the normal case
   - one can claim this is a variant of (2) but that's not necessarily
     the case so let's keep it distinct
2) ability to select fast/full while the simulator is running
   - I can't remember if I played much with this.  One use would be
     when one wants to trace selective pieces of code or not trace
     until some "event" occured.
     (I'm using a _very_ loose definition of "event" here.)

 > however this capability is currently thwarted by at
 > least three things:
 > 
 > 1) The generated code in mloop.c contains '#define FAST_P 0' or
 > '#define FAST_P 1' which is then passed to extract and execute.

Yep.  Note that because it's a constant, gcc can do constant folding on it.

 > 2) Only one of 'sem_fast' or 'sem_full' is initialized in the
 > idesc_table based on the FAST_P macro(sem.c)

But the file may get compiled twice.

Note this code in, for example, m32r/sem.c:

/* This is used so that we can compile two copies of the semantic code,
   one with full feature support and one without that runs fast(er).
   FAST_P, when desired, is defined on the command line, -DFAST_P=1.  */
#if FAST_P
#define SEM_FN_NAME(cpu,fn) XCONCAT3 (cpu,_semf_,fn)
#undef TRACE_RESULT
#define TRACE_RESULT(cpu, abuf, name, type, val)
#else
#define SEM_FN_NAME(cpu,fn) XCONCAT3 (cpu,_sem_,fn)
#endif

 > 3) sc->argbug.semantic contains sem_fast and sem_full members,
 > but is a union so you really only get one or the other.

Not quite.  Whether you get one, the other, or both, depends
on how things are built.  From sim/common/cgen-engine.h:

/* In the ARGBUF struct, a pointer to the semantic routine for the insn.  */

union sem {
#if ! WITH_SEM_SWITCH_FULL
  SEMANTIC_FN *sem_full;
#endif
#if ! WITH_SEM_SWITCH_FAST
  SEMANTIC_FN *sem_fast;
#endif
#if WITH_SEM_SWITCH_FULL || WITH_SEM_SWITCH_FAST
#ifdef __GNUC__
  void *sem_case;
#else
  int sem_case;
#endif
#endif
};

 > My patch simply forces the call to <cpu>_pbb_begin to honour the
 > definition of FAST_P like the rest of sem.c does.

There may still be a need for your patch, but maybe you could confirm
you're building your simulator the way the m32r and fr30 sims are?
I wonder if there's a target specific tweak that is the more
appropriate fix.

Re: CGEN: RFA: Fast vs Full with scache-pbb

[Dave Brolley]

Doug Evans wrote:

>  Dave Brolley wrote:
>  > My patch simply forces the call to <cpu>_pbb_begin to honour the
>  > definition of FAST_P like the rest of sem.c does.
> 
> There may still be a need for your patch, but maybe you could confirm
> you're building your simulator the way the m32r and fr30 sims are?
> I wonder if there's a target specific tweak that is the more
> appropriate fix.

Well, the fr30 and m32r both use '-mono -fast -pbb -switch
sem-switch' whereas I'm using '-mono -pbb'. Hence the lack of
'fast' semantic functions which led to the problem when the
generated 'sem.c' passed 'fast_p==1' to <arch>_pbb_begin.

I think my patch is still necessary since the rest of sem.c
honours the definition of the FAST_P macro and assumes that no
definition means (! FAST_P).

Dave