Introduction to the Mill CPU Programming Model
ootbcomp.com
Introduction to the Mill CPU Programming Model
1–10 of 81 posts
Re: Introduction to the Mill CPU Programming Model
#2Re: Introduction to the Mill CPU Programming Model
#3I can't wait until designs like this become common.
Re: Introduction to the Mill CPU Programming Model
#4Would be interesting to find out:
1. How high that degree of parallelism can be pushed, are we talking about tens or hundreds of pipelines?
2. What frequency this will operate at?
3. What is up with RAM? I saw nothing about memory, with lots of pipelines it is bound to be memory bound.
Re: Introduction to the Mill CPU Programming Model
#5Re: Introduction to the Mill CPU Programming Model
#6Great idea, since it's all theoretical currently I'm wondering with the compiler offloading how well it will actually perform. Itanium was capable of doing some amazing things, but the compiler tech never quite worked out.
Re: Introduction to the Mill CPU Programming Model
#7Interesting, the architecture looks greatly simplified compared to even standard RISC (As opposed to lets say x86). Due to that simplification it will be power efficient while being inherently highly parallel. Would be interesting to find out: 1. How high that degree of parallelism can be pushed, are we talking about tens or hundreds of pipelines? 2. What frequency this will operate at? 3. What is up with RAM? I saw…
There's more information about memory in the talk at http://ootbcomp.com/topic/memory/
Re: Introduction to the Mill CPU Programming Model
#8Interesting, the architecture looks greatly simplified compared to even standard RISC (As opposed to lets say x86). Due to that simplification it will be power efficient while being inherently highly parallel. Would be interesting to find out: 1. How high that degree of parallelism can be pushed, are we talking about tens or hundreds of pipelines? 2. What frequency this will operate at? 3. What is up with RAM? I saw…
1: we manage to issue 33 operations / sec. This is easily a world record :) The way we do this is covered in the Instruction Encoding talk. We could conceivably push it further, but its diminishing returns. We can have lots of cores too.
2: its process agnostic; the dial goes all the way up to 11
3: the on-chip cache is much quicker than conventional architectures as the TLB is not on the critical path and we typically have ~25% fewer reads on general purpose code due to backless memory and implicit zero. The main memory is conventional memory, though; if your algorithm is zig zagging unpredictably through main memory we can't magic that away
Re: Introduction to the Mill CPU Programming Model
#9Great idea, since it's all theoretical currently I'm wondering with the compiler offloading how well it will actually perform. Itanium was capable of doing some amazing things, but the compiler tech never quite worked out.
Here's Ivan's bio that is tagged on his talks:
"Ivan Godard has designed, implemented or led the teams for 11 compilers for a variety of languages and targets, an operating system, an object-oriented database, and four instruction set architectures. He participated in the revision of Algol68 and is mentioned in its Report, was on the Green team that won the Ada language competition, designed the Mary family of system implementation languages, and was founding editor of the Machine Oriented Languages Bulletin. He is a Member Emeritus of IFIPS Working Group 2.4 (Implementation languages) and was a member of the committee that produced the IEEE and ISO floating-point standard 754-2011."
So actually its been designed almost compiler-first :)
Re: Introduction to the Mill CPU Programming Model
#10(I ask as a survivor of Multiflow in the late 80's. ;-)