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

[Doug Evans <dje at transmeta dot com>]

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.