[Libre-soc-dev] Wishbone and House Contract Of Sale Proposition
Jacob Lifshay
programmerjake at gmail.com
Thu Oct 28 19:37:47 BST 2021
On Thu, Oct 28, 2021, 11:23 Richard Wilbur <richard.wilbur at gmail.com> wrote:
> On Thu, Oct 28, 2021 at 11:40 AM lkcl <luke.leighton at gmail.com> wrote:
> >
> > On Thu, Oct 28, 2021 at 6:39 PM Richard Wilbur <richard.wilbur at gmail.com>
> wrote:
> > > Why must we "drop the queue starting from this requester, and any
> > > later requesters" instead of just dropping the cancelled request and
> > > leaving the remainder of the queue intact?
> >
> > this is a hard requirement stemming from speculative execution
>
> How does that follow? Is there a reference on speculative execution
> that I could read to help me see the connection? Seems like
> speculative execution could be more trouble than it's worth. It
> certainly doesn't save energy to compute results and throw them away
> instead of putting computational units into low-power mode. If we
> guess right, it can save time--I see that much.
>
Why it's beneficial is that speculative execution allows you to save tons
of time (by a factor of 3 or 4 on average for some programs), by predicting
which way a branch will go (a lot of branches can be predicted near 100%
correctly) and executing all the instructions either at the branch target
or right after the branch, if speculation wasn't supported, every branch
would stall the cpu until it could calculate which way the branch actually
went and then start fetching instructions from the right target,
potentially wasting dozens of cycles.
That said, I think speculative execution should be limited to only inside a
cpu core with its associated caches, we *should not* attempt full chip
speculation, especially because handling speculation across multiple cpu
cores is a hard problem and very likely to have spectre-style bugs...just
think how easy it is to leak info if one core's speculative execution
causes another core to go slower/faster, as well as what happens if one
core speculatively writes to shared memory, and another core can see that,
and intentionally leak it through a spectre-style vulnerability, before
it's canceled.
Jacob
More information about the Libre-soc-dev
mailing list