Ok, I figured it out. This should now be fixed. By the way, your program
is probably the prettiest test case I've run on m5 to date :-).
Gabe
Gabe Black wrote:
Darn it. I need to double check -then- email. I had int16_t in the
original patch so I suspect the sign extension in predecoder.cc
On Wed, 16 Sep 2009, Gabe Black wrote:
Ok, I figured it out. This should now be fixed.
I can confirm that the various changes checked in overnight have fixed the
various issues I was seeing. Thanks!
By the way, your program
is probably the prettiest test case I've run on m5 to date :-).
On Tue, 15 Sep 2009, Gabriel Michael Black wrote:
As promised here's a patch. It turns out I was already attempting to
sign extend the second operand (that's what sop2 is supposed to be
doing), I just dropped the ball for the immediate variant.
Unfortunately this patch doesn't seem to fix
OK, I think I've fixed this.
The key is the line:
code = int16_t simm8 = (int16_t)((int8_t)imm8); + code
I had to change your patch to have the extra int8_t cast, or else
it wasn't sign extending the result.
Below is the updated patch, which works for my test.
Note, scons
I don't think you actually need the explicit (int16_t) cast here. Not
a big deal though of course.
Nate
On Wed, Sep 16, 2009 at 9:22 AM, Vince Weaver vi...@csl.cornell.edu wrote:
OK, I think I've fixed this.
The key is the line:
code = int16_t simm8 =
int8_t was definitely wrong. What I meant was int16_t, but as Nate says
an explicit cast might not be necessary at all. If you could please give
the castless version a try and it works, I'll check that in.
Gabe
nathan binkert wrote:
I don't think you actually need the explicit (int16_t) cast
Darn it. I need to double check -then- email. I had int16_t in the
original patch so I suspect the sign extension in predecoder.cc isn't
working properly, but don't worry about this any more if you don't want
to. I'll set up your regression and figure this out directly. Sorry for
the run
Never mind. I realized what was going on as I was getting ready for
work this morning. imm is the same size for all microops, but when
it's stored internal to the microop it gets truncated into a 16 bit
immediate value. A better solution might be to make the wripi
instruction sign extend
On Tue, 15 Sep 2009, Gabriel Michael Black wrote:
Never mind. I realized what was going on as I was getting ready for
work this morning. imm is the same size for all microops, but when
it's stored internal to the microop it gets truncated into a 16 bit
immediate value. A better solution
Gabriel Michael Black wrote:
Quoting Vince Weaver vi...@csl.cornell.edu:
On Tue, 15 Sep 2009, Gabriel Michael Black wrote:
Never mind. I realized what was going on as I was getting ready for
work this morning. imm is the same size for all microops, but when
it's stored internal to
Hello
the loop instructions on x86 are broken, they seem to be using a
16-bit immediate for the offset instead of the proper signed 8-bit one.
This very obviously breaks instructions trying to loop backward.
The patch below fixes things on my regression test, though I might have
something
Thank you for your patches. I'm a little buried right now, but they
are important, I -will- get to them eventually, and they'll more than
likely end up in the tree. Thanks!
Gabe
Quoting Vince Weaver vi...@csl.cornell.edu:
Hello
the loop instructions on x86 are broken, they seem to be
Gabe,
If you didn't know, you can just take his patches and stick them in
your queue and use the -u option to qref to add his name to the
patch so he gets credit when you push.
Also, when people use hg email, you can just take the patch as is
and stick it in your queue since it contains all of
13 matches
Mail list logo
