Daman

IMHO you are not right here, breakpoint checking has to be present in the release [firmware] build - this is the one that is published, without breakpoints you would not be able to debug the application (from Visual Studio). Perhaps the overhead should only take place when a debugger is attached (if it is not done so already).

I would be interested in you measurement results of a 'RTM' build (compiled with /p:Flavor=RTM option) that has debugging disabled (and "some CLR diagnostic functionality may be eliminated").

Below are images form my logic analyzer screen shots. The code is below the images.

Three runs are shown here:

First run is with release code:
It takes 51.9 uS to toggle the output D1
It takes 59.6 uS to toggle the output D1 with the line k=i; in the middle.
So takes ~7.7 uS to execute code k=i;

Second run is debug no breakpoint set:
It takes 53.4 uS to toggle the output D1
It takes 60.9 uS to toggle the output D1 with the line k=i; in the middle.
So takes ~7.5 uS to execute code k=i;

Third run is debug code with break point on line k=0;
It takes 83.9 uS to toggle the output D1
It takes 103.9 uS to toggle the output D1 with the line k=i; in the middle.
So takes ~20.0 uS to execute code k=i;








public static void Main()
{

bool ledState = false;
OutputPort A1 = new OutputPort(Pins.GPIO_PIN_D1, false);
OutputPort led = new OutputPort(Pins.ONBOARD_LED, ledState);

int i;
int k=0;
for (i = 0; i < 1000; i++)
{

ledState = !ledState;
led.Write(ledState);

A1.Write(true);
A1.Write(false);
A1.Write(true);
k = i;
A1.Write(false);
Thread.Sleep(2000);
k = k + 1;

}
i = k;

}

Well, his code attempts to measure that overhead and subtract it from the calculated times. (this is the reason for the magic constant 2134 in his code). My approach for hiding that overhead (and also the loop overhead) was to run the instruction many times.

Not sure what the compiler did with your code. Since k is not used later on the right hand side of an expression the compiler my have optimized out the assigment. It also my optimize out the the redundent assigment. I have to go to an appoitment right now but will try this myself later.

Question to Mark - How do you view the CLI assembly code?

Thanks all,
Bill

...
PS: can you say what FPGA prototyping board you are using? That sounds like an interesting project.

It is based on the Altera Cyclone II family.

EP2C5T144 Altera CycloneII FPGA mini Development Board

I got the following USB Blaster clone

Mini Altera FPGA CPLD USB Blaster programmer JTAG

You can find a numbe of people selling similar items on eBay. These just happen to be the vendors I used. The board and blaster took about a week to arrive from Hong Kong.

Alter offers a free web edtion of Quartus II (compiler with a number of other tools including SignalTap II Logic Analyzer)

Alter now also provides a free starter edition of ModelSim

Breadboarding is not my favorite passtime. Programming glue logic in an FPGA is more fun then wiring discrete logic.

Thank you all for you timely responses.

I understand that the code is compiled into CLI that is then interperted by the CLR and that MF does not use JIT and the instructions are always interperted.

But execution still seems order of magnitude slower then I would expect. So here is a code snipet:

long ticksPerMicroSec = TimeSpan.TicksPerMillisecond / 1000; //1000 uS = 1 mS

now = DateTime.Now.Ticks;
later = DateTime.Now.Ticks;
elapsedTime = (later - now);
Debug.Print("Tick Count with no operations = " + elapsedTime + " ticks");

now = DateTime.Now.Ticks;
i = i % count;
f = (byte) ((sum / count) / 10);
k = 0;
later = DateTime.Now.Ticks;
elapsedTime = (later - now - 2134) / ticksPerMicroSec; //find elapsed tick count - count with no operations
Debug.Print("Execution time minus ticks with no operation = " + elapsedTime + "uS");
now = DateTime.Now.Ticks;
k = 0;
later = DateTime.Now.Ticks;
elapsedTime = (later - now - 2134) / ticksPerMicroSec;
Debug.Print("Execution time minus ticks with no operation = " + elapsedTime + "uS");

And here the print out form the debug window.

Tick Count with no operations = 2134 ticks
Execution time minus ticks with no operation = 234uS
Execution time minus ticks with no operation = 42uS

42uS to execute the statment k=0;???

That is over 1000 machine instructions! It does not seem like the CLR would have that much overhead.

Can anyone verify this timing?

I still think I have some configuration setting incorrectly.