From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Evans To: Dave Brolley Cc: cgen@sources.redhat.com Subject: Re: CGEN: RFA: Fast vs Full with scache-pbb Date: Wed, 06 Sep 2000 14:45:00 -0000 Message-id: <14774.47827.940964.97339@casey.transmeta.com> References: <39AFFB1F.99F2A190@redhat.com> <39B51C99.3A2FC29C@redhat.com> <14774.43800.665729.386324@casey.transmeta.com> <39B6B44B.A541F8A5@redhat.com> X-SW-Source: 2000-q3/msg00078.html Dave Brolley writes: > Doug Evans wrote: > > > > Dave Brolley writes: > > > > It turns out that the call to _pbb_begin in the generated > > > > _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 _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.