Look up two's compliment arithmetic. There is no physical or mathematical difference between a signed or an unsigned add/sub for a fixed number of bits. The only difference is the interpretation of the results and what constitutes an overflow.
If the operands differ in length then signed/unsigned affects how the inputs are formed (either duplicates the msb across all higher bits, or it doesn't) as in the immediate variants which are all signed. But since the register variants are all 32-bit operands then there is no difference between signed or unsigned add/sub.
e.g. (using 16-bits here to save typing)
unsigned: 1 + 65534 = 65535, signed; 1 + (-2) = -1
In hex they are both: 0x0001 + 0xfffe = 0xffff
unsigned: 65534+65535 = 65533, signed: (-2)+(-1)= -3
In hex they are both: 0xfffe + 0xffff = 0xfffd (the carry to bit 16 is lost).
But obviously the unsigned version has overflowed.
If there was an "Add byte" then it would need a signed/unsigned specifier since 0xff unsigned is 255 and 0xff signed is -1.
IADD/ISUB is a just a "freebie" from a side-effect of the way integer multiply is implemented so as to require no extra silicon. They could be used in integer heavy code for up to 2x the throughput but the cost of changing mode is so high it's not really useful if the code does any flops.
The pipeline diagram details where the instructions are executed and retired (figure 14), and yes I believe it is one cycle less when using truncate mode. i.e. they will retire in E3 and not E4.
You might find the following posts and static analysis tool of interest. The tool has some bugs (it was really just an extended-weekend hack) and is hard-coded to the rounding timing but it's enough to help understand what's going on. My labelling of the pipleine stages might be out by one because i wasn't sure on which edge specific events occur but it doesn't really make any difference to the relationships.
http://a-hackers-craic.blogspot.com.au/ ... -tool.htmlhttp://a-hackers-craic.blogspot.com.au/ ... round.htmlhttp://www.users.on.net/~notzed/software/ezetool.htmlI did a lot of testing with snippets of code on the hardware to confirm the numbers because whilst the tables are accurate and mostly complete there are some fiddly details missing and I wasn't sure how to interpret them either. Andreas also kindly provided further internal details in some posts here (in the assembly section, i think) which clarified some otherwise odd results I saw with the dual-issue rates (the dependencies on all load/stores are for dword register pairs for example).