By: dmcq (dmcq.delete@this.fano.co.uk), April 12, 2021 1:44 pm
Room: Moderated Discussions
Anon (no.delete@this.spam.com) on April 12, 2021 1:54 am wrote:
> Etienne Lorrain (etienne_lorrain.delete@this.yahoo.fr) on April 12, 2021 12:56 am wrote:
> > Example of a transactional block which will always fail, whatever the processor
> > do: hardware breakpoint (read or write) hit on one of the variable accessed.
>
> Really, I don't see the point here, so what?
> 1) Will fail, until de breakpoint is removed;
> 2) Breakpoints may be disallowed or disabled, or postponed inside a transaction, division-by-zero case;
> 3) Transaction state may be preserved, even if retried, the CPU
> may skip the breakpoint after firing it for the first time.
>
> I see an attempt search for totally irrelevant corner cases.
Or in the POWER implementation it would enter a transaction suspended state. There's very little that can't be done if one just applies a little thought. Solving a problem well however can require quite a bit of hard work and cleveness.
> Etienne Lorrain (etienne_lorrain.delete@this.yahoo.fr) on April 12, 2021 12:56 am wrote:
> > Example of a transactional block which will always fail, whatever the processor
> > do: hardware breakpoint (read or write) hit on one of the variable accessed.
>
> Really, I don't see the point here, so what?
> 1) Will fail, until de breakpoint is removed;
> 2) Breakpoints may be disallowed or disabled, or postponed inside a transaction, division-by-zero case;
> 3) Transaction state may be preserved, even if retried, the CPU
> may skip the breakpoint after firing it for the first time.
>
> I see an attempt search for totally irrelevant corner cases.
Or in the POWER implementation it would enter a transaction suspended state. There's very little that can't be done if one just applies a little thought. Solving a problem well however can require quite a bit of hard work and cleveness.