2015-03-29 6:26 GMT+02:00
<whygee@xxxxxxxxx>:
...
Le 2015-03-28 19:05, Nikolay Dimitrov a ÃcritÂ:
Hi Yann,
Even if you implement such CPU, it would be incredibly expensive and in
most of the use cases the users won't use most of its features. Talk
about inefficiency.
Today all high-performance designs have either a co-processor or
special application accelerator (usually an IP-core attached to one of
the buses). For your case, you can design an arbitrary precision BCD
accelerator. This will both allow you to calculate faster, and leave
the CPU design... well, generic :D.
You raise the question of coprocessors and it's a very important matter
that also influences my new "vision" of the F-CPU evolution.
More and more designs couple a CPU with coprocessors (more or less generic ones)
and GPGPU is spreading all over the map.
Be carefull, since 10 years, i add works on TI omap 3. Coprocessor use
have many stupid drawback. Embeded code for some cryptographique
function use coprocessor when the paquet are big, and the cpu when the
paquet are too small. When you use coprocessor, you loose a lot of time
in communication and register setting. Beside that, there is always a
missing mode or feature, so cpu must then be used. I think that a kind
of specialised (one cycle) instructions are prefered, even with it's own "power
domain".
Â
F-CPU was meant for "high performance" and number crunching,
but this is and should now be relegated to the array of generic
coprocessors. This leaves the real "application" to the F-CPU,
this is how and why I aim at a leaner FC0.
Use of shaders for
HPC is also decreasing. It's always harder to make code fast on shader
compare to a cpu. Latest Xeon core have 20 cores and 256 bits SIMD.
That's almost the same speed than big GPU. The flexibility of CPU
programmation make the writing of fast code even simplier.