On the lack of progress reports from the Mill project

They have some cool ideas, but many are incompatible with existing software, e.g. all the memory protection stuff. Other ideas like how memory loads work could be integrated (and have been in place in GPUs for a long time, though not in CPUs) but still depend on compiler changes, which presumably they've done, but past experience with hardware projects that rely on compiler changes is that the compiler changes aren't performing well enough in practice. Or perhaps compilers improve so slowly that traditional architectures can easily absorb the ideas in time.

Another example is that Apple's M1 proves that wider frontends are possible in traditional architectures, as long as the instruction size is fixed. There's no particular reason to believe that the Mill would be inherently better at this than a traditional architecture.

If you have a lay person's interest in hardware architecture and haven't looked at their docs yet, do so. The ideas will likely tickle your brain in a good way -- they did for me. But don't expect much, if anything, from them in production.

It's not 2004 anymore, they should be able to make progress to making a chip at the gate counts they've been pitching with very little capital investment because of how much democratization of chip tech has happened over the past few years.

Plus I was under the impression that VCs want to at least see something running in an FPGA for a chip startup. The space is filled with software engineers that have trouble synthesizing their HDL. Cut out the fancy meta chip generator, sit down and write some HDL enough for a 'bronze' core and then I imagine the money will start flowing for the money for a leading edge node where the arch will really shine.

* Function calls as the primary built-in control flow mechanism. This is so obviously better its insane, this should be the base unit of control flow in an ISA. No inventing incompatible "conventions" for calls, no manually saving & restoring registers (or need to eke out optimizations by avoiding using registers), no accidentally trampling on external state. Called functions receive parameters in a consistent location and returned values are output in a consistent location, other incidental state not part of the parameters is inaccessible, upon return the caller's state is automatically restored as if it had just executed a 1-cycle cpu instruction. All for an overhead of 1 cycle.

* Instructions and functions can have multiple return values. No stupid out params just to return both an error and value or a value that is bigger than one word. CPU instructions use multiple return values for things that obviously need them instead of overloading stateful flags (eww) or interrupts (heave).

* Unified address space & address translation pushed down to the memory controller. This solves so many problems it's not even funny. Cached writes to memory can unblock as soon as it hits L1, reading from uninitialized memory gives you a pre-zeroed page -- instantly -- not in 300 cycles, the previous two means that it's possible to allocate + write + read + deallocate a memory page where it never actually touches main memory and is entirely served by cpu cache hierarchy, ejects expensive TLB address translation out of the hot path of memory accesses instructions, memory protection-based access control can be done in parallel with the fetch instead of the fetch being delayed until translation is calculated. (A process should not assume its the only thing that exists and that its starting address is always the same, ASLR should be on by default. Arguing that per-program virtual memory is a security feature is like arguing that NAT is a security feature. Access and addressing can be separated securely.)

* Machine code is basically a directly encoded form of Static Single Assignment (SSA) which is typically a compiler Intermediate Representation (IR) middle step in the compilation process, but the Mill consumes SSA directly which means that a lot of data flow information is preserved during the lowering to machine code and doesn't have to be inferred or guessed dynamically by the CPU during execution.

For reference when the mill project was started Intel was releasing pentium 4.

Is it really so hard to them to raise money? Look at some of the stupid ideas that have raised tens to hundreds of millions of dollars over the last few years.

When that started, I contacted them and asked how many part numbers the Analytical Engine needed. That's a basic number for sizing the build job. They didn't have an estimate. (In manufacturing, a part is one object, and a "part number" is the term for a part design from which many parts are made. Engineering and tooling effort is driven by the number of unique part numbers.)

If they were serious, they could start posting drawings and getting people to model them in SolidWorks or Fusion 360. Somebody would probably CNC machine the parts and make a sample storage register.

[1] http://plan28.org/