to find execution time

[GIR]

How many CPU cycles
does it take to get information from memory to the CPU?

it takes 1 cycle to get data from the memory to the CPU. in 1 cycle
there are upto 5 R/W operations.

 

[Mark McIntyre]

Uhu, it didn't occure to you that the language C isn't just for 8086
machines...

There's nothing in Dan's post which assumes C is for 8086, in fact
quite the reverse. Whether a chip is capable of caching and whether it
can be enabled/disabled would be entirely platform specific, and hence
outwith the scope of C. To include functionality to support it would
typically be making C /less/ portable.

comp.lang.c sais to me that this group is about the language C... I
think it's kinda ackward that you would automaticly presume that
everybody in here is programming for a 8086 architecture.

It is for C, and it doesn't assume any architecture.

 

[Mark McIntyre]

I think there's coliding views here. You guyz look at it from a
desktop POV where the OS handles alot of the stuff.

No, we look at it from the C point of view, where there /is/ no
desktop and there /is/ no OS.

I'm looking at it
from a system POV where you have to handle alot of stuff yourself and
thus know every little tiny detail of your system.

Then you've left the realm of C, and you're into hardware specific
land. C doesn't deal with this.

 

[Mark McIntyre]

For example if you processor has an XTAL of 1MHz then 1 cycle takes 1
us (microsecond). Just multiply the total amount of cycles needed by
the XTAL and you got your execution time.

Right. And when your app is task-switched out, and a million cycles
pass with it dormant?

Get with the plot there !

 

[Mark McIntyre]

it takes 1 cycle to get data from the memory to the CPU. in 1 cycle
there are upto 5 R/W operations.

On whatever specific hardware you're using. This is however totally
irrelevant to C in general, and not even remotely reliable as a
principle.

And you're the one claiming that others are locked into x86 mode?

 

[Kevin Goodsell]

I think there's coliding views here. You guyz look at it from a
desktop POV where the OS handles alot of the stuff. I'm looking at it
from a system POV where you have to handle alot of stuff yourself and
thus know every little tiny detail of your system.

Because there is alot of interrupting and queuing going on in the
modern day OS the suggested timing via timers or RTC cannot and will
not be accurate. If you want to know how long a certain piece of code
(function, subroutine or method) exactly needs for it to complete it's
duties to only way to really know for sure is to look at it's cycles.

I'm not thinking of the OS at all. I'm thinking of things like wasted
cycles and complicated pipelining. Both of these can (and do) occur
without the OS being involved at all, or even existing. Cycles get
wasted for any number of reasons - memory accesses, dynamic RAM refresh,
interrupts, etc. Pipelining can cause instructions to use *fewer* clock
cycles (at least, that's the observed result). So if a multiply takes 12
cycles, but it happens to come after certain other instructions, it may
appear to finish after 1 or 2 cycles. Or, if the pipeline is flushed for
some reason, it may take the full 12. The original Pentium chip (I'm not
as familiar with newer architectures) could sometimes do two
instructions in the same cycle. All this makes it very difficult to
predict how many cycles even a single instruction will take.

Your suggestion may work for some simpler architectures (like the 8051),
but it is far from being generally useful.

-Kevin

 

[Kevin Goodsell]

it takes 1 cycle to get data from the memory to the CPU. in 1 cycle
there are upto 5 R/W operations.

I'm sorry, but that's completely false on many architectures. My CPU is
running at something like 2.53 GHz. That clock rate would make the RAM
go nuclear. Besides that, how do you define 'memory'? Cache (possibly
multiple levels), main memory, swap space, those are all types of memory
and they all take different amounts of time to access.

The bottom line is that you are either grossly over-simplifying or you
are simply unaware of several of the issues involved. The method you
suggested is only useful in a relatively small number of very simple cases.

-Kevin

 

[Dan Pop]

The bottom line is that you are either grossly over-simplifying or you
are simply unaware of several of the issues involved. The method you
suggested is only useful in a relatively small number of very simple cases.

Which must fullfil *all* these conditions:

1. No form of memory caching.
2. No form of virtual memory.
3. A single execution unit inside the CPU, non-pipelined.
4. If both the CPU and some other piece of hardware try to simultaneously
access the same memory bank, the CPU always wins.
5. A memory access takes a constant and well known number of wait states.

This basically rules out everything more modern than a 286, but there are
plenty of older systems that fail to qualify for one of the above
mentioned reasons or another.

Heck, not even my old ZX-Spectrum qualified, before I extended its RAM
from 16K to 48K (the first 16K of RAM was shared between the CPU and the
graphics hardware and it was the latter which won all access conflicts).

Actually, there was a hack, involving putting the Z80 in IM2 and storing
certain values in the I register, that confused the system and let the
CPU win access conflicts. The result was "snow" on the TV screen.

Dan