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
