Re: [f-cpu] F-CPU vs ALPHA

[Michael Riepe <michael@stud.uni-hannover.de>]

On Tue, Aug 14, 2001 at 10:43:12AM +0200, Yann Guidon wrote:
> 
> i wrote this stuff tonight.

Some remarks:

[...]
> //  There is no integer divide instruction.
> 
> Michael is (was ?) trying to make a divide unit, i understand his pain.
> but the instruction is defined in the opcode map anyway, even if it must
> be emulated.

I'm still working on it.  The real pain is that the IDU duplicates so
many things that are already present (parts of the INC, SHL and ASU
units are needed for operand normalization and result postprocessing)
but I can't drop them and make the divider core a separate instruction
because it uses too many registers (3r4w).

[...]
> //  The floating operate instructions include four complete sets of VAX and
> //  IEEE arithmetic, plus conversions between float and integer. 
> 
> IEEE only is goinf to be supported, in 32, 40, 64, 80 bit modes.
> 32 and 64 bit versions are preferred of course.

We don't have any registers that can hold 80-bit floating-point
values, and I'd rather add a `tiny float' data type (1+4+11 bits)
for low-precision operations than implement 40-bit FP (which is IMHO
rather useless, and a waste of space).

> //  There is no floating square root instruction.
> 
> We intend to provide "seed" generation for accelerating Newton-Raphson
> computations of divide and SQRT.

In the FC0, we can probably get away with some bit-shuffling (hardwired).
For sqrt(x), divide the exponent by 2 (right shift); for 1/x, invert it.

[...]
> //  Instead, the byte shifting and masking is done in Alpha with normal 64-bit
> //  register-to-register instructions, crafted to keep the sequences short.
> 
> hmmm, this family of instructions is often very useful anyway !

Indeed... but why limit it to bytes?  The ia64 (aka Itanium) has dedicated
insert/extract instructions that work with arbitrary bit fields.

[...]
> //  If precise arithmetic exceptions are desired, trap barrier instructions can
> //  be explicitly inserted in the program to force traps to be delivered at
> //  specific points. 
> 
> no need for them. But there is a "barrier" instruction that can do that anyway
> (flushes the pipeline, "serialise" the issue, wait until all operations are completed...)

Shouldn't we drop the serialize instruction and make it a special
register?

[...]
> I am still wondering if PALcode is such a good idea.
> We're used for a long time to rewrite the trap handlers for each new computer.
> Maybe this idea came from the VMS transition constraint, but there is
> no need of this stuff in the F-CPU.

We can implement a `PALcall' SR if we have to.

-- 
 Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
 "All I wanna do is have a little fun before I die"
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/