Difference between revisions of "Architecture"
(Created page with "== Introduction == The Mill architecture is a general purpose processor architecture paradigm in the sense that [http://en.wikipedia.org/wiki/Stack_machine stack machine] or...") | |||
| Line 8: | Line 8: | ||
This approach traditionally has problems dealing with common general purpose workload operations and flows like branches, particularly while-loop [[Execution]], as well as with hiding [[Memory]] access latency. Those problems have been addressed, and so the static scheduling by the [[Compiler]] offloads most of the work that had to be done in hardware on every cycle into once at complile time tasks. This is where most power savings and performance gains come from in comparison to traditional general purpose architectures. | This approach traditionally has problems dealing with common general purpose workload operations and flows like branches, particularly while-loop [[Execution]], as well as with hiding [[Memory]] access latency. Those problems have been addressed, and so the static scheduling by the [[Compiler]] offloads most of the work that had to be done in hardware on every cycle into once at complile time tasks. This is where most power savings and performance gains come from in comparison to traditional general purpose architectures. | ||
| + | |||
| + | <br /> | ||
| + | <imagemap> | ||
| + | File:Architecture.png|alt=Mill Architecture | ||
| + | desc none | ||
| + | rect 270 110 340 140 [[Streamer]] | ||
| + | rect 80 210 190 250 [[Prefetch]] | ||
| + | rect 200 210 300 250 [[Prediction]] | ||
| + | rect 0 260 370 340 [[Decode]] | ||
| + | rect 620 220 690 240 [[Metadata]] | ||
| + | rect 620 200 630 220 [[Metadata]] | ||
| + | rect 375 145 545 275 [[Belt]] | ||
| + | rect 600 160 700 255 [[Belt#Belt_Position_Data_Format]] | ||
| + | rect 410 80 550 145 [[Execution]] | ||
| + | rect 410 280 550 340 [[Flow]] | ||
| + | rect 550 80 680 145 [[Registers]] | ||
| + | rect 100 340 170 420 [[Protection]] | ||
| + | rect 330 340 400 420 [[Protection]] | ||
| + | rect 590 270 700 310 [[Scratchpad]] | ||
| + | rect 540 310 700 580 [[Spiller]] | ||
| + | rect 0 370 700 500 [[Memory]] | ||
| + | default [http://millcomputing.com/w/images/3/3e/Architecture.svg] | ||
| + | |||
| + | </imagemap> | ||
| + | <br /> | ||
== Overview == | == Overview == | ||
Revision as of 21:30, 26 July 2014
Introduction
The Mill architecture is a general purpose processor architecture paradigm in the sense that stack machine or a RISC processor is a processor architecture paradigm.
It is also a processor family architecture in the sense that x86 or ARM are processor family architectures.
To briefly classify the Mill architecture: it is a statically scheduled, in order Belt architecture, i.e. like in a DSP all instructions are issued in the order they are present in the binary instruction stream.
This approach traditionally has problems dealing with common general purpose workload operations and flows like branches, particularly while-loop Execution, as well as with hiding Memory access latency. Those problems have been addressed, and so the static scheduling by the Compiler offloads most of the work that had to be done in hardware on every cycle into once at complile time tasks. This is where most power savings and performance gains come from in comparison to traditional general purpose architectures.
Overview
This could be described as the general design philosophy behind the Mill: Remove anything that doesn't directly contribute to computation at runtime from the chip as much as possible, perform those tasks once and optimally in the compiler and use the freed space for more computation units. This results in vastly improved single core performance through more instruction level parallelism as well as more room for more cores.
There are quite a few hurdles for traditional architectures to actually utilize the large amount of instruction level parallelism provided by many ALUs. Some of the most unique and innovative features of the Mill emerged from tackling those hurdles and bottlenecks.
The Belt for example is the result of having to provide many data sources and drains for all those computational units, interconnecting them without tripping over data dependencies and hazards and without having polynomal growth in the cost of space and power for interconnecting.
The unusual split stream, variable length, VLIW Encoding makes the parallel feeding of all those ALUs with instructions possible, in a die space and energy efficient way with optimally computed code density.
Techniques like Phasing, Pipelining and explicitly scheduled load latencies, branch Prediction over several jumps with prefetch and a very short pipeline all minimize the occurence and impact of stalls for unhindered Execution.
Metadata enables safe speculative execution over untaken branches and even exceptions, reducing any stalls even more and increasing parallelism. It also offers tremendous savings in opcode complexity and size.
A new Memory access model with caches fully working on virtual addresses, and the Protection mechanisms uncoupled from adress translation makes you never wait for address translation unless it is masked by DRAM access anyway.
