> Arguably Itanium's failure was due to exceeding the weirdness budget with VLIW nonsense

Being VLIW was probably the least weird part of Itanium. The NaT ("not a thing") bit on every register was the weirdest part and probably the one which tripped people the most. And like SPARC, it had register windows. It also had a pair of stacks instead of a single one, a set of predicate registers (which also had their own register windows), and plenty of other assorted weirdness.

The advanced loads (sort of software controlled speculative loads) were real goofy too (but neat!)

x86 sort of has two stacks today as a security mitigation https://techcommunity.microsoft.com/t5/windows-kernel-intern...

The mill guys post one or two updates per year on their forum site. Apparently covid messed up their timeline a lot, but they aren't bankrupt or anything.

What is up with those guys?

I don't think they know how to move a project forward. What's it been, 20 years?

I think they don't have a rich enough VC friend, and they need a kick up the arse before (to be blunt) they get too old.

Ivan was saying that they weren't sure about how to get money, and then someone quite rightfully pointed out that this is probably the most liquid time in years for funding startups.

Mill team if you're reading this: Get your IP sorted out then open source everything, then start talking to VCs aggressively. Not the other way round because everyone thinks you're either a joke or a group of fantasists.

Cool ISA, hopeless execution. Where's the FPGA model?

The mill folks don't care for investment. Most of them are already very rich. They also aren't big on openness: they have a ton of patents.

What’s their end game? Do they ever want a product?

I think they just have a small team. Most recent work has been on their software stack (emulator, compiler etc), which I think is fairly close to release, but I could be wrong about that.

I might be missing something, but I never figured out where mill was saving all those gates they claimed. It could be my lack of imagination, but the straightforward way to implement the belt just looks like a ROB and bypass network just like a normal OoO core spends it's gates on.

And on the frontend, sure they mark instruction boundaries within an instruction bundle, but you still need N barrel shifters (where N is the number of max instructions per cycle) to get at them, and that's the expensive part of wide decode. Even 16bit aligned is so much nicer for the critical path than 8-bit, bit aligned is absolutely crazy town.

Bit aligned instructions? Yeah, that definitely sounds mad, like my joke proposal that instructions should be Huffman-coded so the frequent ones take fewer bits. Might make sense if you're doing a microcontroller with a few K of ROM and need to save bits, but otherwise no.

I'm not sure that you'd do that even on a microcontroller. If you don't have the ROM space, you probably also don't have the transistor budget for the decoder you'd need to handle that.

I think they are claiming a savings on a register file, which is not nothing, but not exactly a ton. Also they save on register renaming and scoreboards, which have some gate count.

The biggest thing that they seem to have is that they can compute an enormous number of instructions per cycle without blowing up the size of the bypass network.

If their goal is to save on register file space, they're barking up the wrong tree, IMO. The Skylake-X die[0], for example, dedicates only about 1% to the integer register file, and only about 2.5% for the floating point register file. The decoder and scheduler also take up only single digit percents.

Granted, this is a top of the line superscalar processor with AVX-512 and megabytes of cache, but my point still stands. The vast majority of the gates are in everything else: cache, execution units, branch prediction, load/store, die interfaces, etc.

[0]: https://twitter.com/GPUsAreMagic/status/1256866465577394181

> exceeding the weirdness budget with VLIW nonsense

I feel like the Russian "Elbrus" architecture did the same exact thing.

They hide it well though, like transmeta.

If you mean the x86 emulation, it's not supposed to be the default mode of operation.

Its supposed to be a valid way to use the chip. The Russian military has a lot of windows systems and wants to run that on domestically developed chips that don't have a management engine.

The Mill weirdeness is weird in the sense that it's almost perfectly compatible with C-like code. It's not this that is impacting the project.

Instead, launching a new architecture is an herculean task. Trying that inside anything that isn't a huge company or consensus on the academic world has a history of nearly 100% failure since huge companies started building computers. (And even the consensus on the academic world is iffy.)

The fab collects. Weird budget is unlimited as long as you don't tape out. Then the real world hits.

At this point, we can safely say that Mill was just an odd engineer's weird fetish.