Emulated clock speeds

[Adrian Johnstone]

I'm doing a performance analysis of some code using the ARM6 PIE board and the
Armulator soft emulator on a SUN. When I run my code on the PIE board (real
hardware) I get exactly the timings I expect. When I run it on the Armulator
I get times reported from the ANSI C clock() routine that are about a factor
20 out, which leads me to believe that the Armulator is pretending to be a 1MHz
processor with no wait states. Can anybody confirm this?

Any details on the emulated ANSI C library timer routines would be of interest.

Adrian

Adrian Johnstone: usually adr...@dcs.rhbnc.ac.uk but until Feb 28 john...@imec.be

[Michael Williams]

I'm moving this thread over to c.s.arm where it belongs.

In article <1995Feb24.1...@imec.be> john...@imec.be (Adrian Johnstone) writes:
>I'm doing a performance analysis of some code using the ARM6 PIE board and the
>Armulator soft emulator on a SUN. When I run my code on the PIE board (real
>hardware) I get exactly the timings I expect. When I run it on the Armulator
>I get times reported from the ANSI C clock() routine that are about a factor
>20 out, which leads me to believe that the Armulator is pretending to be a 1MHz
>processor with no wait states. Can anybody confirm this?

The implementation of SWI_Clock in the ARMulator does just call the
Unix clock() function.

Check out the file "armos.c" (which I think is supplied as source).
This is where the basic SWI_Clock implementation lives. You could
replace this implementation with something that uses the N, S, I and C
cycle counts (no such thing as a T cycle - pah!) to generate a
simulated clock - e.g.

case SWI_Clock:
state->Reg[0]=(state->NumScycles + state->NumNcycles*2 +
state->NumIcycles + state->NumCcycles)/120000;
return TRUE;

(Which sort of gives a reasonable model of an ARM on 12MHz DRAM,
where N cycles take two memory ticks.)

To be like a PIE card you might need something like:

case SWI_Clock:
state->Reg[0]=(state->NumScycles*2 + state->NumNcycles*3 +
state->NumIcycles + state->NumCcycles*2)/200000;
return TRUE;

(This isn't correct for older PIE cards, where writes took longer than reads.)

This gives results that are a fraction faster than the real PIE card, because
the real card has interrupts running that take time.

(SWI_Clock returns a centi-second counter value.)

>Any details on the emulated ANSI C library timer routines would be of interest.

Since the implementation of clock() in the ARM library calls
SWI_Clock, this should be sufficient.

If you don't want to have to rebuild the toolkit then you can use the
debugger pseudo-variable(s) $statistics (and $statistics_inc) to read
the number of cycles taken by a program - assuming that your memory
model gathers this information (the supplied ones do).

Generating this kind of timing information is one of the things that
may be addressed in future releases of the toolkit.

Mike.
____________________________________________________________________________
\ x / Michael Williams Advanced RISC Machines Limited
|\/|\/\ mwil...@armltd.co.uk Fulbourn Road, Cambridge, CB1 4JN, UK
| |(__)"I might well think that Matti, ARM Ltd. couldn't possibly comment."

[Thilo Manske]

john...@imec.be (Adrian Johnstone) writes:

>I'm doing a performance analysis of some code using the ARM6 PIE board and the
>Armulator soft emulator on a SUN. When I run my code on the PIE board (real
>hardware) I get exactly the timings I expect. When I run it on the Armulator
>I get times reported from the ANSI C clock() routine that are about a factor
>20 out, which leads me to believe that the Armulator is pretending to be a 1MHz

^^^^
No one would run an ARM on such low clock-rates (exept for powersaving). So why
simulate it?

>processor with no wait states. Can anybody confirm this?

I suppose, the reason is simply that the software emulation is about 20
times slower then the real ARM6 and that clock() reads the real time, not
any simulated time. Perhaps you should try to run the Armulater on different platforms,
if the timings differ, I am right (or not?)

>Any details on the emulated ANSI C library timer routines would be of interest.

This might be helpful.

> Adrian
>
>Adrian Johnstone: usually adr...@dcs.rhbnc.ac.uk but until Feb 28 john...@imec.be

--
------------------------------------------------------------------------------
Thilo....@Informatik.Uni-Oldenburg.DE
RiscPC600 ARM610 @33MHz 12+1MB RAM @16MHz 420MB IDE-HD RO3.50D
BBC A3000 ARM 2 @ 8MHz 4MB RAM @ 8MHz 250MB IDE-HD RO3.19 GU

I know which side of the soldering iron is the hot one...
*OUCH*
Sorri four may bed English.