Re: [f-cpu] Re: Floating-Point?

[Yann Guidon <whygee@f-cpu.org>]

hi !

Glenn Alexander wrote:
> Hi. This is my first post to this list.
welcome !

> My background is as a hardware
> technician, not a chip designer so bear with me.
i don't see where the problem is :-)

> On Thursday 16 August 2001 03:41, you wrote:
> > Michael Riepe a écrit :
> >
> > In sparc, there is no 80 bits float but 128 bits (2 registers used in
> > the same time). We don't need 1 cycle multiplication so it could be done
> > for the fcpu.
> 
> I am thinking that taking the two-register approach might be
> over-complicating matters. Since F-CPU is intended to later be scaled above
> 64 bits, if someone wanted 128-bit floats in the future they would impliment
> a 128-bit F-CPU. Especially for the FC-0 and probably for the FC-1, KISS
> (Keep It Simple for us Stupid people).
yup, that's obvious.
but we are still defining a lot of things currently.
In the absence of both an acurate manual and working execution units,
a lot of things are still floating.

> BTW: I am wondering about the reasons for having endian-ness encoded in the
> instruction. How often do you need to change endinianness. I am thinking a SR
> for endinian would free up that bit as well as allowing other endiniannesses
> as well as big and little (Not in popular usage at present but I can think of
> several other bizaar ways to re-arrange the bits in a word that may be useful
> in some obscure application).

see my latest post.

> I'd be inclined to use that bit to extend the addressing size from 4
> addressing widths to eight as follows:
> 000 - 1 bit
> 001 - 2 bits
> 010 - 4 bits
> 011 - 8 bits (mandatory)
> 100 - 16 bits (mandatory)
> 101 - 32 bits (mandatory)
> 110 - 64 bits (mandatory)
> 111 - maxWidth (the maximum avaliable width)
>
> I'm not sure about the merits of the first three widths but they are nice and
> neat.
do you mean that you want bit addressability ?
i'm surprised. I've never needed that, and it makes
the load/store unit much more heavy.

> Since you don't want a bank select line for every bit, sub-byte writes
> would have to be implimented as a read-alter-write, wasting at least one
> memory bus cycle. I make no claims as to whether this is worth it. You would
> also need to address each bit instead of each byte, chopping 3 effective bits
> off your maximum memory size. Crazy idea, I know.

AFAIK byte addressability is enough.
if you want to access individual bytes, you have to use shift/rotate/mask
etc. and perform the read/modify/write with a sequence of instructions.

> An alternative might be:
> 000 - 8 bits (mandatory)
> 001 - 16 bits (mandatory)
> 010 - 32 bits (mandatory)
> 011 - 64 bits (mandatory)
> 100 - 128 bits
> 101 - 256 bits
> 110 - application defined
> 111 - maxWidth (the maximum avaliable width)
> 
> 256-bit floats anyone?

in fact, we provided another system for handling "wide" registers.
There are usually 3 bits used by every operation code,
one is the "SIMD" bit and the 2 others are size bits.
In 64-bit implementations, these 2 bits are "hardwired"
to sizes 
	00 - 8 bits
	01 - 16 bits
	10 - 32 bits
	11 - 64 bits
in "wide" implementations, a set of SRs define the mapping.
when a task is initialised, it is set to the defaults (see above)
to provide compatibility, then the application modifies
the mapping. It is not hardwired but there is a user-configurable LUT.

This way, ANY arbitrary register size can be encoded.
I think that it also answers Jürgen's remark.

> --------------------------------------------------------
> Glenn Alexander - The man with no surname and a silly hat.
i'd like to see that :-)

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/