Linus Torvalds (torvalds@linux-foundation.org) on 12/20/11 wrote:
---------------------------
>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.

So because I don't agree with you that it's "not at all unreasonable" I must be ignoring you, right? Maybe it'd be more reasonable if the simple case were one uop. Like usual, provide some numbers about usage of complex address modes (ie, more complex than ARM's) and we can talk. Just saying over and over again how much of an advantage it has is is not convincing me.

>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.
>

Needs more data and less you simply calling it "broken." For something to be the general case I think it needs to at least qualify for over half of all usage, so please justify that.

>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.

ARM's are 12-bits, add or subtract (so you can bias a pointer and hit it both ways).

ARM64 makes the reasonable choice to pre-multiply offset immediates, giving you 2-3 more bits than you'd have otherwise.

>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).

By few enough people you mean few enough compilers?

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

ARM and ARM64 have PC-relative addressing too, but I suppose you'll consider it worthless for its small immediate offsets.

I want to see data on immediate requirements. In typical code immediates will often be used for accessing fields of a struct or object. So for them to be too small the object needs to be too big. While I'm sure this is often the case, it really needs to be too big between a lot of fields, because otherwise one displacement into the struct is going to give you access to a bunch of fields.

>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

YES, the instruction information is public, I've said so multiple times now, I asked you to please go read it before you make more guesses about it (see infocenter.arm.com and register for silver). I can e-mail it to you if you really won't do that.

Seriously though, I wish you'd present more data or at least more thorough arguments for why you feel as strongly as you do about all this, and less emphasis on pejoratives.