Benchmark Questions

In reverse order of your reply.
It is, of course, possible to use a microcontroller where a microprocessor would be the right choice, but why benchmark the wrong choice.
This is exactly the point of the exercise. Yes, if you are are bit diddling, the 8051 has few equals. If you need more data handling power move to the ARM. But in between is a large gray area. With similar size devices, the cost difference is nothing. So make some measurements to help decide which device to select.

As far as benchmarking "optimization" there is no way any "optimizer" can beat well thought out code. With an 8 bit processor you lose more by using an int where a char would do than ANY optimizer can recover.
I agree again. On an eight bit device, the unsigned char data type is the most efficient data type. You can't always limit to byte compares. A 10 bit or 12 bit A/D just doesn't fit. Even an 8 bit A/D that can output a negative sign bit will load a vendor specific LIb routine to do a signed compare. So few programs can be limited to just unsigned char manipulation.
Also, on larger programs, I have a real hard time believing you can optimize better than some Keil compiler/linkers. On smaller programs, yep. Probably all you will get is some const folding and peephole which can be done away with good coding.
As far as rand() goes, I can beat any benchmark, just by using an algorithm that is fast while even more pseudo that the other guys pseudo.
Yes,the LCM was first introduced by Lehman in 1951 and the ACM was the favorite rand function CS profs would assign their students in the 1980s. But the vendors have written good general purpose rand functions for us. We don't need to waste time optimizing a rand function when most of the time we simply mean some arbitary number rather than a random number.
How well/fast does the vendor specific rand function? Again we can do a simple measurement.
interrupt latency is tough to measure.
Yes very difficult to measure accurately. But we can compare compliers/chips with a simple standard. Most data manuals will give the hardware latency if we need to attempt to calculate the last nSec. Frankly, I don't want to design that close to a margin but I would like to compare compiler/device operation.
Thanks again for the discussion Erik. Whether we agree or not, a discussion makes us review our options AND some of our old text books.
Bradfrod

In reverse order of your reply.
It is, of course, possible to use a microcontroller where a microprocessor would be the right choice, but why benchmark the wrong choice.
This is exactly the point of the exercise. Yes, if you are are bit diddling, the 8051 has few equals. If you need more data handling power move to the ARM. But in between is a large gray area. With similar size devices, the cost difference is nothing. So make some measurements to help decide which device to select.

As far as benchmarking "optimization" there is no way any "optimizer" can beat well thought out code. With an 8 bit processor you lose more by using an int where a char would do than ANY optimizer can recover.
I agree again. On an eight bit device, the unsigned char data type is the most efficient data type. You can't always limit to byte compares. A 10 bit or 12 bit A/D just doesn't fit. Even an 8 bit A/D that can output a negative sign bit will load a vendor specific LIb routine to do a signed compare. So few programs can be limited to just unsigned char manipulation.
Also, on larger programs, I have a real hard time believing you can optimize better than some Keil compiler/linkers. On smaller programs, yep. Probably all you will get is some const folding and peephole which can be done away with good coding.
As far as rand() goes, I can beat any benchmark, just by using an algorithm that is fast while even more pseudo that the other guys pseudo.
Yes,the LCM was first introduced by Lehman in 1951 and the ACM was the favorite rand function CS profs would assign their students in the 1980s. But the vendors have written good general purpose rand functions for us. We don't need to waste time optimizing a rand function when most of the time we simply mean some arbitary number rather than a random number.
How well/fast does the vendor specific rand function? Again we can do a simple measurement.
interrupt latency is tough to measure.
Yes very difficult to measure accurately. But we can compare compliers/chips with a simple standard. Most data manuals will give the hardware latency if we need to attempt to calculate the last nSec. Frankly, I don't want to design that close to a margin but I would like to compare compiler/device operation.
Thanks again for the discussion Erik. Whether we agree or not, a discussion makes us review our options AND some of our old text books.
Bradfrod

With similar size devices, the cost difference is nothing. So make some measurements to help decide which device to select.
That is disappearing. You can get an ARM for less than 7 bucks qty 1 and looking at DigiKey the cheapest "full" '51 is 6 bucks qty 1. NO, I did not compare features but the price range is the same.

Erik