Lessons Learned from building mbeddr

Markus Völter
voelter@acm.org
www.voelter.de
@markusvoelter
Language Engineering
Lessons Learned about
from the
Development
mbeddr of

Health & Medical
AutomoEve
Aerospace
RoboEcs
Finance
Embedded
Government
DOMAINS SoKware Engineering
Requirements Engineering
SpecificaEon and VerificaEon
ImplementaEon and Test
Mixed NotaEons and End User Programming
Informal -> Semiformal -> Formal
Languages + VerificaEon
OptmizaEons, Performance and Concurrency
Fundamentals: Editors, Type Systems, Trafos
User-Friendly IDEs, Tools
Safety and Security
Architecture
Science
Methodology
Language Engineering

Background:
MPS
1
Lessons Learned
about Language
Engineering from the
Development of
mbeddr

Freely
deﬁne
integrate
them
languages and
Language
Workbench (MarEn Fowler, 2004)

powerful
ediEng
tesEng
refactoring
debugging
language deﬁniEon
IDE deﬁniEon
implies
+
groupware
Language

support for
„classical“
programming
„classical“
modeling
and
+
Language
There‘s no diﬀerence!

A Language Workbench –
a tool for deﬁning, composing
and using ecosystems of languages.

[Language Workbench]
+ Refactorings, Find Usages, Syntax Coloring, Debugging, ...
Comprehensive Support for
many aspects of Language DeﬁniEon.

Parsing ProjecEonal EdiEng
[ProjecEonal EdiEng]

Regular Code/Text MathemaEcal
Tables Graphical
SyntacEc Flexibility

L2 L1
Separate Files In One File
Type System
TransformaEon
Constraints

Type System
TransformaEon
Constraints
Syntax
IDE

Language ComposiEon

Language ComposiEon

Background:
mbeddr
2
Lessons Learned
about Language
Development of
mbeddr

An extensible set of integrated languages
for embedded soKware engineering.

Composable extensions, Diverse notaEons

Smart Meter
Measures Voltage and Current
Computes Derived Values
Shows Data on LCD Display
Communicates through Networks
Precision is criEcal for CerEﬁcaEon.
Evolvability is criEcal for it to be a viable business.
An Industrial Case Study
Developed with , a set of domain-
Speciﬁc extensions to C, plus an IDE.

Hardware Architecture
MSP430 F67791
25 MHz
256K Flash ROM
32K RAM
MSP430 F6736
25 MHz
128K Flash ROM
8K RAM
MQTT
UART
RS485
IrDA
DLMS/COSEM
Metrology ApplicaOon Logic

SoKware Architecture
Energy
data
Non-
Volatile
data
Mains frequency
measurement
Instantaneous voltage &
current sampling
RMS voltage & current
calculation
Power & power factor
calculation
Energy and consumption
calculation
Energy data
display
Multi-tariff &
billing periods
support
Magnetic
interference
protection
DLT645
calibraEon
commands
Load profile
support
Reset function,
historical data
recording
COSEM
objects/OBIS
codes
Anti-tampering/
anti-fraud
Last/average/
maximum
demand
Output relay
control
Watch-
dog
Clock
System
USCI
LCD
Line
Temperature
Provider
RTC
Flash
Memory
Timer ADC10SD24EEPROM
HAL
Calibration
Protocol
Rem. Device
Access Prot’l
...
Bin/Bcd
Converter
LCD format
Low-Pass
Filter
TickerModem Protocol
UTIL COMM
METROLOGY APPLICATION
No RTOS
Interrupt-Driven
One-Threaded Programming
Required Precision leads to
4096 Hz Sampling Rate
Interrupt-Triggered:
Measurement

Foreground Tasks:
App Logic, RTC

Size of the System
Common code runs on both processors, Metro runs on the
metrology processor and App runs on the applicaOon /
communicaOon processor.

+ roughly the same amount again for tests.
ca. 30,000 SLOC

Use of Extensions
All mbeddr C extensions used a lot.
Some extensions built speciﬁcally for SM.

A 5-minute
MPS tutorial
3
Lessons Learned
about Language
Development of
mbeddr

C Extension to dequeue a value
generated to

Editor + AcEons
Editor acEons to implement editor
behavior. Previously manually wrioen,
now generated from Grammar Cells.
See SLE Paper :-)

Constraints
Tree Constraints:
Scopes:

Type System
Checking Rules:
Typing Rules:

And many more...
IntenEons/Quick Fixes
Refactoring
Text Generators
Language Test Cases
Data Flow Graphs/Analyses
Debuggers
...

Project
Stats
4
Lessons Learned
about Language
Development of
mbeddr

Total Eﬀort
10
person years

Size of the Impl.
ca. 90,000 SLOC

What can
we learn?
5
Lessons Learned
about Language
Development of
mbeddr

1 Language Modualarity
2 ProjecEonal EdiEng
3 Managing Complexity
4 Tool Scalability
5 Development Process
RQ
RQ
RQ
RQ
RQ

For a scienEﬁc treat-
ment with all caveats
and data and details,
check out the paper:
hop://bit.ly/2dvXnBF

What can
we learn?
5
Lessons Learned
about Language
Development of
mbeddr
RQ
1 Language
Modualarity

Some had to be added a posteriori
IAssignmentLike: =, +=, *=, etc.
IFuncEonLike: funcEon, method
IBinaryLike: +-*/ but also . ?: !
IVoidTypeContainer: funcEon, Kype
Conceptually this breaks modularity.
But it‘s like OO programming/frameworks.
So we deem it acceptable.

OvermodularizaEon!
Too much modularizaEon is also not helpful.
We had a lot of circular dep‘s,
solved via interfaces.

Not helpful.
Refactoring tough because of MPS bugs in Refactorings.

We used mostly Extension (+EC)
Fundamentally it works and scales.

Is Extension
ComposiEon
modular?
MulEple Extensions in C

No syntacEc or IDE issues.
Type systems compose well.

BUT: SemanEc InteracEons cannot be
staEcally guaranteed to be correct.

Is Extension
ComposiEon
modular?
NesEng in C/in each other

No syntacEc or IDE issues.
Type systems compose well.

BUT: SemanEc InteracEons cannot be
staEcally guaranteed to be correct.

Is Extension
ComposiEon
modular?
NesEng in each other

Adapter language Needed
Type system adapters needed

Adapter Language also deals
with semanEc interacEons.

Speciﬁcally design integraEons!
No modularity!

Yes, to the degree it can reasonably
be expected to be (third case!)
Is Extension
ComposiEon
modular?
But with the limitaEons that semanEcs
cannot be staEcally checked to be compaEble.

Might be solved in the (far) future when all
transformaEons are declaraEve and analyzable.

Composing Type Systems
DeclaraEve
L1 L2

Composing Type Systems
DeclaraEve
L1 + L2
Order Irrelevant

Composing TransformaEons
DeclaraEve
Order Relevant

DeclaraEve
Order Relevant
Simple extension: D extends I

DeclaraEve
Order Relevant
Independent extension:
D1 and D2 extend I

DeclaraEve
Order Relevant
Stacked extension:
D2 extends D1 and extends I

DeclaraEve
Order Relevant
Indep extension with gen dep:
We did not encounter this.
Hyp. Example: Method, FuncEon, Logging.

Gevng the ordering right can be a
challenge. We discuss debugging later.
Once correct, the system works well.


RQ
1 Language
Modualarity
mbeddr’s 34 C extensions indicate that MPS’ language modularity
works. It is useful for language understanding, tesOng and reuse.

In rare cases, modularity is compromised by necessary changes to
the base language and unwanted dependencies between
independent extensions.

Currently there is no way to detect (unwanted) semanEc
interacEons between independent language extensions through
analysis of their transformaOons.

What can
we learn?
5
Lessons Learned
about Language
Development of
mbeddr
RQ
2 ProjecEonal
EdiEng

ProjecEonal EdiEng
Language ComposiEon

SyntacEc Flexibility is actually useful
for end users – see Smart Meter.

Diﬀerent NotaEons for one AbstracEon.
State Machines

Diﬀerent NotaEons for one AbstracEon.
State Machines
But: type checks and some acEons
based on AST, not on what is shown.
This can be confusing to users.

OpEonally projected syntax.
Requirements Traces

Decoupled NotaEonal PrimiEves
Sum & Trees
Math in C and KernelF
Trees for decisions
and feature models

Developing new notaEons.
MPS is Bootstrapped.

Editor Usability
Strongly ... Neutral ... Strongly
agree disagree
People prefer MPS over convenEonal IDEs
MPS more is more efficient than normal IDEs
MPS more is more producEve than normal IDEs
MPS makes it easier to create correct programs
MPS enforces a structurally correct AST
People benefit from language modularity
People benefit from the flexible notaEons
The experience with learning MPS is mixed.
It takes some Eme to get used to MPS
Based on an empirical study.

Signiﬁcantly Improved Editor Usability
Based on an empirical study.
Generic
CommenEng
Grammar Cells
(see SLE Paper)
Paleoes and other
input support uEls.
Top-Down Progr.
via Target CreaEon

But sEll issues/diﬀerences in Editor Usability
SelecEng code is structural, not linear
Copy/paste of similar syntax but
diﬀerent structure requires customizaEon
Grammar cells go a (very) long way, but
not *every* ediEng acEon is possible.
PasEng from text requires integraEon
of a parser (hooks exist), not automaEc
Very few complaints since we did the improvements.
We consider the problem mostly solved.

Version Control IntegraEon
Fundamentally File-based
We used git – worked well
diﬀ/merge in MPS
Can‘t use outside tools (gerrit)

RQ
2 ProjecEonal
EdiEng
Two main benefits of projecOonal ediOng – language modularity
and a range of combinable notaEons – have been used extensively
in mbeddr. The anOcipated benefits have been observed.

Editor can be flexibly extended with new notaOonal styles with
acceptable effort, as exemplified by math, tables and diagrams.

The ability to use mulEple and parEal projecEons must be further
improved by integraOng with other language aspects, in parOcular,
editor acOons and type checks.

What can
we learn?
5
Lessons Learned
about Language
Development of
mbeddr
RQ
3 Managing
Complexity

ProjecEonal EdiEng
Reduced Complexity
Language modularizaEon
No disambiguaEon code

[Language Aspects]

[Language Aspects]
A separate DSL for each aspect
DeclaraOve
Metamodel
DeclaraOve
Editor Cells
DeclaraOve
Typing Rules
ImperaOve
ValitaOons
DeclaraOve
Templates
DeclaraOve
PrioriOes
ImperaOve
Constraints

[Language Aspects]
A separate DSL for each aspect
DeclaraOve
Metamodel
DeclaraOve
Editor Cells
DeclaraOve
Typing Rules
ImperaOve
ValitaOons
DeclaraOve
Templates
DeclaraOve
PrioriOes
ImperaOve
Constraints
Each language opEmized for its task.
In our experience, separate aspect DSL
increase producEvity – as DSLs should.

[Language Aspects]
A separate DSL for each aspect, but:
DeclaraOve
Metamodel
DeclaraOve
Editor Cells
DeclaraOve
Typing Rules
ImperaOve
ValitaOons
DeclaraOve
Templates
DeclaraOve
PrioriOes
ImperaOve
Constraints
MPS BaseLanguage
essnOally Java + X. Mostly ImperaOve

[Language Aspects]
DeclaraOve
Metamodel
DeclaraOve
Editor Cells
DeclaraOve
Typing Rules
ImperaOve
ValitaOons
DeclaraOve
Templates
DeclaraOve
PrioriOes
ImperaOve
Constraints
MPS BaseLanguage
DeclaraEve? { Analysis?
OpEmizaEon?

[Language Aspects]
DeclaraEve? { Analysis?
OpEmizaEon?

The non-declaraEveness leads to problems in
analysis (impact, debugging, veriﬁcaEons) or
opEmizaEon (caching).

[Language Aspects]
A separate DSL for each aspect. Debugging?
Editor

[Language Aspects]
TransformaEons

[Language Aspects]
Type System

[Language Aspects]
System.out.println(...);
All in all, the debugging experience is not
where it should be. Needs improvement.
All the rest...

[Language Aspects]
A separate DSL for each aspect, but missing aspects:
DeclaraOve
Metamodel
DeclaraOve
Editor Cells
DeclaraOve
Typing Rules
ImperaOve
ValitaOons
DeclaraOve
Templates
DeclaraOve
PrioriOes
ImperaOve
Constraints
MPS BaseLanguage
DocumentaOon
Debugger
Interpreter
...
Since MPS 3.3, one can deﬁne custom aspects.

MPS is bootstrapped.
meaning: it is built with itself.
it can be extended with itself.

DeclaraEve type mappings
Type Guards
Concise syntax, especially for recursive calls
Composable (just as languages)
AbstracEons for environments and stacks Interpreter

IncA
Restricted, DeclaraEve Language
Transformed to Paoerns
Executed incrementally
Very fast!

New primiEve editor cells for math, diagram, tables
More query-oriented than default MPS notaEons
NotaEon independent from Language
Editor

RQ
3 Managing
Complexity
Using a DSL for each language aspect works well based on our
experience, even though some aspects are missing and some are
not declaraOve enough to support meaningful analyses.

The support for debugging is spooy: it works well for
transformaOons, but debugging generator macros, behav- iors and
type system rules is very tedious.

The ability to extend MPS’ language deﬁniOon DSLs with MPS
itself is a powerful approach for managing complexity, and we
have used it extensively, even though it has some limitaOons.

What can
we learn?
5
Lessons Learned
about Language
Development of
mbeddr
RQ
4 Tool
Scalability

Editor Responsiveness
The bigger one root gets, the slower the
editor gets because more “stuﬀ” must
be rendered:
- incrementally rendered, but sEll ...
- depends on the notaEon
- 3000 “lines” of C code
Split into several roots.
Impacts Language Design.

Editor Responsiveness
Code compleEon is extremely criEcal:
you can only enter what has been “put into”
the code compleEon menu. => Tree Constraints
Scopes

Type Checking and Constraints
Type checking is incremental, and happens
in the background.
Checks may run long – but are interruptable.
But both need locks on the repo: they can
lead to performance issues.
=> Cancellable Checks
Assessments
SelecEve Enabling
“Energy Saver Mode”

TransformaEon
The model with 128 roots corresponded to 68,400 LoC of generated C
code (for Plain C), 202,000 LoC (C + State Machines) and 198,000 LoC (C
+ State Machines + Units + Components).
GeneraEon Eme (in seconds)
# of roots with 1,000 nodes each

TransformaEon
GeneraEon Eme (in seconds)
# of roots with 1,000 nodes each
Time Size && Time Intermediate Model Volume ~ ~

RQ
4 Tool
Scalability
With ahenOon to root size and the distribuOon of code over
models, then systems of signiﬁcant size can be built with MPS.

The performance of the type system (as it is evaluated in realOme
in the editor) and support for cross-model generaEon are the two
most criOcal ways of improving MPS performance.

During the development of languages we have not run into any
problems regarding performance or scalability (of editor, type
system or generator deﬁniOons).

What can
we learn?
5
Lessons Learned
about Language
Development of
mbeddr
RQ
5 Development
Process

TesEng the editor
No need to test if “parsing” works.
But you have to check if you can enter what
you need to enter, where you think it belongs.

TesEng the editor
No need to test if “parsing” works.
And you have to test if the the tree is con-
structure correctly when linear input is used.

TesEng the type system
Do typing rules and constraints work?
EssenEally check if the red squigglies
show up where you expect them.

TesEng semanEcs
Whenever possible, test semanEcs by
execuEon and test cases, and not by checking
(the structure of) the generated code.

TesEng semanEcs
Test case generaEon:
•  Select a set of language extensions
•  Randomly generate structurally sound programs
•  If the type system finds errors in the program, discard
the program (because errors are correctly reported)
•  If the program has no errors, try to generate and
compile it. If either generaOon or compilaOon fails, flag
this parOcular generated program as a failed test.
Helps finding inconsistencies in the mulE-
stage transformaEon process.

Version Control
Works. As long as you are willing to
use MPS for diﬀ/merge.

CI Server IntegraEon
We successfully run all our builds, tests and
packaging on
However, the effort to get the MPS builds
to run there is too high
the usual build dependency hell
the MPS build language is not flexible enough
maybe iniEally not enough experience with “build stuff”
Also, builds tend to take (too) long.
a full mbeddr build takes 12 minutes on the server and ca.
30 minutes on a fast developer PC
Mixed bag!

Languages have version numbers
MigraEon of Models
Automated refactorings increment that
number; so can developers.
MigraEon scripts bring models up to date
based on the language versions.
Mixed bag!
This is already more than in most other
tools we know about. But it is clumsy and
someEmes slow.

RQ
5 Process
IntegraEon
Except for the missing test support for model migraOons and
single-step transformaOons, language tesEng works well; we have
achieved good coverage as demonstrated by a stable code base.

We have successfully integrated mbeddr’s build, test and
packaging with the Teamcity CI server, but the eﬀort was too high,
parOally because of the inadequacy of MPS’ build language.

MigraEng models as languages change incompaObly is feasible
with manually scripted migraOons and their automaOc execuOon
based on implicitly-maintained language version numbers.

Concluding
Thoughts
6
Lessons Learned
about Language
Development of
mbeddr

C is a strange language
The details were
harder to build than
we iniEally thought.
But MPS can do it!

Language is not enough.
IDE, Debugger,
Analyses, Interpreter.

Tool Chrome hurts.
MPS „looks“ too complicated
for the prospecEve end user.

Onboarding devs.
It took 4 – 8 weeks to get
competent new devs on board.

OpEmizing Generators
is hard :-)

Modularity vs. OpEmizaEon
Global opEmizaEon are in
conﬂict with modularity
and extensibility.

Perhaps two generators?

Open vs. Closed World
How do you build trust
into a system that is
inherently extensible?

More DeclaraEveness
More declarariveness and inproved
ability to analyze language deﬁniEon
code would help!

Shadow Models
We need incremental, real-Eme,
mulE-step, in-IDE transformaEons
for advanced analyses.

Change is hard.
ProspecEve users were hard
to convince to adopt mbeddr.

Wrap
Up
7
Lessons Learned
about Language
Development of
mbeddr

MPS is a capable LWB.
Overall we are happy and conEnue to use it.
It is deﬁnitely ready for real-world use
mbeddr – and this evaluaEon – is testament to that.
Many architectural desicisons are good...
ProjecEon, Aspect DSLs, Bootstrapping.
... but it has some weak points as well.
Internal complexity, imperaEveness, build, fat Java client.
A good choice for LE projects today.
Great starEng point for next gen LWBs :-)

Lessons Learned from building mbeddr

More Related Content

What's hot (16)

Similar to Lessons Learned from building mbeddr (20)

More from Markus Voelter (20)

Recently uploaded (20)

Lessons Learned from building mbeddr