Or you know, you mandate most of the stuff in the core arch document with the assumption that on tiny cores that lack.. say multiply instructions its handed by.

Or you know, you mandate most of the stuff in the core arch document with the assumption that on tiny cores that lack.. say multiply instructions its handed by.. wait for it... microcode. Which actually given the toy CPU's i've implemented is pretty easy to do even if your talking something that fits on a small/medium sized FPGA. Illegal instruction traps are a lot worse/harder to get right than just cracking an unsupported opcode into a string of microops, particularly if the arch has simple addressing modes that themselves won't ever need to be part of multiple micro ops. AKA you won't have to deal with fault handling in the middle of a sequence. And even worse, the optimal sequence is likely diffrent for every tiny micro arch change, or even change in memory subsystem characteristics. So it needs to be tied to the core and associated memory subsystem, which on a popular arch implemented across the scale of platforms you find x86/arm is going to be unachievable without lots of unoptimal code being used.