6 ms·

As I understand, they aren't seeking venture capital backing, so progress is slow. I know they have (had) plans to implement a Mill on an FPGA, but even going

by uxcn 11y ago

As I understand, they aren't seeking venture capital backing, so progress is slow. I know they have (had) plans to implement a Mill on an FPGA, but even going to a usable ASIC will probably be a challenge. It's a major architectural change as well. Most existing systems rely on virtual memory, which the Mill doesn't support.

adwn 11y ago
> Most existing systems rely on virtual memory, which the Mill doesn't support. I believe you're mistaken. The Mill does support virtual memory; the main differences to most systems are that its caches use virtual addresses (the TLB is between the L2 cache and the DRAM), and that it's a single-address-space architecture.
- uxcn 11y ago
  Sorry, I did misunderstand. I see. I was under the impression they were entirely doing away with the hardware necessary for virtual memory.
- aidenn0 11y ago
  ARM did that with L1 cache in the '90s and it was terrible for targeting a VM OS to. Cache aliasing is a nightmare and a never-ending source of bugs for e.g. shared memory.
  - vanderZwan 11y ago
    Maybe this talk answers questions you may have? (since it's specifically about memory on the Mill CPU) http://millcomputing.com/docs/memory/ http://millcomputing.com/docs/memory/
  - mike_hearn 11y ago
    It's very likely that they will need to write their own OS from scratch for the Mill. They might be able to reuse a lot of code from Linux, but it won't be Linux, as the whole ethos of the Mill is to rethink everything. In particular the Mill does not have the same notion of a process, the CPU itself is aware of threading, it has its own security design that isn't anything like user/supervisor mode, there are no syscalls, and programs have to be specialised before they can be run, a la ART on Android. I suspect once they have LLVM up and running, one of the next biggest wins they'll want to go for is porting HotSpot. The only other company I'm aware of that was able to actually make money selling a really crazy custom CPU architecture is Azul with their Vega arch, and they did it by making Java bytecode their exposed bytecode. The actual CPU opcodes were an implementation detail and everything compiled on the fly. The nice thing about porting the JVM is tons of business-critical, performance sensitive code would Just Work™. And then you have a ready made market for companies with huge Java (e.g. Hadoop) jobs that are very power/performance tradeoff sensitive.
    - dogma1138 11y ago
      Is VEGA an actual discrete CPU architecture or something they've licensed/copied from existing chips? Azul made their money from selling high performance JVM's they have their "VEGA" compute appliances for Java applications but I've never actually seen their ISA documentation for the hardware which would be a very interesting thing to see....
      - mike_hearn 11y ago
        It's apparently entirely custom. There are some tech talks about it online.
  - fulafel 11y ago
    Aliasing problems are conveniently eliminated by the single address space.
    - aidenn0 11y ago
      If it's single address space, I wouldn't call it Virtual Memory. That sounds more like what the Blackfin had. I'm going to watch their memory talk today (when I can get a free 90 minutes). [edit] Reading the Memory page on the wiki, it is indeed SAS with an MPU. Obvious difference from Blackfin is that you have 2^28 times as many addresses available. It would also be interesting to see how much smaller a PLB entry is compared to a typical TLB. TLB misses are responsible for a surprising amount of performance loss on some workloads as L2 caches have gotten so much larger, so if they can have e.g. an order of magnitude more entries in the PLB it would be a big performance win. [edit3] It just occurred to me that your PLBs could be as slow as your L1 cache with little impact on performance. This can also let them be physically larger than your TLBs. Assuming the ISA is designed for efficient PIC/PID a unix-like shouldn't be too terrible to port from that difference alone. I know there have been SAS unixes before. I have run into the 46-bit userspace limit on linux AMD64 (think mmap), so I'm somewhat concerned 64-bits may not be enough in the future as disks get bigger, though that's a long way off as you have 2^14 times that room under this scheme. [edit2] It's a 60-bit SAS, not a 64-bit SAS
      - adwn 11y ago
        > If it's single address space, I wouldn't call it Virtual Memory. The term "virtual memory" refers to a dynamic mapping between physical and virtual addresses. SAS doesn't preclude virtual memory; you can still have many of the advantages of virtual memory without multiple address spaces (for example, memory mapped files).
      - willvarfar 11y ago
        (Mill team) Afraid this answer is quite late, but hopefully it finds the curious passing through anyway :) The really big gains from splitting protection from translation are twofold: First, you can do the protection lookup in parallel to the cache lookup, rather than before it. This allows the PLB to be much bigger than a conventional TLB could ever be. Second, the PLB entries do not need to be fixed power-of-two sizes. Each PLB entry has a start and stop offset so protection can be as granular as protecting one byte. In general, though, a single PLB entry will be quite large, covering the whole mapped region. The Mill still has a TLB but it sits between chip and the off-chip memory. This allows it to be larger than a conventional TLB, as it taking slightly longer will not have the same impact. Additionally, as a small implementation optimisation, the TLB on the bigger Mill family members will do a lot of things like allocating-from-a-pool dynamically, so you only trap to the OS when things get dire. The Mill address has a special bit to signify if it is a global address, or whether it is "local" to the process (using a special register which is XORed into the address). This allows the Mill to fork() and all the other things that traditionally have been hard on a SASOS. We are porting Linux, and it will be Linux. Only a very very small part of the HAL will need to know anything Mill-specific :)
  - Veedrac 11y ago
    All of the Mill's cache, not just one level, is virtual SAS. Further, the Mill has no false aliasing, consistent caches, is always sequentially consistent and has no aliasing races. Some of this is covered in http://millcomputing.com/wiki/Memory http://millcomputing.com/wiki/Memory. The more criticisms I hear of this architecture, the more impressed I get.

by uxcn 11y ago

adwn 11y ago

> Most existing systems rely on virtual memory, which the Mill doesn't support. I believe you're mistaken. The Mill does support virtual memory; the main differences to most systems are that its caches use virtual addresses (the TLB is between the L2 cache and the DRAM), and that it's a single-address-space architecture.

uxcn 11y ago
Sorry, I did misunderstand. I see. I was under the impression they were entirely doing away with the hardware necessary for virtual memory.
aidenn0 11y ago
ARM did that with L1 cache in the '90s and it was terrible for targeting a VM OS to. Cache aliasing is a nightmare and a never-ending source of bugs for e.g. shared memory.
- vanderZwan 11y ago
  Maybe this talk answers questions you may have? (since it's specifically about memory on the Mill CPU) http://millcomputing.com/docs/memory/ http://millcomputing.com/docs/memory/
- mike_hearn 11y ago
  It's very likely that they will need to write their own OS from scratch for the Mill. They might be able to reuse a lot of code from Linux, but it won't be Linux, as the whole ethos of the Mill is to rethink everything. In particular the Mill does not have the same notion of a process, the CPU itself is aware of threading, it has its own security design that isn't anything like user/supervisor mode, there are no syscalls, and programs have to be specialised before they can be run, a la ART on Android. I suspect once they have LLVM up and running, one of the next biggest wins they'll want to go for is porting HotSpot. The only other company I'm aware of that was able to actually make money selling a really crazy custom CPU architecture is Azul with their Vega arch, and they did it by making Java bytecode their exposed bytecode. The actual CPU opcodes were an implementation detail and everything compiled on the fly. The nice thing about porting the JVM is tons of business-critical, performance sensitive code would Just Work™. And then you have a ready made market for companies with huge Java (e.g. Hadoop) jobs that are very power/performance tradeoff sensitive.
  - dogma1138 11y ago
    Is VEGA an actual discrete CPU architecture or something they've licensed/copied from existing chips? Azul made their money from selling high performance JVM's they have their "VEGA" compute appliances for Java applications but I've never actually seen their ISA documentation for the hardware which would be a very interesting thing to see....
    - mike_hearn 11y ago
      It's apparently entirely custom. There are some tech talks about it online.
- fulafel 11y ago
  Aliasing problems are conveniently eliminated by the single address space.
  - aidenn0 11y ago
    If it's single address space, I wouldn't call it Virtual Memory. That sounds more like what the Blackfin had. I'm going to watch their memory talk today (when I can get a free 90 minutes). [edit] Reading the Memory page on the wiki, it is indeed SAS with an MPU. Obvious difference from Blackfin is that you have 2^28 times as many addresses available. It would also be interesting to see how much smaller a PLB entry is compared to a typical TLB. TLB misses are responsible for a surprising amount of performance loss on some workloads as L2 caches have gotten so much larger, so if they can have e.g. an order of magnitude more entries in the PLB it would be a big performance win. [edit3] It just occurred to me that your PLBs could be as slow as your L1 cache with little impact on performance. This can also let them be physically larger than your TLBs. Assuming the ISA is designed for efficient PIC/PID a unix-like shouldn't be too terrible to port from that difference alone. I know there have been SAS unixes before. I have run into the 46-bit userspace limit on linux AMD64 (think mmap), so I'm somewhat concerned 64-bits may not be enough in the future as disks get bigger, though that's a long way off as you have 2^14 times that room under this scheme. [edit2] It's a 60-bit SAS, not a 64-bit SAS
    - adwn 11y ago
      > If it's single address space, I wouldn't call it Virtual Memory. The term "virtual memory" refers to a dynamic mapping between physical and virtual addresses. SAS doesn't preclude virtual memory; you can still have many of the advantages of virtual memory without multiple address spaces (for example, memory mapped files).
    - willvarfar 11y ago
      (Mill team) Afraid this answer is quite late, but hopefully it finds the curious passing through anyway :) The really big gains from splitting protection from translation are twofold: First, you can do the protection lookup in parallel to the cache lookup, rather than before it. This allows the PLB to be much bigger than a conventional TLB could ever be. Second, the PLB entries do not need to be fixed power-of-two sizes. Each PLB entry has a start and stop offset so protection can be as granular as protecting one byte. In general, though, a single PLB entry will be quite large, covering the whole mapped region. The Mill still has a TLB but it sits between chip and the off-chip memory. This allows it to be larger than a conventional TLB, as it taking slightly longer will not have the same impact. Additionally, as a small implementation optimisation, the TLB on the bigger Mill family members will do a lot of things like allocating-from-a-pool dynamically, so you only trap to the OS when things get dire. The Mill address has a special bit to signify if it is a global address, or whether it is "local" to the process (using a special register which is XORed into the address). This allows the Mill to fork() and all the other things that traditionally have been hard on a SASOS. We are porting Linux, and it will be Linux. Only a very very small part of the HAL will need to know anything Mill-specific :)
- Veedrac 11y ago
  All of the Mill's cache, not just one level, is virtual SAS. Further, the Mill has no false aliasing, consistent caches, is always sequentially consistent and has no aliasing races. Some of this is covered in http://millcomputing.com/wiki/Memory http://millcomputing.com/wiki/Memory. The more criticisms I hear of this architecture, the more impressed I get.