Properties and Restrictions :

Obviously, such objects have the following properties:

• The memory address of an object is always known at compilation time, and no memory violation are expected during run-time when accessing these objects.
• The size of the object is fixed and known in advance, using the sizeof() operator.
• The memory mapping is the same for any implementation except for int and float which memory representation may vary from a machine to another.
• The access time to any component of a memory-object is fixed and known in advance, the address being a simple offset with respect to the memory-object start address.
• The components of the objects are always aligned with 32bits addresses. Furthermore, struct corresponding to bit fields are always accessed as a whole (the 32bits is read or written once and manipulated either though predefined masks or using specific processor instructions).

Let us now discuss the voluntary restrictions introduced in these specifications:

• There is no pointer. This is the main restriction, in fact, and the only fundamental one. As soon as pointers are introduced the semantic of the language is much more difficult to control, programs can easily violate the memory, etc...

  It is clear that we need pointers to defined lists, tables, stacks, files etc... of elements, but these objects will not be defined this way. They will be called containers and will be part of another layer of the specifications and implemented in the kernel, for safe and easy use.

• There is no double numbers (usually of 64bits) and 8 or 16bits elements.

  This restriction is not mandatory, but seems to be reasonable considering the applications. Double floating point numbers are only useful for computations numerically not very stable, while they yield slower and heavier implementation. We thus better discourage their use, although it is very easy to reintroduce them. Similarly, using 8 and 16bits numbers save memory but very often slow the memory access since almost all architectures are now optimized for 32bits access.

  Another reason to limit the numeric formats, is to simplify the specifications and the underlying semantic models. Being lazy, helps being efficient.

• There is no enum or define primitive because this mechanism of macro is treated at another level of these specifications.
• There is also no char and strings, because the purpose of such systems is indeed not to perform text processing, but symbolic or numeric computations. Furthermore, strings are variable length zero-ended mono-dimensional arrays, which manipulation introduced pointers and unsafe access.