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 defined as "int8_t". It seems like a weird
>>>> hidden restriction to say that there are operand types you can declare but
>>>> can't use on memory, and that you're pushing a somewhat arbitrary internal
>>>> implementation decision up to the level of language visibility, which is
>>>> going the wrong direction. I'm not sure what the right solution is, but
>>>> even if it's the brute force one of creating a bunch more read/write
>>>> function templates in the CPU implementations, I think that's preferable.
>>> [...]
>>>
>>> The unsigned thing is sort of a weird gotcha. I'd like to avoid adding a
>>> lot of bulk to the CPU models since they're already fairly chunky and it
>>> makes them harder to reason about looking through the code, but it would
>>> be great to straighten this out. One possibility might be the technique
>>> I used with the endianness changing functions in src/sim/byteswap.hh.
>>> Things are built up in layers there:
>>> [...]
>> I think some kind of additional set of template instantiations should
>> do it. I just noticed that we already have:
>>
>> template<>
>> Fault
>> AtomicSimpleCPU::read(Addr addr, int32_t &data, unsigned flags)
>> {
>> return read(addr, (uint32_t&)data, flags);
>> }
>>
>> template<>
>> Fault
>> AtomicSimpleCPU::write(int32_t data, Addr addr, unsigned flags, uint64_t
>> *res)
>> {
>> return write((uint32_t)data, addr, flags, res);
>> }
>>
>> .. and similar for TimingSimpleCPU; do we just need to extend these to
>> int8_t and int16_t, and maybe add similar sets in
>> base_dynamic_inst.hh?
>>
>> Steve
>> _______________________________________________
>> gem5-dev mailing list
>> gem5-dev@m5sim.org
>> http://m5sim.org/mailman/listinfo/gem5-dev
> Oh yeah, I guess we're already doing something like that, and that glob
> of code was just instantiating different versions of the function. Could
> we reduce the amount of text by moving it into the header? There isn't a
> lot of actual information there in all that text, and we're talking
> about doubling it. I don't have a better idea, though.
>
> Gabe
> _______________________________________________
> gem5-dev mailing list
> gem5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/gem5-dev
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?
Gabe
_______________________________________________
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev
