rwessel (rwessel.delete@this.yahoo.com) on September 29, 2021 1:58 pm wrote:
> dmcq (dmcq.delete@this.fano.co.uk) on September 29, 2021 1:44 pm wrote:
> > rwessel (rwessel.delete@this.yahoo.com) on September 29, 2021 11:35 am wrote:
> > > 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? ;-)
> >
> > Well that does seem an obvious way to handle interrupts. But it could execute as if it was a number of
> > operations with some extra state being passed between the stages, except the extra information can be
> > discarded if an interrupt happens. So the first operation would set up a couple of microoperations. Then
> > more would be generated dependent on each other till the count went to zero. An interrupt would just stop
> > it after one of the operations had finished and updated the registers showing how much had been done.
> > You want it to work okay in a longer pipeline so operations after the move can be done in parallel.
>
> Sure, so long as the CPU was executing the move, externally visible state doesn't need to
> be updated. But so long as it's architected (like x86 movs), there's no problem moving between
> cores that might maintain some sort state internally while running a multi-word move.

It's bit of a pity though if the actual end state is guaranteed like for x86 or mvcl. It means one can't implement memmove because sometimes one would want to go forwards and other times backwards.