Lpc2000

someone know how many oscillator clock x instruction cycle?
from my measure it's seems about 4 oscillator clock x instruction.
thank's to all

--- In lpc2000@yahoogroups.com, "arturo tramontini" <a.t@t...> wrote:
> 
> someone know how many oscillator clock x instruction cycle?
> from my measure it's seems about 4 oscillator clock x instruction.
> thank's to all

If I remember from my class, the Arm7 is a 3 stage pipelined
processor: Fetch Decode Execute.

So, depending on how the question is interpretated, the answer is
either 3 (latency) or 1 (throughput).

--Peter

Hi Arturo,

your measurement seems very much in line with what ARM is quoting for
the ARM7 core. The core can run in the average over all programs they
tested with 1.9 clocks per instruction. This is not LPC2000 specific,
rather ARM7 core specific. As side information, the ARM9 core is
quoted at 1.3 clocks / instruction, so inherently faster while running
at the same frequency. 

Now to the possible difference between the chips you might be testing.
A device running 0 wait states will be very close to what you
measured. If you would use for example external flash memory (or
internal) and have to insert wait states, you will see this factor
degrading depending on the number of wait states.

Another topic you would want to consider is whether you execute ARM
code or Thumb code. You will execute the same number of ARM or Thumb
instructions during a given time on the LPC2000 but you might find
that other devices with narrower busses will give you more
instructions in Thumb mode than in ARM mode. What does this mean?
Thumb mode has the benefit of reducing your code size by approx. 30
percent, or in numbers, 7 Thumb instructions replace 5 ARM instructions. 

It takes approx 10 clock cycles to execute the 5 ARM instructions on a
LPC2000 but it takes almost 14 cycles to execute the Thumb
instructions performing the same task. 

Your question if related to performance could then be rephrased to how
many clock cycles to perform a task in ARM and Thumb mode and now we
are exactly there what a benchmark is.  It is not as easy as how many
clock cycles per instruction but more how much time to perform a given
task with lots of parameters if comparing different devices. 

Accept my apologies for this lengthy e-mail but I could not resist ;-)

Cheers, Bob


--- In lpc2000@yahoogroups.com, "arturo tramontini" <a.t@t...> wrote:

> 
> someone know how many oscillator clock x instruction cycle?
> from my measure it's seems about 4 oscillator clock x instruction.
> thank's to all

I'm seeing slightly different numbers.  
Yesterday I put two lines of code in my C program.
Line 1 was  IOSET0 = xxxx   to set an IO pin.
Line 2 wss  IOCLR0 = xxxx   to clear the same pin.,
This compiled to a total of 8 lines of assemble code using IAR.
When executed, the IO pin stayed high for 2 uS with a 24MHz clock.  
This implies the 8 instruction took over 48 clock ticks.  I was in 
the THUMB mode, and I'll try it again in the ARM mode.  
John

--- In lpc2000@yahoogroups.com, "lpc2100_fan" <lpc2100_fan@y...> 
wrote:
> 
> Hi Arturo,
> 
> your measurement seems very much in line with what ARM is quoting 
for
> the ARM7 core. The core can run in the average over all programs 
they
> tested with 1.9 clocks per instruction. This is not LPC2000 
specific,
> rather ARM7 core specific. As side information, the ARM9 core is
> quoted at 1.3 clocks / instruction, so inherently faster while 
running
> at the same frequency. 
> 
> Now to the possible difference between the chips you might be 
testing.
> A device running 0 wait states will be very close to what you
> measured. If you would use for example external flash memory (or
> internal) and have to insert wait states, you will see this factor
> degrading depending on the number of wait states.
> 
> Another topic you would want to consider is whether you execute ARM
> code or Thumb code. You will execute the same number of ARM or 
Thumb
> instructions during a given time on the LPC2000 but you might find
> that other devices with narrower busses will give you more
> instructions in Thumb mode than in ARM mode. What does this mean?
> Thumb mode has the benefit of reducing your code size by approx. 30
> percent, or in numbers, 7 Thumb instructions replace 5 ARM 
instructions. 
> 
> It takes approx 10 clock cycles to execute the 5 ARM instructions 
on a
> LPC2000 but it takes almost 14 cycles to execute the Thumb
> instructions performing the same task. 
> 
> Your question if related to performance could then be rephrased to 
how
> many clock cycles to perform a task in ARM and Thumb mode and now 
we
> are exactly there what a benchmark is.  It is not as easy as how 
many
> clock cycles per instruction but more how much time to perform a 
given
> task with lots of parameters if comparing different devices. 
> 
> Accept my apologies for this lengthy e-mail but I could not 
resist ;-)
> 
> Cheers, Bob
> 
> 
> --- In lpc2000@yahoogroups.com, "arturo tramontini" <a.t@t...> 
wrote:
> > 
> > someone know how many oscillator clock x instruction cycle?
> > from my measure it's seems about 4 oscillator clock x 
instruction.
> > thank's to all

At 10:21 PM 3/17/05 +0000, johnsonnenberg99 wrote:
>I'm seeing slightly different numbers.
>Yesterday I put two lines of code in my C program.
>Line 1 was  IOSET0 = xxxx   to set an IO pin.
>Line 2 wss  IOCLR0 = xxxx   to clear the same pin.,
>This compiled to a total of 8 lines of assemble code using IAR.
>When executed, the IO pin stayed high for 2 uS with a 24MHz clock.
>This implies the 8 instruction took over 48 clock ticks.  I was in
>the THUMB mode, and I'll try it again in the ARM mode.

I believe you are timing I/O speed not instruction speed.  Take a search 
back through the history of the group.  In particular there was some 
discussion on this in the first month or two of the groups existence.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

John,

as Robert already mentioned your test includes the delays that are by
design in the path to the I/O pads if the I/O is connected to the APB
(Philips calls it VPB, same thing). You do not just measure execution
speed of code / instructions. 
Please use a program, lets say >> 1kB, look at the size and the
executed code and the average 1.9 should be very close to what you
will see. This number, 1.9,  is actually from ARM presentations I saw
at the ARM Developers Forum.

Bob

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote:
> At 10:21 PM 3/17/05 +0000, johnsonnenberg99 wrote:
> >I'm seeing slightly different numbers.
> >Yesterday I put two lines of code in my C program.
> >Line 1 was  IOSET0 = xxxx   to set an IO pin.
> >Line 2 wss  IOCLR0 = xxxx   to clear the same pin.,
> >This compiled to a total of 8 lines of assemble code using IAR.
> >When executed, the IO pin stayed high for 2 uS with a 24MHz clock.
> >This implies the 8 instruction took over 48 clock ticks.  I was in
> >the THUMB mode, and I'll try it again in the ARM mode.
> 
> I believe you are timing I/O speed not instruction speed.  Take a
search 
> back through the history of the group.  In particular there was some 
> discussion on this in the first month or two of the groups existence.
> 
> Robert
> 
> " 'Freedom' has no meaning of itself.  There are always
restrictions,   be 
> they legal, genetic, or physical.  If you don't believe me, try to
chew a 
> radio signal. "  -- Kelvin Throop, III
> http://www.aeolusdevelopment.com/

> I'm seeing slightly different numbers.
> Yesterday I put two lines of code in my C program.
> Line 1 was  IOSET0 = xxxx   to set an IO pin.
> Line 2 wss  IOCLR0 = xxxx   to clear the same pin.,
> This compiled to a total of 8 lines of assemble code using IAR.
> When executed, the IO pin stayed high for 2 uS with a 24MHz clock.
> This implies the 8 instruction took over 48 clock ticks.  I was in
> the THUMB mode, and I'll try it again in the ARM mode.
> John

What you should do is inserting instructions BETWEEN these lines and see the
timing DIFFERENCE, then divide that by the number of (assembly)
instructions. That way you avoid measuring the delay that is incurred by the
slow I/O bus timing.

Regards,
Arie de Muynck