EM•Mark program size – TI CC2340R5
With its tiny code → tiny chips mantra capturing the essence of the EM programming language, it should come as no surprise that our first set of EM•Mark results will focus on program size – comparing legacy CoreMark (written in C) with its EM language counterpart.
High(er)-level design
EM Platform Documentation recently added an article entitled CoreMark Reimagined , which explains the transformation of a "typical" base of C code into a higher-level rendition written in EM. Details aside, the following diagram summarizes the design of EM•Mark :
the blue boxes [ActiveRunnerP, CoreBench] represent concrete EM modules, while the green boxes [BenchI, ComparatorI] correspond to abstract EM interfaces
different concrete modules might implement the same abstract interface – enabling clients to use these modules in a "plug-compatible" (polymorphic) manner
the blue arrows depict a direct coupling between module suppliers and their clients – for example, ActiveRunnerP explicitly imports CoreBench and calls its public functions
the red arrows, on the other hand, depict the use of ephemeral EM proxies which decouple module clients and suppliers by introducing a level of indirection
the red gear inside CoreBench indicates the pivotal role played by this module in "wiring together" many of the plug-compatible components of this design
Take a quick peek at the legacy core_list_init function defined in the core_list_join.c source file and compare it with its setup counterpart found here in ListBench.em .
Setting aside the more "modern" look-and-feel of the EM language, ListBench.setup in fact contains less runtime code than its C counterpart. How so – because EM•Mark leverages the WPO + ACO optimizations highlighted in this earlier Blogging EM post.
But doesn't EM•Mark cheat here ???
Viewing CoreMark as a "black-box", the benchmark receives initialized data structures as input and produces checksums as output – transforming input to output by iteratively executing a prescribed set of algorithms. The time required to run N iterations of the benchmark ultimately determines the CoreMark score.
The benchmark defines a known set of seed values used when initializing as well as manipulating the input data structures. To prevent overly aggressive optimization by the compiler, CoreMark mandates that source code declare these seeds as volatile C variables with values only known at runtime; EM•Mark follows suit.
But since initializing the input data lies outside of the benchmark's measurement window, EM•Mark leverages the full power of EM to minimize the run-time overhead of (say) ListBench.setup by migrating some of the legacy core_list_init logic into ListBench.em$construct – which now executes at build-time on your PC.
A novel feature of EM, build-time execution of functions normally relegated to run-time within C plays a critical role in reducing overall program size. EM language config params like ListBench.maxElems – build-time variables, but run-time constants – also allow the backend compiler to further optimize program space and speed.
The envelope, please ...
Using the setup described in our recent EM•Mark Results article, the legacy CoreMark program built with TI's compiler weighs in with the following section sizes for this image:
text (8798) [XO] |
const (3777) [RO] |
data (286) [RW] |
bss (2372) [RW] |
| executable code | initialized constants | initialized variables | zero-initialized variables |
We've explicitly employed the most aggressive optimize-for-space compiler options here; building legacy CoreMark with the most agressive optimize-for-space options, on the other hand, would likely increase overall program size by 2X - 3X .
The following screen-shot reports comparable section sizes for ActiveRunnerP – an EM program (patterned after core_main.c) which iteratively applies a prescribed set of algorithms to a pre-initialized dataset, and then outputs a set of checksums when complete.
While certainly NOT the original intent of CoreMark, its legacy base of C code does provide us with an interesting opportunity to learn more about EM – a higher-level programming language with higher-levels of program performance.
Future blog posts should subtantiate our claim about EM, by reporting additional EM•Mark results in execution time, active power, and energy efficiency .
How can you get involved
dive into CoreMark Reimagined , to learn more about the CoreMark ⇒ EM•Mark re-design
with EM•Mark now available for download, maybe you should now consider Installing EM
try building ActiveRunnerP with different compiler options – or even with different compilers
Happy coding !!! 
