On Tue, Jul 13, 2010 at 5:47 PM, Gabriel Michael Black
wrote:
> Quoting Steve Reinhardt :
>
>> On Tue, Jul 13, 2010 at 11:20 AM, Gabe Black
>> wrote:
>>>
>>> I can't say it was -the- reason, but one reason is that the TLBs as is
>>> don't actually send the packets for the CPU, so they can't split
On Jul 13, 2010, at 7:47 PM, Gabriel Michael Black wrote:
>
> Yes, the predecoder is sort of stateful. It's stateful in that it keeps
> state, but no attempt was made (yet, maybe) to make it work with mispredicts,
> for instance. The idea was that it could speculatively update state to keep
>
Quoting Steve Reinhardt :
On Tue, Jul 13, 2010 at 11:20 AM, Gabe Black wrote:
I can't say it was -the- reason, but one reason is that the TLBs as is
don't actually send the packets for the CPU, so they can't split
anything into multiple transactions easily. I'm intrigued by the idea of
putting
Quoting Ali Saidi :
On Tue, 13 Jul 2010 11:20:26 -0700, Gabe Black
wrote:
This also brings up another idea I've been rolling around for a while.
Why is all the control state local to the miscregfile/it's decendant the
ISA object? Why don't we put control state that matters to the TLB, or
at
On Tue, Jul 13, 2010 at 11:20 AM, Gabe Black wrote:
> I can't say it was -the- reason, but one reason is that the TLBs as is
> don't actually send the packets for the CPU, so they can't split
> anything into multiple transactions easily. I'm intrigued by the idea of
> putting the TLB behind a port
On Tue, 13 Jul 2010 11:20:26 -0700, Gabe Black
wrote:
> This also brings up another idea I've been rolling around for a while.
> Why is all the control state local to the miscregfile/it's decendant the
> ISA object? Why don't we put control state that matters to the TLB, or
> at least a copy of
Gabe Black wrote:
> Steve Reinhardt wrote:
>
>> All the discussion of different extensions to TimingSimpleCPU got me
>> thinking again about what a mess it is. I walked through the code
>> with Brad & Joel a few weeks ago, and it's still the same basic
>> structure of everything being driven by
Steve Reinhardt wrote:
> All the discussion of different extensions to TimingSimpleCPU got me
> thinking again about what a mess it is. I walked through the code
> with Brad & Joel a few weeks ago, and it's still the same basic
> structure of everything being driven by callbacks, with numerous cas
On Tue, Jul 13, 2010 at 10:35 AM, Korey Sewell wrote:
>
>> Thoughts? Volunteers? :-)
>
> I had thoughts on similar tasks where you would need to do some editing on a
> memory request
> after it's been sent to the CPU.
>
> I wouldnt mind a shim object so to speak, but what about deriving a new
>
> Thoughts? Volunteers? :-)
>
I had thoughts on similar tasks where you would need to do some editing on a
memory request
after it's been sent to the CPU.
I wouldnt mind a shim object so to speak, but what about deriving a new
class of port to handle this?
There is already a "translating" port
All the discussion of different extensions to TimingSimpleCPU got me
thinking again about what a mess it is. I walked through the code
with Brad & Joel a few weeks ago, and it's still the same basic
structure of everything being driven by callbacks, with numerous cases
where we call the next callb
11 matches
Mail list logo
