I’m not sure I get your point? Are you saying it is impossible to accelerate the VAX instruction set via the same technique used on x86? If so, you’ll have to explain why. Now, whether you’d want to or not is another question.
I’m not sure I get your point? Are you saying it is impossible to accelerate the VAX instruction set via the same technique used on x86? If so, you’ll have to explain why. Now, whether you’d want to or not is another question.
Yes, it's not possible to do it the same way, because what made x86 successful in their application is that x86 was remarkably RISC-y in actual behaviour compared to 68k or VAX.
The main reason for that is that x86 code, outside of being register poor leading to lots of stack etc. use, decomposes most "ciscy" operations into LEA (inlined in pipeline) + memory access + actual operation.
VAX (and to lesser extent, m68k and others) had multiple indirections just to get the operands right, way more than what is essentially single LEA instruction. The most complex VAX instructions could have been ignored as "this is super slow one and rarely used", but the burden of handling the indirections remain, including possible huge memory latency costs.
Also, the VAX instruction encoding is a class of horror above that of x86.
few classes above.
Only ISA where I've seen a single instruction span two memory pages despite being page aligned
Two cache lines, sure, on earlier models, but not two VM pages!!
Maximum instruction length is 56 bytes. Early models had 8 byte cache lines, later ones 64 bytes. VM page 512 bytes.
I might be mistaken then, but I recall reading something about most extreme decode on VAX going into ~522 bytes.
What I am more certain of was complaints about possibly ending with maaaany TLB lookups (and pagetable walks) for certain "business" optimized instructions.