Apollo Team has new Cyclone 5 FPGA accellerator cards

[Megol]

Originally Posted by meynaf

So once MOVEM.L is done, doing MOVEM.W is peanuts ? (As the special format is what's tough here, when you have it, you can reuse it, right ?)

Yes it is easy. The only complication is the sign extension but that is required elsewhere.

But many instructions are in this case. They require a special handling that's not reused elsewhere, e.g. DIV is in this case.
Others like LINK need to use several µops.

DIV doesn't touch any critical part of the pipeline so that isn't a problem. In my design it was actually handled a lot like a load missing the cache, this means there is no extra hardware needed for the variable latency operation and starting the execution would be a "store-data" operation in the integer unit.

I never started implementing LINK.

Of course if the problem comes from the total number of subops you have (i.e. the total for all instructions), i can understand it becomes a big problem.

If one have proper microcode support MOVEP isn't hard to execute without extra hardware but it would be slow. Unlike x86 the 68k doesn't really need full microcode support and adding it complicates a critical part - the decoder.

MOVEM needs to be reasonably fast, while MOVEP does not. Isn't it easier when it can be slow ?
Basically it's just a bunch of shift + move.b, and these already exist in the cpu. It's not like if we want it to run in 1 clock.

IIRC the byte store/load starts with the MSB so one either have to do a BSWAP (x86 instruction - translates between little endian and big endian formats) or a rotate to place the data in the right position.
Or one could extend the ld/st unit to support byte operations targeting the MSB of a register. Even further the ld/st unit could be extended to support loading/storing an arbitrary byte of a register.

In a speed demon design changing the ld/st unit could lead to lower clock frequency as it touches a time critical part of the pipeline.
If the same design then doesn't have proper microcode support then it is very hard to execute MOVEP at all. Not because it is really hard per se but because it is a very bad fit for the design.

[meynaf]

Originally Posted by Megol

Yes it is easy. The only complication is the sign extension but that is required elsewhere.

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)

Originally Posted by Megol

DIV doesn't touch any critical part of the pipeline so that isn't a problem. In my design it was actually handled a lot like a load missing the cache, this means there is no extra hardware needed for the variable latency operation and starting the execution would be a "store-data" operation in the integer unit.

If DIV is no big deal, would an integer SQR be a problem ?

Originally Posted by Megol

I never started implementing LINK.

Too bad. Why did you stop doing your 68k implementation, btw ?

Originally Posted by Megol

If one have proper microcode support MOVEP isn't hard to execute without extra hardware but it would be slow. Unlike x86 the 68k doesn't really need full microcode support and adding it complicates a critical part - the decoder.

Other 68k instructions need microcode as well. Oh, wait. They're the 020+ insns everyone removes too

[matthey]

Originally Posted by meynaf

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

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.

[meynaf]

Originally Posted by matthey

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

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

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

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

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

[Megol]

Originally Posted by meynaf

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)

Didn't Coldfire remove many word sized operations?

If DIV is no big deal, would an integer SQR be a problem ?

Not really. It was a looong time since I've touched something like that but a Newton-Rapson started by a table lookup should IIRC be enough. It requires resources that may be better spent though.

Too bad. Why did you stop doing your 68k implementation, btw ?

Many reasons. It wasn't a good fit to support a full 68k instruction set, while it could support (this was never implemented) virtual memory it wouldn't be compatible with existing software. It was designed for a certain family of FPGA without any thought on portability, while fast clock wise some relatively common code patterns would be slow (somewhat like the Pentium 4). This and other things meant I simply lost interest in it.

If I'll ever restart the design it would probably be translated to a VLIW type design with code morphing in Transmeta style.

Other 68k instructions need microcode as well. Oh, wait. They're the 020+ insns everyone removes too

[meynaf]

Originally Posted by Megol

Didn't Coldfire remove many word sized operations?

They removed so many things...