ISA for Speed, Speed, and more Speed
When it come to current architectures certain level parallelism is achieved by pipe lining and executing concurrent instruction pipe lines.
Also programmatically parallelism is achieved by running multiple threads to maximise throughput. But generally speaking even the code execution within a thread is more or less in sequence.
When analysing algorithms there are is some parallelism in the instructions. This parallelism can be exploited by analysing each statement and its dependencies. All possible independent instructions are executed together. E.g.
A = b + c
D = e + f
G = h + i
J = k + l
Can be executed at once since there is no dependency between the elements. But,
A = b + c
D = e + f
G = h + I + D
J = k + l
Will need to be executed in two cycles since A, D, J can be computed in parallel fist but the since G is dependent in D it will need to be executed later. Since in current instruction are essentially fetched decoded and executed in sequence these dependencies are not 100% apparent to the processor.
The new ISA focuses pushing data through different operations to arrive at the result of the algorithm where as nearly all the current ISAs (CISC, RISC, VLIW, etc.) concentrate operation performed on the operands.
I go the idea for this radical approach when studying algorithmic graph theory.
Depending on the executed code a many fold speed increase can be achieved using this architecture.
I have filed for a patent on this technique also. When these matters are finalized I like to licence the technology.
# 2
I attended Prof. Dave Patterson's talk at Multicore expo. He remarked that
in the last two decades, hardware was hard to change, software was easy to change.
Going forward, hardware will be easy to change, and software is hard to change.
Think about how ISV vendors will use these new instructions, think of the impact to the development tools ...
Innovation is good but also check for market relevance.
Do some performance analysis of standard benchmarks (you may have to
hack some tools, simulation models) to show performance gain.Show some real world results to show significance of your enhancements.
# 3
Well the simple examples I have given so far were just for illustration purposes.
This processes is more or less and "organic". If is build of small FUs. The instructions are implied therefore no decoding is involved. (I.e., the instruction appear in recurring patters therefore they are deducible by the position they occupy in the instruction stream.) In the simplest case the whole processor is implemented using only a move instruction. The FUs perform simple operations. The system has registers which are hardwired to the FUs. On writing to a hardwired register which purse as an input to a FU would result in the resultant value will be placed in a hardwired register.
Computation is achieved side effects of moving the registers. (When input registers are written the output registers will have a value of the operation.) A number of these moves happen in parallel. The compiler should packet number of these moves (perhaps in order or out of order) so that all the many of the independent instructions are executed in parallel. The parallelism is only limited by the number of parallel moves and the availability of FUs. (To gain maximum leverage there should be as many FUs, for a given operations, equivalent to the number of parallel operation generally found in programmes and the parallel moves that are possible should be as much as the number of parallel instructions generally possible in programmes.)
FUs can also be also added and removed to extend or change the capabilities.
?2006 Suminda Sirinath Salpitikorala Dharmasena. All rights reserved.
This does not constitute public disclosure. Please keep this information as private to the forum.
