Re: [f-cpu] French meeting (in Paris) in english, resumé

[Yann Guidon <whygee@f-cpu.org>]

hi !

At last some techie speaking !!!

Nicolas wrote:
> So i made one more mistake, only whygee have receive my answer.
and you made yet another mistake, you answered to yahoogroups :-P

> So i have learn about the pipeline of the pentuim III et 4. So the logic
> between each flipflop (the time barrer) need 0.6 ns for the PIII and 0.3
> ns for the P4 (pipeline depth *2) but the flipflip need 0.3 ns to be
> crossed !
so what ? it's rather balanced.
however, on FPGAs, for the same amount of logic, the FF take less "time"
in proportions.

> So longer pipeline with less job to do (out of order execution, register
> renaming,...) is a none sense !
there's a thing that you forget :
 CLOCK SPEED.
people want "faster" CPUs, we give them.
OK, that's for the justification, everybody knows it.

going to less time between FF will be silly for one reason :
the whole chip will be filled with FF and the amount of "work"
vs amount of FF (which do nothing) will be crazy.

However, you can remark that i designed FC0 with almost the same
characteristics as the 2x parts of the P4 :-) so you see that
there are not many ways to do things.

> I have discuss with an old Bull designer from the golden age (70's,
> 80's). He was in the CAO departement. In 1984, they could extract HDL
> (there own) from masks and, in 1988, they use equivalence checking
> between mask and HDL. Crazy, no ?

When i listened to some EDA engineers, it sounded extremely difficult.
however, i think that there are some tools in ALLIANCE that do that
(HITAS or YAGGLE ?). The people who designed it have funded their own
little company.

> Bull have put to the retirement a lot of very good designer.
some are now found at META ;-)

> Most of
> them was disgusted of that. A lot of technology was trashed. So some
> guys decided to create an association, the FEB.
> http://perso.club-internet.fr/febcm/febhist.htm
> It's mostly in french but some article are in english. I think that
> maybe some of them could help us.
that's a really good news !

> He give quickly two main idea. In 1975(!), it give a patent for a queue
> processor ! Good answer to the stack processor where it's impossible to
> make it multi-way. Some thing to think about.
> 
> Next it's about what to do if i want to create a new leading edge
> processors. It's main idea is to produice binary to be translated, like
> for transmeta but in hardware. The L1 instruction cache contain the
> translated code.

P6 core does almost the same, except that the code is translated
somewhere else. P4 core does almost that, now. Maybe they had to wait
because they didn't want to buy the patent ? :-)

> Why ? Because the underlying core don't need any compatibility stuff,
> could be as unprogramable by common user as we want. And the programmer
> could try to describ what you want to do and then the core (and the
> following one) accelerate to the best. For example, prefetch is used to
> optimise cache. In this processor, you just said, i will use this block
> in a few moment. So depending of the cache size, the translater could
> behave to the best.

there's always a drawback with translation : you compromise peak performance
and predictibility, to the advantage of the average performance.

i don't know if you've programmed enough x86 asm, but when you want
to get the most of the CPU, you're forced to follow an increasing
number of strict coding rules. When the CPU changes, the rules vary
and in the case of the P4, it's even completely different ! This
means that your super-optimised code runs more slowly on newer CPUs.

For example, i had programmed a code which ran faster on a Pentium 200 MMX
than on a PII-266, simply because the pairing rules differ !

If you're going to make a CPU and a family thereof, take that into account.
Intel is not a good example.

> The actual fc0 could be the first "inside core".
if you can't make an efficient translator in SW,
it's not worth it to make it into HW. Show me a good
translator algorithm before you go on ;-P

> But for the US speaker, the next generation will be VLIW, SMT
> (simultaneous multi thread) and SMP (symetrical multi processor),
> because actual hardware became much too complexe (register renaming,
> multiway, out of order execution and reordering, interrupt management).
no kidding ;-)

> So the compiler will have much of the hardwork in static, but with a
> total incompatibility between generation(because of the size of the slot
> and the type of units per slot).
how did you discover that ? :-)

> Lots of works for the fcpu ;p
more than you think, but you have to learn to listen to your instincts.

my experience and instinct says : we have to define CLEAR, SIMPLE and DURABLE
coding rules, that avoid all the problems we face now.

> nicO
> 
> Yann Guidon a écrit :
> >
> > merde ! j'y ai pas allé !
> >
> > i just woke up and discovered that i missed the event :-(
> >
> > nicolas.boulay@ifrance.com wrote:
> > >  May 29th, Professor Vojin Oklobdzija will give two lectures
> > > respectively on "Modern Microprocessor Architectures:
> > > Evolution of RISC into Super Scalar" and "Timing
> > > Elements and Timing issues in High Performance
> > > Processors". This Event is sponsored by CAS
> > > Distinguished Lecturer Program and by IEEE French
> > > Section and will take place in ISEP, 28 rue Notre
> > > Dame-Des-Champs, Paris 6?me at 2:0 pm. The conference
> > > will be followed by a CAS meeting.


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