Re: [f-cpu] another DATE report

[nico <nicolas@seul.org>]

hi,
I'm back from vacation !


Yann Guidon a écrit :
> 
> hi !
> 
> nico wrote:
<...>
> > Nop, absolutely necessary to handel very easly synchronous problem.
> > Christophe convince me, if he could resend it's URl about the paper that
> > speak about.
> > Such technic, in the common case, where there is no collision the only
> > lose is this CAS2 instruction, there is no OS call overhead, no task
> > switch, nothing. Only 4 atomic transactions ! We must have that !
> 
> i agree that CAS-like operations are interesting, no doubt about that.
> However, what you propose is uglier than what i heard before, and
> you know that we have discussed a lot ;-)
> 
> * first, there must be an instruction that supports this kind of
> transaction. there is none and this instrruction would block the pipeline.
> you couldn't for example "pipeline" the CASes.
>

That's not a problem !  Most of the other technique are much more costly
(call to the os, trap,...)

 
> * second, probably no device would support this operation. I don't know
> how you would like to implement that but F-CPU is not alone in the system
> (otherwise there would be no use for an I/O bus :-D) and the other elements
> must support the same protocol. If there is only one memory block, ok,
> but if other CPUs of a different sort are present, there might be risks.
>


If the arbitrer of the bus does it's not a problem any more ! It's it
that grant the devices.
 
> * third, and more difficult for me (because i'm one of the people who code),
> your feature requires a more complex state machine than needed. Generally
> such a complex thing is not used 99.95% of the time, so i think it's an
> overhead on my shoulders, unless you want to do it.
>

?? it's only a 4 straits state machine, you're scheduler will be much
more paintfull !
 
> > > > - maybe things to manage cache L2 (from my point of view L2 is tied to
> > > > the DRAM controller, the L1 is tied to the CPU). None caching access for
> > > > example to avoid cache trashing.
> > > what do you mean by "things to manage cache L2" ? what things ?
> >
> > For example, caching or no caching data (imagine the FCPu as the core of
> > the Geoforce 8, rendered image didn't need to be cached).
> there's a flag in the Load and Store instructions which specify if the
> data is to be cached.
>

Grrr! I speak about the bus that connect device internally. I know there
is such flag. But there is no interreset if ouer internal bus does
handel it to informe the DRAM controler.
 
> > To extend that, i would try to apply distributed memory in some control logic to
> > make invalidate some cache line...
> 
> if we work with private and public memory spaces, there is no invalidation
> logic required.
> 

????? I think you miss completly one thing. Invalidate is one of 4
technics but none of one of them are superior to the other it depend
much on the application.

> > > see you soon,
> > Yep ! I leave Paris for 1 weeks. Don't blow my mail box !
> send me a postcard ;-)
> 
> if you go in vacations, take some time to write a white paper about how to
> use Wishbone in the most simple case (1 CPU + 1 memory). I'll try to make
> that for the VCI interface. Some VHDL code would be nice, too.
>

Too late!
nicO
 
> > nicO
> > > > nicO
> > > WHYGEE
> 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/