http://ootbcomp.com/docs/

No GP registers. Single address space but still using page tables. They claim up to 33 operations per cycle. Each CPU version needs different binary code so assembly might not be supported, instead using loader code to generate the bits at runtime.

But it is also vapourware so maybe nothing will come of it.

There are some clever ideas. But you never know. They might deliver. Or they might get bought without delivering the Mill to the market. They can be seen as a threat to the existing products or as a useful resource. There might be some value in their patents (I don't know how many they've applied for and how many they've got or what's in them besides the content of the publicly available videos and slides). I don't think they'll just disappear as if never existed.

There is a looooooooooooooooooooooooooooooooong discussion here: http://forum.osdev.org/viewtopic.php?f=15&t=27743

Lost me at "terrorism".

The fact that that binary encodings change depending upon the specific CPU configuration means that if an assembler was to be used then it would have to generate different code for each target CPU that it will be run on.

Also the source code might need changing for each CPU model because basic things like belt length are different and thus needs different handling within the expression of the algorithms.

It is not clear to me whether each implementation of the same specced CPU will use the same encodings. There appears to be an automatic generator used to define the encodings and no human is involved the the bit allocation. So if there is some new method used or an algorithmic improvement in the bit encoding it could be that a newer version of the same specced chip would have a different binary instruction encoding. And this is the point (if correct) that would kill assembly code on a practical level and force the use of the "specialiser" to convert intermediate code into hardware opcodes.