View Single Post
Old 23 August 2015, 03:43   #243
Registered User
Join Date: Jan 2010
Location: Kansas
Posts: 873
Originally Posted by meynaf View Post
So Gunnar's excuses for rejecting my MOVEM.B idea were invalid
(and the removal of MOVEM.W in the coldfire doesn't look very smart either)
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?
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.
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?
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.

Originally Posted by meynaf View Post
If DIV is no big deal, would an integer SQR be a problem ?
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.
matthey is offline  
Page generated in 0.05909 seconds with 9 queries