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

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/