anon2 (anon.delete@this.anon.com) on August 18, 2020 7:04 pm wrote:
> Maynard Handley (name99.delete@this.name99.org) on August 18, 2020 3:42 pm wrote:
> > dmcq (dmcq.delete@this.fano.co.uk) on August 18, 2020 1:00 pm wrote:
> > > hobold (hobold.delete@this.vectorizer.org) on August 18, 2020 11:58 am wrote:
> > > > Michael S (already5chosen.delete@this.yahoo.com) on August 18, 2020 4:48 am wrote:
> > > > [...]
> > > > > BTW, Power ISA™ Version 3.1 manual is here https://ibm.ent.box.com/s/hhjfw0x0lrbtyzmiaffnbxh2fuo0fog0
> > > > >
> > > >
> > > > Thanks for the link!
> > > >
> > > > Looks like they are really serious about autovectorization. Quite a few SIMD
> > > > bits to round out functionality, and more interoperation between scalar and
> > > > SIMD. They even have "vector centrifuge" now ... that is ... interesting.
> > >
> > > Gah! You can't split a prefixed instruction over a 64 byte boundary.
> > > I wonder why they felt it necessary to impose that.
> >
> > For precisely the reasons I discussed!
> > If you have that restriction, then (along with other things being
> > easier) an instruction is never split across two cache lines.
> > Which means pre-decode can mark instructions as pairs.
> > Which means that, yes, it IS possible to track a branch into the middle of a pair
> > of instructions and behave appropriately (which, IMHO, should be to fault).
> >
>
> Exactly as I said here https://www.realworldtech.com/forum/?threadid=194561&curpostid=194635
> (if that is indeed the reason for it -- predecode does seem likely).
>
> Interesting how quickly the x86 fan club are to insist none of the failings of x86 are
> actually failings at all, clearly without having thought through even the very basics.

Yes, I think we are on the same page about this -- the pitfalls that are possible, and the extent to which both the architectural design (eg the 64-byte restriction) and the implementation (at the very least, pre-decode) prevent those pitfalls from being instantiated.