Quote:
Originally Posted by meynaf
|
No, problem. Just let me download the file and have a look... Oh, surprise!
(Click to see in full size.)
Quote:
|
Not exactly, no. They just say - and only in the specific manual you linked to - that it's a longword operation. Nowhere they say we should write 'moveq.l' and not 'moveq'.
|
The specific manual I linked to is the same manual you linked to, and that I happen have here in paper, straight from Motorola
And this is what it says:
(Click to see in full size.)
Now, you're throwing in the mix two things I either didn't touch on or say:
*
Technically, moveq is 8->32, not 32 - that's right, but I didn't even remotely touch on that aspect;
*
we should write 'moveq.l' and not 'moveq' - nowhere I said that.
Let's instead look at what actually happened.
In
post #140 you wrote:
As an example, most assemblers will accept moveq.l even though it is technically incorrect (moveq has no size).
With
post #145 I showed that
"moveq has no size" is false, as the official reference manual from Motorola (again, the same you linked to) states that the size of moveq is long; additionally, I showed an example on an instruction that actually has no size (bfextu).
That's all there is to it, and I'm shocked that such a basic matter started such a reaction
Regarding appending ".l" to "moveq": it's redundant, but not technically wrong, because the size attribute of moveq is precisely .l. But that's a totally different story from lsr.l d5: that is just wrong, because Motorola's syntax - and, even more, instruction encoding - demands that a count be specified when the operand is a register.
Who designed the CPU and defined the instruction set with its syntax is the only authority in such matter, and that's Motorola. Alternative syntaxes can and have been be adopted, but they can't have higher authority.