Exophase (exophase@gmail.com) on 12/20/11 wrote:
>
>I don't know why you think I'm disregarding x86's strengths when I list them out
>pretty categorically.

You seem to ignore it when I say that even the two-uop case
is not at all unreasonable for a store - exactly because
the address generation can be a big deal.

>is useless. Yes, I didn't list absolute addresses specifically, I figured that was
>redundant with reg + reg + imm even if the latter doesn't necessarily have to allow for the former.

Everybody has some "imm", but the broken fixed-length
instruction sets usually have an immediate that is limited
to 8 or 16 bits.

Which is simply not good enough for general cases, and then
you have to load addresses with another load instruction.

In contrast, x86 can generally generate most relevant
addresses without having to have that "load address from
GP table" kind of crap.

ARM has immediates, but they are *tiny*. I don't know
how big they are in ARM64, but since the whole insn is
32 bits, we know they aren't big.

>This lists absolute addressing is only being 1% of operand types.

Few enough people use true absolute addressing, although it
does get used for 32-bit globals etc (but even then it does
not work well with relocatable code).

But in 64-bit code, RIP-relative addressing is certainly
not uncommon, and again, the immediates often aren't small.

I've seen other 64-bit RISC setups (just assuming ARM64
is going to be similar: I've only seen the overview slides,
not the actual instruction encoding - is it public yet?)
and the address generation is often disgusting.

Linus