Xref: utzoo comp.lang.c++:2222 comp.lang.c:14612 comp.lang.forth:736 comp.lang.fortran:1606 comp.lang.misc:2322 Path: utzoo!utgpu!watmath!clyde!mcdchg!motmpl!ron From: ron@motmpl.UUCP (Ron Widell) Newsgroups: comp.lang.c++,comp.lang.c,comp.lang.forth,comp.lang.fortran,comp.lang.misc Subject: Re: Instruction Timing (was: Assembly or ....) Summary: it depends... Message-ID: <1101@motmpl.UUCP> Date: 9 Dec 88 05:29:45 GMT References: <1388@aucs.UUCP> <729@convex.UUCP> <1961@crete.cs.glasgow.ac.uk> <1988Nov29.181235.23628@utzoo.uucp> <960@vsi.COM> Reply-To: ron@motmpl.UUCP (Ron Widell) Organization: Motorola Semiconductor, Minneapolis, MN Lines: 24 In article <960@vsi.COM> friedl@vsi.COM (Stephen J. Friedl) writes: >In article <1988Nov29.181235.23628@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: >> Alas, if you buy your newer faster CPUs from Motorola or Intel, they can't >> tell you how many cycles each instruction takes! > >Why is this? [...] Is it laziness on the vendor's part or are there >good reasons for this? Some of the reasons are cache-hit-rate, alignment (of both instructions and operands), instruction stream mix (and consequent overlap of the execution unit with the bus controller) and operand dependencies (e.g. multiply or divide). While this is hardly an all-inclusive list, you probably get the idea: too many variables. >Stephen J. Friedl 3B2-kind-of-guy friedl@vsi.com -- Ron Widell, Field Applications Eng. |UUCP: motmpl!ron Motorola Semiconductor Products, Inc., |Voice:(612)941-6800 9600 W. 76th St., Suite G | If they *knew* what I was saying, Eden Prairie, Mn. 55344 -3718 | do you think they'd let me say it?