The specs drive scripts which generate the hardware, test interfaces, C headers for software and the PDF manual we give to our customers. I assume everyone is doing this: how else can you guarantee thousands of pages of documentation and a large API match the product perfectly?
What's new is ARM is giving that internal specification to customers. Makes a lot of sense given their customers are also chip companies with similar practices. I think it's a good idea and everyone should do it.
Not just customers but everyone, judging by the fact that I could just click the links in the post and download the files.
Or, on a more technical note, my feeling is that if that is what you wanted to do, then you would not start from the style of specification ARM has released.
I'd bet there already are clones/semi-clones of ARMs hidden in various obscure far-East ICs which have no user-accessible firmware... we just don't hear about them because the ones we do, would've been sued out of existence. I've seen presumably-unlicensed MIPS cores a lot in those.
Now if we had a peripheral specification like this we could auto generate to a given HAL and that would pretty much make the instruction set architecture completely irrelevant to systems folks building things.
To give a concrete example, suppose you want to compile "c = a + b;". You would realise this is an addition operation, then look at the sizes of the variables and consider where they are/will be. You then search for instructions in the instruction set which can perform addition. Maybe the source operands are in memory and the only addition instructions operate on registers (like ARM) in which case you would then have to solve the sub-problem of getting them into a register, by searching for more instructions which do that; or perhaps (like x86) only one of the operands need be in a register, so you only need to solve that sub-problem once. After you've chosen an instruction, update the machine state and continue with the next operation. Etc. etc. A compiler uses a similar algorithm, and could be driven by this spec. It's not in a good form for efficient compilation (e.g. indexing by operation(s) performed would be far better), but it contains the necessary mapping.
Of course there are plenty of subtle details in this whole process, but it is very possible to do this type of "table-driven meta-compilation". At least for Asm, there are a few table-driven (dis)assemblers which operate on a very similar principle.
If anything, a "table-driven decompiler" using this spec might be a bit easier, since that is directly mapping machine instructions into their higher-level operations.
Table driven assemblers and disassemblers would be straightforward to produce from this spec, yes, because those just need to care about the instruction patterns and the mnemonics. A compiler backend needs to care about the semantics of the instructions, which are in the pseudocode, and thus harder to automatically reason about. (For instance lots of the instructions include an add somewhere, but how do you find the one that is just a plain add rather than saturating or simd or also setting the condition flags?) Writing something smart enough would I think be vastly more work than just doing a compiler backend by hand, and likely produce worse code anyway. (A sibling comment suggests it would be phd-thesis level work and I think I'd agree with that.)
And within ARM, there were lots of people transcribing bits of the ARM manual into various forms: C/C++, LLVM .td files, Verilog, spreadsheets, etc. Apart from all the wasted effort, this also created a verification problem: each transcription had its own set of bugs that now had to be fixed. And it missed a verification opportunity: if everyone used the same master copy then each time one group spots a bug and reports it, the spec gets better for everybody.
I talked about this virtuous cycle at S-REPLS last year: https://alastairreid.github.io/papers/srepls4-trustworthy.pd... (S-REPLS is a programming language seminar in SE England.)
Good for them.
Topics included the license, what you can do with it, what other specs are out there (for ARM and others), ARM's love of arm/leg/limb-related acronyms and how much people hate XML.