Embench-IoT 2.0 Weekly Update

[Konrad Moron]

Hi all,

this week's update is rather short:

Progress since last week:

• Added depthconv statistics and description to the paper
• Updated paper for other code changes (size calculation)
  
• Ordered baseline board: STM32F4-DISC1
  

To-do:

• Compute baseline results for the reference board.

If there's anything else you believe we should change for Embench-IoT 2.0 or the paper please send an E-Mail or attend the weekly engineering meeting (Wednesday 4 PM GMT).

Kind regards,

Konrad

[Adam Krolnik]

Hello;

Any possibility of replacing use of the keyword "volatile" in the benchmarks with memory references instead ? 

It appears the keyword was artificially added, by the benchmark team, to prevent compilers from optimizing away parts of the benchmark.

Replacing it with some memory references (E.g.   mem[x] = (used to be volatile variable reference) ...   (used to be volatile variable) = mem[x])
preserves the benchmark team's desire to retain the functionality, but also allows the compiler to work with the code, doing its standard optimizations.

programs having volatile include : libnsichneu, mont64, picojpeg, sglib-combined,  slre,  ud

   Thx 

[Konrad Moron]

Hi,

I think it's a good idea to remove volatile variables, but it would require calculating something in each benchmark that is later verifiable and necessitates execution.

Maybe I didn't quite understand what you mean by memory references, but if they are just pointers to objects with extern linkage, I belive the compiler can still optimize away all writes.

(If I understand the standard correctly, all that is guaranteed about extern objects is that reads produce the value of the last write in the same program).

All the best,

Konrad