In my regards it seems that one of their sources of inspiration were Transmeta processors - VLIW core, software translator from some intermediate bytecode (x86 in case of transmeta).
I hope they will get it better this time.
Introduction to the Mill CPU Programming Model
61–70 of 81 posts
Re: Introduction to the Mill CPU Programming Model
#62In my regards it seems that one of their sources of inspiration were Transmeta processors - VLIW core, software translator from some intermediate bytecode (x86 in case of transmeta). I hope they will get it better this time.
They don't translate. Rather, they compile code to their instruction set.
Re: Introduction to the Mill CPU Programming Model
#63Earlier quoted context omitted.
Hi, I'm the author of that intro. The talks which Ivan has been giving - there are links in that intro - go into everything in much more detail. But here's a quick overview of your specific questions: 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…
>>: the on-chip cache is much quicker than conventional architectures as the TLB is not on the critical path I would really like to know your reasoning that the TLB is a major bottleneck in conventional CPUs. CPUs execute a TLB lookup in parallel with the cache, so there is usually no latency except on a TLB miss. Basic research on in-memory databases suggest eliminating the TLB would improve performance only by abou…
The reason the TLB is so fast is also that it is fairly small and thus misses fairly often. Moving the TLB so it sits before the DRAM means that you can have a 3-4 cycle TLB with thousands of entries.
Re: Introduction to the Mill CPU Programming Model
#64In my regards it seems that one of their sources of inspiration were Transmeta processors - VLIW core, software translator from some intermediate bytecode (x86 in case of transmeta). I hope they will get it better this time.
They don't translate. Rather, they compile code to their instruction set.
yes, wrong wording on my part
Re: Introduction to the Mill CPU Programming Model
#65Earlier quoted context omitted.
Hi, I'm the author of that intro. The talks which Ivan has been giving - there are links in that intro - go into everything in much more detail. But here's a quick overview of your specific questions: 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…
>>: the on-chip cache is much quicker than conventional architectures as the TLB is not on the critical path I would really like to know your reasoning that the TLB is a major bottleneck in conventional CPUs. CPUs execute a TLB lookup in parallel with the cache, so there is usually no latency except on a TLB miss. Basic research on in-memory databases suggest eliminating the TLB would improve performance only by abou…
Right, most modern caches use the virtual address to get the cache index and use the physical address for tag comparisons[1]. Since on x86 the bits needed for the tag are the same between the virtual and physical address the entire L1 lookup can be done in parallel, though for other architectures like ARM you need to finish the TLB step before the tag comparison[2].
But while I think the Mill people are overselling the direct performance benefits here, the single address space lets them do a lot of other things such as backing up all sorts of things to the stack automatically on a function call and handling any page fault that results in the same way that it would be handled if it was the result of a store instruction. And I think they're backless storage concept requires it too.
[1]http://en.wikipedia.org/wiki/CPU_cache#Address_translation [2] Unless you were to force the use of large page sizes, as some people suggest Apple might have done with their newest iPhone.
Re: Introduction to the Mill CPU Programming Model
#66Does anyone know how this compares with VLIW designs like the original Yale/Multiflow machines? Seems very familiar. (I ask as a survivor of Multiflow in the late 80's. ;-)
Well, this seems to fall within the VLIW tradition and has an exposed pipeline like the original VLIW, but there are a bunch of differences. In the original VLIW every instruction pipeline was conceptually a different processor while the Mill is very much unified around it's single belt, though I wonder if you could have a similar design with separate integer and floating point belts.
And instead of having a fixed instruction format the Mill has variable length bundles, which is good. Instruction cache pressure is certainly a traditional weakness of VLIW. So maybe you could say Mill:VLIW::CISC:RISC? But the most important part of RISC was separating memory access from operations and the Mill still certainly does that.
Re: Introduction to the Mill CPU Programming Model
#67In my regards it seems that one of their sources of inspiration were Transmeta processors - VLIW core, software translator from some intermediate bytecode (x86 in case of transmeta). I hope they will get it better this time.
They don't translate. Rather, they compile code to their instruction set.
Well, the plan is to distribute an intermediate representation and then specialize it to the particular mill pipeline the first time you load the binary. Probably a lot easier than translating something that wasn't designed for it.
Re: Introduction to the Mill CPU Programming Model
#68Very interesting reading. Are such procs already being sold or is this still on the workbench?
Re: Introduction to the Mill CPU Programming Model
#69This whole thing is just horribly exciting for a computer architecture geek like me. I am somewhat worried about the software side given the number of OS changes that would have to be made to support this. But then again, there are lots of places in the world where people are running simple RTOSes on high end chips and the Mill probably has a good chance there. The initial plan to use an older process and automated design means that the Mill can probably be profitable in relatively modest volumes.
Re: Introduction to the Mill CPU Programming Model
#70Earlier quoted context omitted.
They don't translate. Rather, they compile code to their instruction set.
Well, the plan is to distribute an intermediate representation and then specialize it to the particular mill pipeline the first time you load the binary. Probably a lot easier than translating something that wasn't designed for it.
I believe IBM mainframes have traditionally used something like that: binary code is shipped for a general mainframe architecture, and on first execution is specialized to the hardware / performance characteristics of the particular model within that architecture that you're running. Also allows for transparent upgrades, since if you migrate to a new model, the binary will re-specialize itself on the next execution, (ideally) taking advantage of whatever fancy new hardware you bought.