>>> On 30.11.16 at 14:45, <daniel.ki...@oracle.com> wrote: > On Fri, Nov 25, 2016 at 12:50:55AM -0700, Jan Beulich wrote: >> >>> On 24.11.16 at 22:44, <daniel.ki...@oracle.com> wrote: >> > On Thu, Nov 24, 2016 at 04:08:12AM -0700, Jan Beulich wrote: >> >> >>> On 23.11.16 at 19:52, <andrew.coop...@citrix.com> wrote: >> >> > Always use add/sub 1 in preference to inc and dec. They are the same >> >> > length to encode in 64bit, and avoids a pipeline stall from a merge of >> >> > the eflags register. >> >> >> >> What you say regarding length not true - add/sub need to encode >> >> the immediate somewhere (even if the operand was a register, >> >> inc/dec would still be smaller than add/sub, just not by as much as >> >> in 32-bit code). And the pipeline stall, afaik, affects only rather old >> >> processors. >> > >> > Intel 64 and IA-32 Architectures Optimization Reference Manual, section >> > 3.5.1.1, Use of the INC and DEC Instructions says nothing about exceptions. >> >> Which by itself is suspicious, as the dependency issue had been >> introduced only in (iirc) Pentium4. And anyway, this is a general > > Hmmm... Interesting... It looks that INC/DEC behavior has not changed since > the beginning (why it would change? It would not make sense).
Please properly disambiguate "behavior": Architectural behavior of course can't change. Performance, otoh, has changed many times. And the resource dependency issue did appear only once the pipelining of instructions was sophisticated enough, but not good enough yet to track (as a dependency) EFLAGS.CF separately from the other arithmetic result flags. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
