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
