View Single Post
Old 23 August 2015, 09:18   #244
68k wisdom
meynaf's Avatar
Join Date: Nov 2007
Location: Lyon (France)
Age: 43
Posts: 1,935
Originally Posted by matthey View Post
MOVEM.B is not particularly difficult to implement but has other potential issues.

1) Is there a logical encoding for it and is the encoding space taken worth the space used?
There is an encoding for it, whether it's logical or not is another story, but the space isn't lacking. It's not big either, so for me it's certainly worth - but guess what, i'm pretty sure Gunnar has stolen my encoding space here

Note : my question was about how hard it was to do, i didn't want to discuss the usefulness.

Originally Posted by matthey View Post
2) Is it consistent with the 68k? No other instructions allow sign extending a byte to a longword for addresses register destinations. Only allowing data register destinations for MOVEM.B really limits its value.
Of course I would allow MOVEA.B as well, and every byte An operation that has a natural encoding. Why allowing .W and .L but not .B ? Seems more orthogonal to me to allow all three.
Note : it would be zero-extended, not sign-extended (more useful on bytes).

Originally Posted by matthey View Post
3) Would it be used enough to be worth implementing (cost benefit analysis)? Can compilers make good use of it? Does it save cycle or improve code density in practice?
Unsure it would save cycles but it would improve code density (consider the rgb example : 3x moveq #0 + 3x move.b -> single movem.b).
Can compilers make good use for actual MOVEM.W ? You can study this, and thus you've got your answer for MOVEM.B as well (and you probably know that i don't care much about compilers).

Originally Posted by matthey View Post
4) Are there as many resources available for byte to longword extending as word to longword (less resources generally equates to less optimization possibilities)? The EA units allow only word to longword sign extension and allowing byte to longword extending in the EA may increase the mux size and slow the EA calculation.
EA calculation isn't the bottleneck, and the main problem of EA is certainly the 020+ new modes.
Anyway if the alu can write An registers because they support more operations, then you have another place where to put that, and MVZ already provides the necessary operation.

Originally Posted by matthey View Post
I doubt it would be a problem for most designs but wouldn't this introduce fixed point integers which aren't used anywhere else in the 68k? The range of fixed point integers is more limited than fp where the decimal point can float. These types of instructions generally take a lot of logic also. I can't say I've needed an integer square root very often either.
Not fixed-point integers, no, but pure integer, like DIV.L (note that you can do your own fixpoint with that).
I don't like fp for sqr. Does it give an exact result, or a rounded one ? My need is an exact result, i.e. the largest a such as a*a<=b. The range is better than with fp - src of full 64 bits and dst of 32.
Btw If sqr is implemented as power of 1/2 then the precision is catastrophic.

You need sqr any time you compute a distance. This can occur very often in a game AI, for example.

Note : again, it was about how hard it would be to do, not to discuss the usefulness. I can do it, but if you really want to, it's time for a new thread (or a new PM) - as we're getting a little bit OT here
meynaf is offline  
Page generated in 0.05891 seconds with 9 queries