# HG changeset patch
# User Gabe Black [EMAIL PROTECTED]
# Date 1226041356 28800
# Node ID 94ef4905a939b782105ce0ebb3c063451744fb3d
# Parent 61c838ecc2259cd0d60dc7d7b9bf0e92cb1a89da
X86: Make the timing simple CPU handle variable length instructions.
diff --git a/src/cpu/simple/timing.cc
* build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-atomic passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed.
['g++', '-o', 'build/SPARC_SE/m5.fast.unstripped', 'build*
It would seem to me that getuint64_t should automatically do that
for you. I.e., it should grab the size of memory that it's got and
then give you the size that you need.
Nate
On Sat, Nov 8, 2008 at 6:02 PM, Steve Reinhardt [EMAIL PROTECTED] wrote:
Just looking at this code, can we put a
Thanks, Gabe. It's cool to have this working. Just a few minor things:
- It looks like the two requests are issued to the cache
sequentially... did you consider issuing them concurrently? I don't
see a reason why this wouldn't work, though it would be a little more
complex (since the responses
I'm sure we could. This is useful anywhere you need to get an endian
converted value out of a packet without knowing the size ahead of time.
Does that happen often? I think this was the first time I'd run into it,
but I haven't messed with a lot of the device stuff.
Gabe
Steve Reinhardt wrote:
Is that code not in all of the other completeAcc ISA functions?
On Sat, Nov 8, 2008 at 10:20 PM, Gabe Black [EMAIL PROTECTED] wrote:
I'm sure we could. This is useful anywhere you need to get an endian
converted value out of a packet without knowing the size ahead of time.
Does that happen
Not as far as I know. For SPARC at least you always know based on the
instruction what the memory size is (load word, load byte, etc).
Gabe
Korey Sewell wrote:
Is that code not in all of the other completeAcc ISA functions?
On Sat, Nov 8, 2008 at 10:20 PM, Gabe Black [EMAIL PROTECTED] wrote:
What happens on big endian systems? Do the low order bits get set to 0,
or do you just shove everything down to the bottom? What happens if the
value you want doesn't fit in a uint64_t?
Also more generally in the current code, if the underlying data pointer
in the packet isn't aligned properly to
Second, handleLockedWrite is called on any swap, but it isn't until
later, and only for conditional swaps, where that extra data field is
actually set to anything. That means that in all cases you're actually
trashing something useful, and for conditional swaps you're actually
then
A get method is already defined in packet_access.hh.
Ali
On Nov 8, 2008, at 9:02 PM, Steve Reinhardt wrote:
Just looking at this code, can we put a more generic version of this
somewhere, like as a Packet method? I don't know how many other
places already do this, but other than the
I'm actually using it in the patch...
Gabe
Ali Saidi wrote:
A get method is already defined in packet_access.hh.
Ali
On Nov 8, 2008, at 9:02 PM, Steve Reinhardt wrote:
Just looking at this code, can we put a more generic version of this
somewhere, like as a Packet method? I don't
Steve Reinhardt wrote:
Thanks, Gabe. It's cool to have this working. Just a few minor things:
- It looks like the two requests are issued to the cache
sequentially... did you consider issuing them concurrently? I don't
see a reason why this wouldn't work, though it would be a little more
I actually have to reiterate that the fact that we do the endian
conversion in the get function and not in the actual read instruction
is broken in my opinion. Stores should be doing a htog (because
register values are stored in the host form so we can do math on them)
and loads should be doing a
As far as this code though, the problem would still exist. You'd have to
still switch on the size to figure out how to do the conversion in the
instruction.
Gabe
nathan binkert wrote:
I actually have to reiterate that the fact that we do the endian
conversion in the get function and not in the
14 matches
Mail list logo
