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

Re: [f-cpu] Status quo



Hi Yann,

On 04/01/2015 01:49 PM, whygee@xxxxxxxxx wrote:
Le 2015-04-01 12:36, 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).

Have you seen the paper "Von Neumann Syndrome"?
(http://www.ce.ewi.tudelft.nl/fileadmin/ce/homepages/galuzzi/File_index/Symposium/06_Hartenstein.pdf)

so didn't intended to put this LUT on the CPU data path at all.
The CPU datapath is where data are treated, modified, etc.


I think it can be implemented like MMU extension module, to handle
the address-conversion only for the tiled pages (for graphics
purposes, if/when needed).
There is no "magic box" called MMU, there's the LSU, the TLBs, some
buffers here and there, cache memory... Adding a LUT "when requested"
in the address path would not just increase the memory latency but
also make it more complex because "certain cycles" will have one
more cycle of latency. It adds a new "visible state" to the CPU
architecture : in a multithreaded, one thread would want one
conversion, another wants a different one, so the thread switch is
ridiculously slow. And you still haven't specified how you'll tell
the LUT to be active or not.

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!

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