1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
.. highlight:: none


.. index::
   pair: execution; environment

.. _design-exec-env:


Execution environment
=====================

.. mps:prefix:: design.mps.exec-env


Introduction
------------

:mps:tag:`intro` This document describes how the MPS is designed to work in
different execution environments (see standard.ansic section 5.1.2).


Discussion
----------

:mps:tag:`std` These are the relevant statements from the International
Standard ISO/IEC 9899:1990 "Programming languages — C", with tags
added:

    4. Compliance

    […]

    :mps:tag:`std.com.hosted` A "conforming hosted implementation" shall
    accept any strictly conforming program. :mps:tag:`std.com.free` A
    "conforming freestanding implementation" shall accept any strictly
    conforming program in which the use of the features specified in
    the library clause (clause 7) is confined to the contents of the
    standard headers ``<float.h>``, ``<limits.h>``, ``<stdarg.h>``,
    and ``<stddef.h>``. A conforming implementation may have
    extensions (including additional library functions), provided they
    do not alter the behaviour of any strictly conforming program.

    […]

    5.1.2 Execution environments

    :mps:tag:`std.def` Two execution environments are defined:
    "freestanding" and "hosted". […]

    :mps:tag:`std.init` All objects in static storage shall be "initialized"
    (set to their initial values) before program startup. The manner
    and timing of such initialization are otherwise unspecified. […]

    :mps:tag:`std.term` "Program termination" returns control to the execution
    environment. […]

    5.1.2.1 Freestanding environment

    :mps:tag:`std.free.lib` Any library facilities available to a
    freestanding environment are implementation-defined.

    :mps:tag:`std.free.term` The effect of program termination in a
    free-standing environment is implementation-defined.


Interpretation
--------------

:mps:tag:`int.free` We interpret the "freestanding environment" as being the
sort of environment you'd expect in an embedded system. The classic
example is a washing machine. There are no library facilities
available, only language facilities.

:mps:tag:`int.free.lib` We assume that the headers ``<float.h>``,
``<limits.h>``, ``<stdarg.h>`` and ``<stddef.h>`` are available in the
freestanding environment, because they define only language features
and not library calls. We assume that we may not make use of
definitions in any other headers in freestanding parts of the system.

:mps:tag:`int.free.term` We may not terminate the program in a freestanding
environment, and therefore we may not call :c:func:`abort()`. We can't call
:c:func:`abort()` anyway, because it's not defined in the headers listed
above (:mps:ref:`.int.free.lib`).

:mps:tag:`int.free.term.own` We can add an interface for asserting, that is,
reporting an error and not returning, for use in debugging builds
only. This is because the environment can implement this in a way that
does not return to the MPS, but doesn't terminate, either. We need
this if debugging builds are to run in a (possibly simulated or
emulated) freestanding environment at all.


Requirements
------------

:mps:tag:`req` It should be possible to make use of the MPS in a
freestanding environment such as an embedded controller.

:mps:tag:`req.conf` There can be configurations of the MPS that are not
freestanding (such as using a VM arena).


Architecture
------------

:mps:tag:`arch` Like Gaul, the MPS is divided into three parts: the *core*,
the *platform*, and the *plinth*.

:mps:tag:`arch.core` The *core* consists of the Memory Pool Manager (the
core data structures and algorithms) and the built-in Pool Classes.
The core must be freestanding.

:mps:tag:`arch.platform` The *platform* provides the core with interfaces to
features of the operating system and processor (locks, memory
protection, mutator context, stack probing, stack and register
scanning, thread management, and virtual memory). The platform is
specialized to a particular environment and so can safely use whatever
features are available in that environment.

:mps:tag:`arch.plinth` The *plinth* provides the core with interfaces to
features of the user environment (time, assertions, and logging). See
design.mps.io_ and design.mps.lib_.

.. _design.mps.io: io.html
.. _design.mps.lib: lib.html

:mps:tag:`arch.distinction` The distinction between *plinth* and *platform*
is that end users will need to customize the features provided by the
plinth for most programs that use the MPS (and so the interface needs
to be simple, documented and supported), whereas implementing the
platform interface is a specialized task that will typically be done
once for each platform and then maintained alongside the core.