[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [f-cpu] another DATE report
just a quick, incomplete answer.
More answers later, if i find more time
(i'm currently trying to make YGASM more useful).
> Well, it's true i'm shy in english :-)
obviously not ;-)
> More seriously, I think the issue about the time penality about using CAS and
> CAS2 is overstated. The solution offered by Yann to replace it with a fix array
> of semaphores through the SR mechanisms is an evidence that either he don't
> know about what we are really talking or he misunderstands the real purposes of
> CAS2. Yann, let me tell you that your solution is really clumsy (I will explain why).
So maybe your problem was not clearly stated in the beginning.
My position is simple : separate the different kinds of problems to
solve them all in the most simple, suitable and efficient way.
This is not something Descartes will disagree with.
I see nicO's position ("everything is memory mapped") as the contrary
because it makes the memory system so much complex by mixing all problems
together. In the end, the problem is not solved and the memory system
is too complex to be implemented.
The SR were designed to separate the configuration registers (which have
very important side effects on security, scheduling and memory coherency,
but which are not accessed often, so the bandwidth is not a problem) from
the general streams (data and instructions, which eat up 100% of the bandwidth).
The LSU, fetcher and the remaining of the FC0 memory system
are designed to handle 256 bit words as a base granularity.
Putting either configuration registers or synch primitives
(which are 32-bit or 64-bits) in the memory range is a waste of
bandwidth (it takes an average of 4 cycles in the optimistic scenario
to load or store a whole line and using only one word means that
there are at least 3 lost cycles). Modifying the LSU to handle
smaller lines is also a bad "solution" because it makes the design
more complex and the feature is not going to be used often.
As far as i can imagine, CAS and CAS2 were designed on _exsting_ computers,
with the limitations of the existing platforms. Now we are designing
a new platform and we can find better solutions to the problems.
Not a better implementation of the previous solution, but a rewording
of the initial question. All i read in the current thread is :
"let's make a CPU like what already exists" and this is not going
to help make better computers.
> Personnaly, I think that you are too more confident about yourself -
It is not about confidence. You, nicO or any other people
who has once posted in a F-CPU thread was confident enough to
speak in this list. It's about opinions and if i was
not confident in my own opinions, i wouldn't speak or write about it.
This list is also a medium that works by convincing people, by finding
good reasons but not forcing people. Everybody here is free to think
what he wants. I respect your opinions and i have the right to have my own.
My only work as one of the maintainers of this list is to receive
error messages and help people to subscribe and unsubscribe, it is
not a moderated list and i encourage the technical discussions, even
when no agreement is found. If somebody want to manage this list
in my place, no problem (my mailbox will get less messages).
If you have a magic solution, then speak about it. Not only the theory,
but also the implementation and this has to fit in the existing framework.
You have to find the way to integrate your idea in what others have done
during the last 3 years.
> especially since you states everytime that you are the only one who code.
I am not the only one : Mathias Brossard, Michael Riepe, Cedric Bail
and Etienne Labarre have also contributed with code, or are contributing.
I am just pointing out that some people prefer to speak rather than
implement. Implementation is better because it's a tangible proof.
I also tease you because _i_want_you_to_code_, too. nicO, you and
all the other lurkers (80 ?) in this list. I am not going to
make everything myself, otherwise it would not be F-CPU bu YGCPU.
> Please, stop with that !!! you shouldn't speak that way simply because you
> don't want to hear about something you regard as a crap. You will exasperate
> too many people with such a behavior.
I don't say that what you think or propose is crap. I say that it is not
adapted to the existing framework/architecture. I am really sorry if you are
exasperated and it is not my intention, far from it. However, if your method
is as good as you say, you will certainly find a way to convince me with
a solution or a compromise, and some code to backup your affirmations.
Otherwise, this thread will last forever and make everybody angry :-(
This thread seriously lacks sense of humor, too ...
read you soon,
To unsubscribe, send an e-mail to firstname.lastname@example.org with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/