Agner`s CPU blog

Load/store multiple registers instruction:
I guess that one depends on just how many microcoded instructions you have to deal with. To me, I think the #1 priority is making out-of-order C++ run as fast as possible, and setting a "single result register per instruction" limit helps a lot with this goal, because it removes a lot of degenerate cases like "4 two-result instructions in one cycle" (which means 8x register rename at front-end and 8x register writeback at back-end - this is bad).

Add with Carry:
It's true that if you want to do lots of BIGNUM computation, then you'll definitely want a flags registers (and 64x64->128 multiplies), whereas if you're doing general purpose C++ on an out-of-order cpu, you never need flags and multi-result instructions just aren't worth the extra trouble (which is why MIPS never had them). I have a weird suggestion here: BIGNUM computation will probably always happen on the SIMD unit, so you probably only want flags on the SIMD unit. Or perhaps you could use scalar integer registers as flags on SIMD operations designed for BIGNUMs.

Separate Register Files:
For SIMD code you could definitely have both float and integer vectors in the same register file, and a lot of instruction sets do this. In fact, you could have a register set for SIMD integer+SIMD float+scalar float (this is what ARM does) and it would be usable. I guess I was arguing specifically for not mixing scalar integers and scalar floats.

Predicated instructions / 8-bit and 16-bit ALU instructions:
I think that integer scalar and SIMD operations shouldn't be orthogonal. They don't really need to be, and they're optimized for different things (C++ compiler code and heavy out-of-order execution for integer scalar, maximum throughput at the cost of increased latency for SIMD). So predication and 8/16 bit data should probably be restricted to SIMD units.

Exceptions:
This is the kind of stuff that does pop up occasionally: MIPS and PA-RISC have versions of ADD that trigger overflow interrupts, x86 has the BOUND instruction (but CPUs typically don't optimize for it - for instance it issues on the vector path on the Athlon and it has 6 cycle latency). The problem is that C++ doesn't use these (+ - * are expected to wrap, and the way C++ conflates arrays and pointers prevent bounds checking most of the time), and higher-level languages typically have to do fancy fallbacks (try {} catch() and so forth) which precludes something as blunt as an interrupt. BOUND is essentially racing against an easy-to-predict conditional branch (which becomes free if the CPU isn't issuing full IPC at any point in the loop).