anonymous (no@spam.com) on 4/21/12 wrote:
---------------------------
>The BD AGUs can't actually handle INC/DEC.
>
>The current optimization manual finally shows that.
>
>And it's trivial to test it yourself. :)

The current optimization manual also doesn't mention anything about the AG units actually being used to generate addresses. If we go strictly by them it looks like they're only used in more complex forms of lea and calls, which is of course silly.

Others have claimed that they've ran tests that confirm inc/inc + add/add or somesuch can be done in one cycle. I don't know if 4x inc can be done in one cycle; it's possible that the EX units can't handle it entirely.

I don't have one so I can't test myself - do you/have you?

With the information we have the following makes sense:

1) Can read at least one register, since otherwise it'd be useless for address generation
2) Can write at least one register, for inc/dec
3) Can perform adds, for effective address generation in complex lea and calls
4) Can't have immediate operands?

It's possible that it also can't modify the carry flag (inc/dec doesn't), but xadd does (same as add) and bextr sets it to 0. bextr also accesses two registers, but the second access only has to be 16-bits. xadd requires two writes instead of 1, and the SOG claims it's single cycle.

These are really weird thing to optimize for. xadd is mainly just useful for synchronization and thus not that performance sensitive. bextr with a register control would almost never be used in real code - extract fields are usually constant, and if you actually did need a variable one and were willing to use AMD only code you'd probably use XOP instead.

And if you can do xadd there's no reason why you can't do add, unless you must modify the source register (inc/dec follow this as well, but bextr doesn't).

The whole thing is just really confusing. Sometimes I wonder if someone in AMD is making that section of the SOG wrong on purpose.