STM Compiler

Hello, I'd like to welcome you to our STM portion of the whatif site.

As Intel is moving towards multi core processors, we are committed to provide development tools to help programmers exploit the parallelism available in these processors.

We view transactional memory as a part of the solution.

Here we offer a prototype implementation of our C/C++ compiler product with the addition of transactional programming constructs. (I will refer to it as a transactional compiler).

While a lot of work has been done in the area of transactional memory, we expect that yet more work is needed. Therefore, we are not providing a compiler with transactional programming as a product. Instead, we are making it available through our whatif site to encourage experimentations and to seek feedback on our choices.

The compiler available here is a result of collaboration between Intel's researchers and product teams. Practitioners in the area of transactional programming are well aware of the many contributions of Intel's researchers, and these are the researchers who participated in developing this compiler. Many professional programmers are also aware of Intel's development tools, the C/C++ compiler supporting OpenMP, Intel performance library and others. Members of this product team participated as well in the development of this compiler.

The current compiler provides the basic construct you would expect to express a transaction. Our syntax for a transaction is __tm_atomic[1] statement;'. Our implementation allows function calls within transactions. As we work in the IA32 eco system, we had two goals, that are particular to this domain: maintain the programmer's ability to control the size of the application, and allow them to leverage existing investments in IA32 SW packages. To that end, we provide facilities to express that a function will only be called within transactions, and alternatively to express that a function will be called both inside and outside of transactions. In the latter case, the compiler will generate two different translations of those functions. One that includes the transactional barriers for loads and stores, and one that does not. We also allow calling of functions that are not part of the current compilation and that were not compiled with transactional semantics. That allows a SW developer to use exciting packages where the source code is not available for recompilation. The addition to these constructs to the language made it harder to add some other constructs, mainly the "retry" and "abort" statements. While some would expect these to be a part of a transactional compiler, our initial view is that adding all of these constructs would results in a complex language. We therefore chose to not provide support for the retry and abort statements. We are seeking feedback on these, as well as some other choices.

Our goal in making available this early version of our transactional compiler is to encourage use of transactional programming and provide feedback on the usability of our language constructs. The implementation of these constructs was shown to provide acceptable performance on some programs we used internally. However, we do not expect it to perform consistently and we expect that some will see reduced performance when compared to other implementation alternatives. We chose to make the compiler available early rather than wait for a high performance implementation, which we hope to provide at a later time.

Thanks for your interest in our prototype compiler.

Robert Geva.

[1] We expect that once transactions are integrated into the C/C++ languages, the keywords will be friendlier. For the prototype implementation, our concern was to minimize the risk of name clashing with program variables.

For more complete information about compiler optimizations, see our Optimization Notice.