I'm running into a problem with running a SPARC SE-mode multithreaded
program on a multiprocessor (but not SMT) O3 system. Part of the clone()
syscall emulation copies the FP regs like this:
for (int i = 0; i < SparcISA::NumFloatRegs; ++i) {
dest->setFloatRegBits(i, src->readFloatRegB
On Tue, Apr 14, 2009 at 1:43 PM, Korey Sewell wrote:
> Well, I think the problem was (other than me just messing up), was that
> nowhere in the O3 code does it use "IsSerializing" anymore. Matter of fact,
> nowhere in any CPU model is that used anymore. (grep -rn "IsSerializing"
> src/cpu/*). So
Well, I think the problem was (other than me just messing up), was that
nowhere in the O3 code does it use "IsSerializing" anymore. Matter of fact,
nowhere in any CPU model is that used anymore. (grep -rn "IsSerializing"
src/cpu/*). So I'm not sure that particular flag is necessary since it seems
t
The last I looked at the code, when you called the syscall function in
the exec context it eventually made O3 flush the pipeline. I don't
know if anything happened to that, but I would be moderately surprised
if it vanished between now and then, but who knows. You also
definitely want to ma
OO OK... I see what happened... I'm messing up myself basically.
When I was at MIPS we kept a different tree than from M5-dev. So when I
merged in the new code from when I was at MIPS, I basically overwrote the
'SerializeAfter' change for the O3 model. And since there wasnt (and still
isnt
On Tue, Apr 14, 2009 at 11:42 AM, nathan binkert wrote:
> I'll admit that I'm not following this thread very closely, but the
> biggest question I have is: is it necessary to actually do the
> translation in the translation pipe stage? Can't it just be there to
> burn a cycle while you do the ac
I vaguely recall that at some point the single IsSerializing flag got
replaced by the SerializeBefore and SerializeAfter flags to provide a little
more fine-grain control... some instructions just need one or the other and
some need both.
Now that I've looked at 'hg annotate', your name is on the
I'll admit that I'm not following this thread very closely, but the
biggest question I have is: is it necessary to actually do the
translation in the translation pipe stage? Can't it just be there to
burn a cycle while you do the actual translation when executing the
read?
Nate
On Tue, Apr 14,
Thanks for the insight.
Looks like O3 has moved from squashing after system call to marking a the
"SerializeAfter" flag for system calls.
MIPS had system calls marked as "IsSerializing" which (from grep'ing around)
happens to be a flag that isn't even used in the code anymore (delete?!).
On Tue
The syscall instruction is marked as serializing, and it's up to the CPU
model to look at that flag and do whatever (if anything) is necessary to
make sure that any register or memory changes that happen in the syscall are
seen by the subsequent instructions--typically this means flush the
pipeline
I'm pretty sure that was in the code a while back, but I can not locate this
currently in O3. Has this been removed?
In SE mode, I would think squashing after a system call is necessary because
real system calls would need to save/restore context to Memory before
returning to user-mode execution s
Comments below:
> There's still one aspect that confuses me though: why does translation
> need to be separated out of xc->read() and xc->write()? The model for
> all the other CPUs is that translation is part of that process. I can
> believe that in the InOrder model you may want to separate th
Ok, so it seems lie the following is happening:
qdo submits the jobs to the pool. Normally, we just check for a
timeout here, and if one occurs we're done and execute M5 locally.
However, the last two days we've gotten lucky, and managed to sneak in
a job in the middle of the otherwise busy
See /z/m5/regression/regress-2009-04-14-03:00:01 for details.
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
14 matches
Mail list logo
