[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Yann Guidon a écrit :
> 
> hi !
> 
> nicO wrote:
> >
> > >FC0 issues in-order all the instructions that are considered as valid.
> > >if a trap occurs, it must NEVER enter the pipeline (because of the OOO
> > >completion, it would become a nightmare to rewind the pipeline !!!).
> >
> > !!! "rewind the pipeline !" You just have to bypass the write back stage !
> 
> i told you i was really lazy :-)
> 
> > >Currently, FC0 uses two addressing spaces : "private" space where the CPU
> > >is the only master (cache coherency is straight-forward) and "outside world"
> > >where all the accesses are in-order and uncacheable.
> >
> > I don't think it will be very interresting (too slow). It will be much
> > interresting to manage this inside the VM unit by page (the page will
> > have the information of none caching, none registering,...). And then a
> > decoder will send the data thought memory port or fbus port.
> 
> there will be something like that.
> however i have to solve a bunch of problems concerning the
> "execution pipeline" first.
> 
> > >Use semaphores that are mapped in the SRs !
> > In all case, we need to write something in memory or to touch something
> > in the VM unit.
> why ? a semaphore is a semaphore, a flag if you want.
> whether it is implemented in memory or with a dedicated HW in
> a different addressign space, is "implementation dependent".
> 

In all case, you have one memory access + 1 or more port to the outside.
Plus, you could add many problem for multicpu system. So there isn't any
port dedicated to it, and shouldn't have ! Because it so tight to the
OS, that we could have many compatibility problem in the futur. I think
you thought to an implementation of SGI not really usual processor.
Today's µp implement semaphore with atomic read_modify_write
instructions.

> > So it's just pushing the problem away !
> and if possible where it doesn't disturb us :-P
> 
> the L/S unit is optimised to allow high bandwidth through
> cache-line width packet transfers, accessing single bytes
> in scattered order is a good way to "kill" your memory subsystem
> and the speed of your synchronisation.
> 

You could add specific memory barrer (semaphore aren't so common!).

> > More generaly, i find the text very agressive against Alpha.(the 2 first
> > sentences of the text, for example). We should never forget that alpha
> > work since 10 years and fcpu is in it's very beginning. So this kink of
> > speech could make laught a futur investor in the fcpu, never forget
> > that.
> 
> i think that you know that i am not "agressive" and that i respect the
> ALPHA. I have two expensive books about it and unfortunately no
> Alpha server at home.
> 
> We can still discuss whether Alpha is dead or not. CPQ will keep
> Alpha alive artificially as long as IA64 is not a serious competitor.
> that is enough for me : it's just marketing and financial manipulation,
> the ALPHA engineers have a very reduced freedom of decision now,
> because they know that it will be dropped after the 364.
> 
> So i could say : Alpha is dead as much as F-CPU is alive.
> it's time to learn alpha's lessons, i think.
> 

the problem is the tone not the content.

nicO

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