dmcq (dmcq.delete@this.fano.co.uk) on September 29, 2021 7:53 am wrote:
> rwessel (rwessel.delete@this.yahoo.com) on September 29, 2021 6:55 am wrote:
> > NoSpammer (no.delete@this.spam.com) on September 29, 2021 3:53 am wrote:
> > > dmcq (dmcq.delete@this.fano.co.uk) on September 28, 2021 2:21 pm wrote:
> > > > The bits could vary between implementations so letting designers optimise better. More conditions
> > > > could be saved. The only problem I can see is big-little systems and they could just zero the bits
> > > > if moving between different cores - with the current system how can we tell if the form optimised
> > > > by one is okay for the other? And yes it seems like an unnecessary waste of opcodes and code space.
> > >
> > > I think 3 instructions make very simple implementations possible for the low-end. Per example:
> > > Initial instruction is movsb until aligned or end.
> > > Middle instruction is movs[your core's biggest R/W chunk]
> > > End instruction is movsb until end.
> > >
> > > Why have more state when the state can already be in the registers and PC?
> >
> >
> > Remember that in the general case, you can't get both operands aligned, so you can't avoid
> > dealing with at least some of that in the "middle" instruction. But the point is, how
> > hard could it be to detect the case where the initial or final instruction apply?
>
> And thinking yet again about it why bother even saving any bits? AT most it can get by with some bits that are
> passed between the micro-ops. If an interrupt happs one can just dump the bits and start anew from where stopped.
> I'm basically saying just have one op and if they want three have the one op split into three. Then there's no
> need to start wondering about describng what the state is like when restarting the second operation.


So update registers with intermediate state like 8x86 movs or S/370 mvcl? ;-)