* CGEN: RFA: Fast vs Full with scache-pbb
@ 2000-09-01 11:53 Dave Brolley
2000-09-03 19:23 ` Ben Elliston
2000-09-05 9:17 ` Dave Brolley
0 siblings, 2 replies; 7+ messages in thread
From: Dave Brolley @ 2000-09-01 11:53 UTC (permalink / raw)
To: cgen
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
}
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: CGEN: RFA: Fast vs Full with scache-pbb
2000-09-01 11:53 CGEN: RFA: Fast vs Full with scache-pbb Dave Brolley
@ 2000-09-03 19:23 ` Ben Elliston
2000-09-05 9:17 ` Dave Brolley
1 sibling, 0 replies; 7+ messages in thread
From: Ben Elliston @ 2000-09-03 19:23 UTC (permalink / raw)
To: Dave Brolley; +Cc: cgen development
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: CGEN: RFA: Fast vs Full with scache-pbb
2000-09-01 11:53 CGEN: RFA: Fast vs Full with scache-pbb Dave Brolley
2000-09-03 19:23 ` Ben Elliston
@ 2000-09-05 9:17 ` Dave Brolley
2000-09-06 13:37 ` Doug Evans
1 sibling, 1 reply; 7+ messages in thread
From: Dave Brolley @ 2000-09-05 9:17 UTC (permalink / raw)
To: cgen
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
> }
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: CGEN: RFA: Fast vs Full with scache-pbb
2000-09-05 9:17 ` Dave Brolley
@ 2000-09-06 13:37 ` Doug Evans
2000-09-06 14:17 ` Dave Brolley
0 siblings, 1 reply; 7+ messages in thread
From: Doug Evans @ 2000-09-06 13:37 UTC (permalink / raw)
To: Dave Brolley; +Cc: cgen
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".
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: CGEN: RFA: Fast vs Full with scache-pbb
2000-09-06 13:37 ` Doug Evans
@ 2000-09-06 14:17 ` Dave Brolley
2000-09-06 14:45 ` Doug Evans
0 siblings, 1 reply; 7+ messages in thread
From: Dave Brolley @ 2000-09-06 14:17 UTC (permalink / raw)
To: Doug Evans; +Cc: cgen
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: CGEN: RFA: Fast vs Full with scache-pbb
2000-09-06 14:17 ` Dave Brolley
@ 2000-09-06 14:45 ` Doug Evans
2000-09-08 11:19 ` Dave Brolley
0 siblings, 1 reply; 7+ messages in thread
From: Doug Evans @ 2000-09-06 14:45 UTC (permalink / raw)
To: Dave Brolley; +Cc: cgen
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: CGEN: RFA: Fast vs Full with scache-pbb
2000-09-06 14:45 ` Doug Evans
@ 2000-09-08 11:19 ` Dave Brolley
0 siblings, 0 replies; 7+ messages in thread
From: Dave Brolley @ 2000-09-08 11:19 UTC (permalink / raw)
To: Doug Evans; +Cc: cgen
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2000-09-08 11:19 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-09-01 11:53 CGEN: RFA: Fast vs Full with scache-pbb Dave Brolley
2000-09-03 19:23 ` Ben Elliston
2000-09-05 9:17 ` Dave Brolley
2000-09-06 13:37 ` Doug Evans
2000-09-06 14:17 ` Dave Brolley
2000-09-06 14:45 ` Doug Evans
2000-09-08 11:19 ` Dave Brolley
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).