5 ms·

Maybe the future is not about fixed instruction sets at all [1]. Especially with the rise of high-level hardware synthesis methods, platforms and tools like Kam

by snaky 8y ago

Maybe the future is not about fixed instruction sets at all [1]. Especially with the rise of high-level hardware synthesis methods, platforms and tools like Kami [2]. Of course, tooling and C compilers for the non-standard ISA are the main obstacles on this way. [1] "Synthesis of Processor Instruction Sets from High-Level ISA Specifications" IEEE Transactions on Computers 2014, 63(6), 1552-1566 [2] https://deepspec.org/entry/Project/Kami https://deepspec.org/entry/Project/Kami

ChuckMcM 8y ago
> Of course, tooling and C compilers for the non-standard ISA are the main obstacles on this way. Yup, see the Itanium architecture for how pernicious this can be to the survival of an architecture.
- snaky 8y ago
  What exactly is the lesson of Itanium is debatable. > Q: I feel like deja vu - at Hot Chips, Intel introduced VLIW-concept Itanium that pushed complexity onto the compiler. I see traces of that here. What are you doing to avoid the Itanium traps? How will you avoid IP from Intel? > A: Itanium was in-order VLIW, hope people will build compiler to get perf. We came from opposite direction - we use dynamic scheduling. We are not VLIW, every node defines sub-graphs and dependent instructions. We designed the compiler first. We build hardware around the compiler, Intel approach the opposite. https://www.anandtech.com/show/13255/hot-chips-2018-tachyum-prodigy-cpu-live-blog https://www.anandtech.com/show/13255/hot-chips-2018-tachyum-... I don't think that's the way of the future anyway, but C is not the only programming language, fortunately. Generating the ISA, and then CPU from specification, the next logical step is to generate highly optimized lower-than-C-level code from high-level specifications too.
- zozbot123 8y ago
  The Itanium folks actually put a lot of effort into tooling and compilers for the architecture, back in the early 2000s - even FLOSS tooling. The problem on that side was that a community never coalesced around Itanium, the way it did around e.g. amd64, or nowadays around riscv.
  - jabl 8y ago
    Indeed, they put lot of effort into it, but the main problem was that they committed to the HW architecture with the expectation that compiler R&D would fix the even by then well-known issue of generating good VLIW code for general-purpose software. Turned out this was a fatal mistake, and compiler tech has yet to advance to the level they expected. RISC, while older, at least was informed by what real compilers actually liked (lots of GPR's, simple instructions).
- pjmlp 8y ago
  The Itanium failed because Intel signed cross-licensing deals with AMD a couple of years before, and AMD just got lucky with their extensions. If there was no AMD in the picture we would all be using some form of Itanium by now.

by snaky 8y ago

ChuckMcM 8y ago

> Of course, tooling and C compilers for the non-standard ISA are the main obstacles on this way. Yup, see the Itanium architecture for how pernicious this can be to the survival of an architecture.

snaky 8y ago
What exactly is the lesson of Itanium is debatable. > Q: I feel like deja vu - at Hot Chips, Intel introduced VLIW-concept Itanium that pushed complexity onto the compiler. I see traces of that here. What are you doing to avoid the Itanium traps? How will you avoid IP from Intel? > A: Itanium was in-order VLIW, hope people will build compiler to get perf. We came from opposite direction - we use dynamic scheduling. We are not VLIW, every node defines sub-graphs and dependent instructions. We designed the compiler first. We build hardware around the compiler, Intel approach the opposite. https://www.anandtech.com/show/13255/hot-chips-2018-tachyum-prodigy-cpu-live-blog https://www.anandtech.com/show/13255/hot-chips-2018-tachyum-... I don't think that's the way of the future anyway, but C is not the only programming language, fortunately. Generating the ISA, and then CPU from specification, the next logical step is to generate highly optimized lower-than-C-level code from high-level specifications too.
zozbot123 8y ago
The Itanium folks actually put a lot of effort into tooling and compilers for the architecture, back in the early 2000s - even FLOSS tooling. The problem on that side was that a community never coalesced around Itanium, the way it did around e.g. amd64, or nowadays around riscv.
- jabl 8y ago
  Indeed, they put lot of effort into it, but the main problem was that they committed to the HW architecture with the expectation that compiler R&D would fix the even by then well-known issue of generating good VLIW code for general-purpose software. Turned out this was a fatal mistake, and compiler tech has yet to advance to the level they expected. RISC, while older, at least was informed by what real compilers actually liked (lots of GPR's, simple instructions).
pjmlp 8y ago
The Itanium failed because Intel signed cross-licensing deals with AMD a couple of years before, and AMD just got lucky with their extensions. If there was no AMD in the picture we would all be using some form of Itanium by now.