Rep:Re: Re: ll/sc (was Re: Re: Re: [f-cpu] F-CPU project and Debian)

["Nicolas Boulay" <nicolas.boulay@ifrance.com>]

From an old speach, i remember that ll/sc couldn't be used for multi-cpu
computer. Or it work if the teste are maid at the memory interface and
not inside the cpu ?

It should be great to think about the problem of having 2 memory bank on
2 differents cpus, so you could have the same virtual page on 2 separate
physical page. You could manage such thing with managing the write right
and a kind of lock but what about ll/sc ?

nicO
(from my point of view, the cpu should always be seen to adress a single
flat adresse space that ease so much things !)

-----Message d'origine-----
De: Cedric BAIL <cedric.bail@free.fr>
A: f-cpu@seul.org
Date: 10/10/02
Objet: Re: Re: ll/sc (was Re: Re: Re: [f-cpu] F-CPU project and Debian)

> >Did we need to add a bit in the TLB entry to manage right on page
> >for this unit ?
> if a new addressing space is created, there is no need to
> care about the TLB entries...

Hum, we have a problem here ! Cristophe mean yes and you say no. From
what
Cristophe say I think it's the best idea to put some info in the TLB.
 
> > I mean the VM must be able to create a page only
> >for ll/sc to prevent normal load/store on it.

> a different "address space" is necessary because
> if a local CPU can prevent L/S, nothing prevents
> another CPU from not doing it...

But all the other CPU will have the same TLB entry, because they run the
same OS ! So that's not the problem. In fact the problem is that we must
prevent the user code from accessing to super user data and read/modify
it
without authorisation => we absolutly need a mechanism like the TLB !

> if the stream number is lost (through IRQ or a context switch)
> then the "best" thing is to default to stream 0.

oki 

> >  I will look to the one that reduce gperf colision and I think that
we
> >must specify this one.
 
> ARAARRRRGGGGHLHLLHH...... "gperf collision"....
> forget about this and think more in terms of simplicity,
> rather than parsing speed.... gperf is not the only tool
> on Earth...

Yes, but if we create a hash table for all our asm instructions we must
be aware about collision problem (actually we have around 200
collisions,
compared to a x86 with fpu, sse, mmx, 3dnow it's really a lot because it
only
have 6 collisions !) and in fact it's only a little test, run gperf on 
f-cpu.perf and have the result ! Finally it didn't cost anything to us
to 
test that before adding a new instruction/form to the manual, so why not

testing it ?

In fact the solution from michael didn't change anything in collision
and
it's clear so I will specify it.

A+
  Cedric
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/
______________________________________________________________________
Etudiant: Wanadoo t'offre le Pack eXtense Haut Débit soit 150,92 euros
d'économies ! Clique ici : http://www.ifrance.com/_reloc/mail.etudiant 


______________________________________________________________________
Exclusif: 75 euros remboursés sur le pack eXtense Haut Débit de Wanadoo ! 
Cliquez ici : http://www.ifrance.com/_reloc/mail.exclusif 

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