Sujet : Re: Decrement And Branch
De : anton (at) *nospam* mips.complang.tuwien.ac.at (Anton Ertl)
Groupes : comp.archDate : 13. Aug 2024, 14:28:07
Autres entêtes
Organisation : Institut fuer Computersprachen, Technische Universitaet Wien
Message-ID : <2024Aug13.152807@mips.complang.tuwien.ac.at>
References : 1
User-Agent : xrn 10.11
Lawrence D'Oliveiro <
ldo@nz.invalid> writes:
The original designers of POWER clearly thought there was a point to
having such instructions; do you agree?
Sure. The question is what it was. Maybe they wanted to look good on
some kernels. In the same vein they also added loads and stores with
update (i.e., autoincrement/decrement addressing), and in one version
of the architecture reference manual I found the warning that these
may be as slow as a separate load and update.
AMD64 has LOOP. I looked at it here several times. Theoretically one
can branch-predict it perfectly, but when I measured that
<
2016Jun16.103617@mips.complang.tuwien.ac.at>
<
2017Mar14.183125@mips.complang.tuwien.ac.at>, I found that they just
use history-based branch prediction for these instructions like
everybody else.
I think that the major reason is that in an OoO CPU the OoO part would
need to move the count to the front end, and either let the front end
wait until that is done, or introduce some mechanism to let the front
end run ahead and, when the count finally becomes available to the
front end, update it to the right value where the front end is now.
Moreover, at least some AMD64 CPUs take more cycles for a LOOP than
for the equivalent "sub; jne" sequence
<
2017Mar15.141411@mips.complang.tuwien.ac.at>
- anton
-- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>