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:

AtomicSimpleCPU::read(Addr addr, int32_t &data, unsigned flags)
    return read(addr, (uint32_t&)data, flags);

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

gem5-dev mailing list

Reply via email to