[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [f-cpu] Status quo



Le 2015-04-01 13:00, Nikolay Dimitrov a ÃcritÂ:
Hi Yann,
Hi !

Well, I personally don't like the idea of having such CPU
instructions in the first place,
Why ?

Because I feel this is a process of centralizing functionality in the
CPU itself. My "gut-feeling" is that the more scalable approach is to
have multiple CPU cores with simple ISA (which can tolerate higher clock speeds), and also other computational blocks attached on the system bus.

I think that the CPU cores should handle the normal instruction streams,
where accelerator blocks should handle data streams (losless
compression, encryption, audio/video decoding, etc).

But here, the requested functionality is not an "accelerator",
which would take several cycles for example.

The F-CPU does not have a so-called "system bus", it speaks directly
to whatever it needs to speak to, because latency kills.

You describe an ideal system with a fixed, well-defined function
while F-CPU is a RISC, general-purpose processor. One feature
can be added if it does not make the whole rest slower, even a bit.
Otherwise, the slower clock must be justified by a speedup all over
the whole application spectrum (that's why we have SPEC)


OTOH, a LUT instruction is feasible. some address bits may be used to
select one thread's contents and it would be useful for many many
applications (gamma conversions, crypto, hash...) unlike reordering
address bits which is useful only for one specific use.

This looks like a neat idea!

one of the aspects of RISC is to factor the functionalities.

but the very first implementation will be very scaled down...
We're creating a catalog of features that will never be
completely implement and/or use. the key here is the application.

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