Re: [f-cpu] back to VHDL

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

hi,

Michael Riepe wrote:
> 
> On Sun, Feb 10, 2002 at 02:17:50AM +0100, Yann Guidon wrote:
> [...]
> > I have one question however : Can we "link" the SHL unit to the
> > LSU ? This would allow us to perform both endian and alignment
> > with few overhead and some flexibility : it would even allow
> > us to do "signed" loads, where the data is first aligned and
> > then sign-extended... This is often used for CPUs like ALPHA
> > and MIPS where data are handled only in a word-sized way.
> 
> That's not very RISCy, isn't it?

it is, depending on what you want to do.
All i was thinking was : to not duplicate functionalities.
The LSU provides / takes a "word" (64 bit now) and we can reuse
the shifter to :
 - sign extend
 - align
 - bit-reverse
the word during load or store.

by "align", i mean : we get a N-bit word from memory
but when we request a smaller chunk (a byte, for example),
it needs to be "aligned" so the requested data appears
on the LSB, whether or not the address is aligned on N bits.

I have no intention to provide "unaligned" access
(when a word of 2^N bits has a pointer with the N LSB not cleared)
because what would happen if the word crosses a page boundary ?...

> We should duplicate the byterev part and add it to the LSU (for
> loade/storee), but the rest is IMHO overkill.
if byterev is already done in one unit, we could spare the duplication...

> In general, data should be properly aligned. Applications that violate
> this rule are supposed to do their bit fiddling on their own.
of course, but what happens if we request one byte, half-word or word
from a 64-bit word ? this is where the SHL can help. Maybe i was not
specific enough...

> Sign-extension (that is, the `widen' instruction) is currently not handled
> by the SHL unit (sign-extended right shifts are, but that's a totally
> different operation). We can implement it in the SHL, the LSU, or both.
> Or in another, separate unit.
sign-extension of loaded words is not a priority because
the CPU can handle most operand sizes. Usually, load+sext
("signed load") is required when only one data size is allowed
in the CPU (such as in MIPS and ALPHA). let's keep that as an option
for a future enhancement but first, we have to get the LSU right,
and if possible not duplicate units (it's already large enough ;-D)

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/