Oooooh. I get it. I guess this proves I shouldn't send emails when I'm
tired.
Gabe
Gabe Black wrote:
> I'm trying to use a TypedBufferArg to get at a small array of
> uint64_ts, but I think the following snippet of code from that class is
> tripping me up:
>
> T &operator[](int i) { return ((T *)bufPtr)[i]; }
>
> T in this case is uint64_t[3], and I think it has to be because the
> amount of space allocated for the buffer is equal to sizeof(T). If I
> want to be able to hold all the elements in the buffer, I can't for
> instance make it a uint64_t *. In the line above, what happens is that
> the bufPtr is cast to a T*, or in other words a (uint64_t[3]) *. That's
> probably syntactically wrong, but you get the idea. Then the subscript
> of i is applied, so for example if i was 2 you'd end up with bufPtr +
> sizeof(uint64_t[3]) * 2 which is off the end of the buffer. The data
> type you get out the end is also not useful because it's a uint64_t[3],
> not a uint64_t like I would expect. I'm not sure what the right way to
> implement what this code seems to be going for is, but I'm pretty sure
> this is not it. Does anyone have a suggestion for how to fix it? Maybe
> we need a new type called TypedBufferArgArray? If it's too obnoxious to
> fix we should probably nuke that operator and I'll rework my code to do
> without it.
>
> Gabe
> _______________________________________________
> m5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/m5-dev
>
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
