On 06/12/11 16:29, Steve Reinhardt wrote:
On Sun, Jun 12, 2011 at 1:05 AM, Gabe Black gbl...@eecs.umich.edu wrote:
I was thinking about this today, and if we expand the read/write
functions to handle signed types too, we're really just expanding the
arbitrary set of types they can handle, not
On 06/04/11 09:32, Steve Reinhardt wrote:
On Sat, Jun 4, 2011 at 1:57 AM, Gabe Black gbl...@eecs.umich.edu wrote:
To clarify, is this signed/unsigned issue something we need to deal with
before this patch goes in, or can it be dealt with separately later?
I'd like to see it handled before the
On Sun, Jun 12, 2011 at 1:05 AM, Gabe Black gbl...@eecs.umich.edu wrote:
I was thinking about this today, and if we expand the read/write
functions to handle signed types too, we're really just expanding the
arbitrary set of types they can handle, not removing the limitation that
you have to
On 05/31/11 00:13, Gabe Black wrote:
On 05/30/11 21:57, Steve Reinhardt wrote:
On Mon, May 30, 2011 at 1:33 PM, Gabe Black gbl...@eecs.umich.edu wrote:
On 05/30/11 09:47, Steve Reinhardt wrote:
Anyway, it seems very odd to have to say (int8_t)Mem.ub when we already
have a .sb operand type
On Sat, Jun 4, 2011 at 1:57 AM, Gabe Black gbl...@eecs.umich.edu wrote:
To clarify, is this signed/unsigned issue something we need to deal with
before this patch goes in, or can it be dealt with separately later?
I'd like to see it handled before the patch is committed, mostly
because I'm
On 05/30/11 21:57, Steve Reinhardt wrote:
On Mon, May 30, 2011 at 1:33 PM, Gabe Black gbl...@eecs.umich.edu wrote:
On 05/30/11 09:47, Steve Reinhardt wrote:
Anyway, it seems very odd to have to say (int8_t)Mem.ub when we already
have a .sb operand type defined as int8_t. It seems like a
On 2011-05-28 21:58:27, Steve Reinhardt wrote:
The description is a little general; can you be more specific about what
this change is doing? I see that you're getting rid of the size from the
memory access operands and encoding that in the ctype instead, which seems
fine. However
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/655/
---
(Updated 2011-05-30 00:18:31.344077)
Review request for Default, Ali Saidi, Gabe
On 2011-05-28 21:58:27, Steve Reinhardt wrote:
The description is a little general; can you be more specific about what
this change is doing? I see that you're getting rid of the size from the
memory access operands and encoding that in the ctype instead, which seems
fine. However
On 05/30/11 09:47, Steve Reinhardt wrote:
On 2011-05-28 21:58:27, Steve Reinhardt wrote:
The description is a little general; can you be more specific about what
this change is doing? I see that you're getting rid of the size from the
memory access operands and encoding that in the ctype
On Mon, May 30, 2011 at 1:33 PM, Gabe Black gbl...@eecs.umich.edu wrote:
On 05/30/11 09:47, Steve Reinhardt wrote:
Anyway, it seems very odd to have to say (int8_t)Mem.ub when we already
have a .sb operand type defined as int8_t. It seems like a weird hidden
restriction to say that there
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/655/#review1276
---
The description is a little general; can you be more specific about what
12 matches
Mail list logo
