4 ms·

Unless you have a VLIW based architecture and the compiler takes care of the dependencies and hazard checking in software... then you are able to have dramatica

Unless you have a VLIW based architecture and the compiler takes care of the dependencies and hazard checking in software... then you are able to have dramatically simpler hardware (reducing area and power), along with faster performance! Wait another month and a half and I'll be getting around to writing my blog post in support of VLIW, and why previous attempts have failed miserably.

catnaroek 11y ago
Maybe this is a gross over-simplification, but isn't the tl;dr that VLIW architectures require significantly smarter compiler backends, and compiler writers were having none of that?
- trsohmers 11y ago
  Very overly simplified, but yes. Thankfully my team will be showing the significantly smarter compiler in the coming months. It is primarily for our own architecture that is both VLIW and requires full software management of the memory, but a lot of the techniques we have developed can improve compilers in a general sense. We have also built all of our work within/around LLVM, so our optimizations that occur on the LLVMIR can potentially be applied to other backends, and our backend optimizations make very performant VLIW scheduling actually real.
  - wolf550e 11y ago
    I thought of Mill Computing, but I see from your profile that it's a competitor. Your thing seems less radical. What do you think of the Mill?
    - trsohmers 11y ago
      I've talked with the Mill folks, and while I find their architecture intellectually/academically interesting, I just don't think that stack machines will ever take off. We've stuck to the tried and true von Neumann, while dramatically increasing memory bandwidth within a core, throughout a chip, and when connecting multiple chips, along with enforcing strict determinism at a hardware level, which is why our compilers work. We have one ACM paper published that is intentionally vague, but describes at a high level our scratchpad (software managed) memory techniques... we'll be talking the specifics of our full toolchain later this summer when we have a full public unveiling of the architecture. Another problem with Mill is that they have been around for a little over 10 years, and have not released anything publicly (though have given a number of very detailed talks). They have had a lot of trouble getting their design into FPGAs, and even more trouble with having working compilers. When I started REX, I believed in getting it into silicon as fast as possible, as that is the point when people would take us seriously. We closed funding in July of 2015, and are taping out our first silicon next month... While many have called us crazy (and we will be giving real information on why we are not that crazy), I definitely don't want to be called vaporware.
      - pohl 11y ago
        In what sense is the Mill a stack machine?
        trsohmers 11y ago
        The "belt" is very reminiscent of a stack. I was generalizing, but it is much closer to the traditional stack machine in terms of execution without registers than a load/store based RISC machine like every other mainstream architecture is at this point... Even though x86 is technically a CISC ISA, the actual mainstream implementations of it are RISC internally. At least for myself and my computer architecture friends/colleagues, most of us just throw Mill into the stack machine box even if it is not entirely true... the benefits of the Belt architecture over the traditional stack machine are there in concept, but Mill has also not released any real concrete information on their compilers (at least from what I have seen).
  - catnaroek 11y ago
    Wow, cool stuff. I've just checked your company's website. Do you provide any resources to programmers interested in learning your architecture? (Emulators, a reference manual for your instruction set, etc.)
    - trsohmers 11y ago
      Thanks. We'll be releasing a lot more information this summer, but most of our effort has been in actually getting things finished for tape out next month. We currently have some partners that are early evaluators using our current tools and FPGA based platform, and are trying to figure out the best way to make this more publicly available. We'll have actual hardware development/evaluation kits available this fall, so feel free to contact us or sign up for our mailing list to be alerted when we release details on all of that. As I said in a previous post here, I strongly believe that most people do not care about something that they can not physically touch, so I expect that most developers would much rather start to learn about and work on an architecture that actually has silicon available.

catnaroek 11y ago

Maybe this is a gross over-simplification, but isn't the tl;dr that VLIW architectures require significantly smarter compiler backends, and compiler writers were having none of that?

trsohmers 11y ago
Very overly simplified, but yes. Thankfully my team will be showing the significantly smarter compiler in the coming months. It is primarily for our own architecture that is both VLIW and requires full software management of the memory, but a lot of the techniques we have developed can improve compilers in a general sense. We have also built all of our work within/around LLVM, so our optimizations that occur on the LLVMIR can potentially be applied to other backends, and our backend optimizations make very performant VLIW scheduling actually real.
- wolf550e 11y ago
  I thought of Mill Computing, but I see from your profile that it's a competitor. Your thing seems less radical. What do you think of the Mill?
  - trsohmers 11y ago
    I've talked with the Mill folks, and while I find their architecture intellectually/academically interesting, I just don't think that stack machines will ever take off. We've stuck to the tried and true von Neumann, while dramatically increasing memory bandwidth within a core, throughout a chip, and when connecting multiple chips, along with enforcing strict determinism at a hardware level, which is why our compilers work. We have one ACM paper published that is intentionally vague, but describes at a high level our scratchpad (software managed) memory techniques... we'll be talking the specifics of our full toolchain later this summer when we have a full public unveiling of the architecture. Another problem with Mill is that they have been around for a little over 10 years, and have not released anything publicly (though have given a number of very detailed talks). They have had a lot of trouble getting their design into FPGAs, and even more trouble with having working compilers. When I started REX, I believed in getting it into silicon as fast as possible, as that is the point when people would take us seriously. We closed funding in July of 2015, and are taping out our first silicon next month... While many have called us crazy (and we will be giving real information on why we are not that crazy), I definitely don't want to be called vaporware.
    - pohl 11y ago
      In what sense is the Mill a stack machine?
      - trsohmers 11y ago
        The "belt" is very reminiscent of a stack. I was generalizing, but it is much closer to the traditional stack machine in terms of execution without registers than a load/store based RISC machine like every other mainstream architecture is at this point... Even though x86 is technically a CISC ISA, the actual mainstream implementations of it are RISC internally. At least for myself and my computer architecture friends/colleagues, most of us just throw Mill into the stack machine box even if it is not entirely true... the benefits of the Belt architecture over the traditional stack machine are there in concept, but Mill has also not released any real concrete information on their compilers (at least from what I have seen).
- catnaroek 11y ago
  Wow, cool stuff. I've just checked your company's website. Do you provide any resources to programmers interested in learning your architecture? (Emulators, a reference manual for your instruction set, etc.)
  - trsohmers 11y ago
    Thanks. We'll be releasing a lot more information this summer, but most of our effort has been in actually getting things finished for tape out next month. We currently have some partners that are early evaluators using our current tools and FPGA based platform, and are trying to figure out the best way to make this more publicly available. We'll have actual hardware development/evaluation kits available this fall, so feel free to contact us or sign up for our mailing list to be alerted when we release details on all of that. As I said in a previous post here, I strongly believe that most people do not care about something that they can not physically touch, so I expect that most developers would much rather start to learn about and work on an architecture that actually has silicon available.