Skip to content

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 :

Image info

EM•Mark Design Hierarchy

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.

Image info

EM•Mark Image Size

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 !!!   🌝   💻