FAQ

  
    This page is no longer up-to-date. Please go to http://mbeddr.com/faq
  

Why are you doing this?

We believe that, while C is a powerful and efficient language, it does not provide adequate support for defining higher level abstractions. We feel that language extension is the way to introduce abstractions relevant to embedded
software development into C. Initial experience with mbeddr in a real world project confirms this belief.

What are some of the available extensions to C?

Examples include components (incl. interfaces with pre- and postconditions, ports and connectors), data types with physical units (as in 300 km/h) and state machines. Many smaller but very useful extensions, such as counters and decision tables are also supported. Support for cross-cutting concerns such as requirements tracing and product line variability are available as well. Additional extensions will be inspired by our application partners SICK and BMW Car IT, and will specifically target use cases encountered in their domains.

How do you position this in comparison with other approaches?

We perceive the embedded development world as being made up of two camps. One camp uses bare-bones C to develop highly efficient, low level code. The other camp uses tools such as Matlab/Simulink, Ascet or similar tools to “model and synthsize” executable software. We position mbeddr in the middle between the two: you still primarily write code, but with meaningful, customizable abstractions.

Can’t all this be done with libraries?

Libraries don’t support custom syntax, static error checking and efficient translation. Language extension can provide all of these. However, libraries of course still play an important role, we don’t claim that language extension is the solution to all problems. Language extension also makes programs accessible for meaningful static analysis. Support for model checking or constraint solving is an important ingredient of the approach.

… or with macros?

Macros can provide some of the same efficiency (because they are translated statically). However, you cannot implement context-specific optimizations, and macros do not come with support for the type system and the IDE. Experience tells that using macros a lot turns your software into a maintenance nightmare.

Are you implementing all of C?

We are implementing essentially all of C, here are some of the few differences. There are various reasons for these differences. For some of them, we feel we are compensating weaknesses of C (int vs. boolean). For others, we exploit the capabilities of MPS and the generative approach (modules). Yet others just make our lives as implementers more pleasant (arrays and pointers after type instead of variable name). However, we are generating ANSI C99, so the generated code is compatible with existing target systems.

What about C++?

We have started implementing the basics of C++. The challenge with C++ is the type system for templates. We are not yet sure how far we will be going there; instead of using template meta programming, mbeddr users can use language extensions to achieve many of the same effects in a more elegant and robust way.

Are you going to write your own compiler?

No. MPS works by progressively reducing higher abstractions to lower abstractions, leading to ANSI C99 at the end of the chain. That C code can be compiled with existing compilers. We use GCC currently, but others can be plugged in.

Do you support debugging?

We have a debugger working for C. We have proven its extensibility by building debuggers for components and state machines as well. Once completely finished, we will provide a integrated debugging approach for C and its domain-specific extensions.

How can you build C without a preprocessor?

The C preprocessor is (mis)used for a number of different things in C, including definition of constants, visibility management (header files) and expressing variants of programs. We provide first class support for these use cases in our language. For example, a module system with explicit visibility control is provided. For expressing code variants, we provide first class support for variant management, incl. static verification of correctness (see this short paper). Of course we generate C code that makes use of the preprocessor for some of these use cases, but we don’t expose it to users.

What about legacy code?

An importer for header files is available. We are currently working on an importer for all of C that deals with preprocessor variability (#ifdef) correctly, as far as that is possible.

Is it Open Source?

mbeddr is open source; you can get it from here. It is licensed under the Eclipse Public License.

Why don’t you use Xtext?

While Xtext is a very good and widely used language workbench, it is also limited in many ways, particularly regarding language modularization and composition as well as non-textual notations. MPS is a much more productive environment for working with lots of modular languages.

How about Eclipse Support?

As of now, the system is built on MPS and MPS is not integrated with Eclipse. However, there is an EMF export for language meta models and programs. JetBrains has also agreed to provide an Eclipse-integrated version of MPS in 2013. Stay tuned for more news in this regard.

How about Graphical Notations?

Currently all notations used by mbeddr are textual, tabular or symbolic because MPS does not yet support graphical notations. However, MPS will start providing support for graphical notations in 2013, and we will use them for state machines and components as soon as graphical notations become available. In the meantime, mbeddr already supports automatically-generated, read-only visualizations for various extensions based on graphviz, and a viewer that is directly integrated into MPS and provides drill-down support (double-click an element in the view, and the editor opens for this element).

Is mbeddr ready for prime time?

A number of prototypical systems have been built, and a first commercial project is currently being developed. As of Jan 2013, we are also starting a larger case study with our project partner BMW Car IT. mbeddr is usable, scales well and is stable enough. Some usability challenges with MPS still remain, but they are scheduled to be fixed with version 3.0 (Q1 2013). In other words: yes, now is the time to seriously investigate mbeddr.

 

4 thoughts on “FAQ

  1. Pingback: FAQ added «

  2. Pingback: Pengembangan Embedded Modular dengan mbeddr C | LinuxBox.Web.ID

  3. A concurrency abstraction is currently missing in mbeddr.
    Will this be added/addressed in the future
    (or is this considered as a component implementation detail)?

    • We currently do not have anything on the roadmap. But of course that would be an extremely useful extension and will be added as soon as we (or our users) see a need for it.

      Sorry for answering the comment only now — WordPress didn’t send out a notification of your comment😦

      Markus

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s