|
| 1 | +<!-- |
| 2 | + © 2023 Intel Corporation |
| 3 | + SPDX-License-Identifier: MPL-2.0 |
| 4 | +--> |
| 5 | + |
| 6 | +# Managing deprecated language features |
| 7 | + |
| 8 | +As the DML language evolves, we sometimes need to change the language in |
| 9 | +incompatible ways, which requires DML users to migrate their code. This |
| 10 | +appendix describes the mechanisms we provide to make this migration process |
| 11 | +smooth for users with large DML code bases. |
| 12 | + |
| 13 | +In DML, deprecations can come in many forms. Deprecations in the form of |
| 14 | +removed or renamed symbols in libraries are rather easy to manage, since they |
| 15 | +give clear compile errors that often are straightforward to fix. A slightly |
| 16 | +harder type of deprecation is when some language construct or API function |
| 17 | +adjusts its semantics; this can make the model behave differently without |
| 18 | +signalling error messages. A third kind of deprecation is when DML changes how |
| 19 | +compiled models appear in Simics, typically to adjust changes in the Simics |
| 20 | +API. Such changes add another dimension because they typically affect the |
| 21 | +end-users of the DML models, rather than the authors of the models. Thus, as an |
| 22 | +author of a model you may need to synchronize your migration of such features |
| 23 | +with your end-users, to ease their transition to a new major version. |
| 24 | + |
| 25 | +## Deprecation mechanisms |
| 26 | + |
| 27 | +The simplest deprecation mechanism is Simics API versions: Each deprecated DML |
| 28 | +feature is associated with a Simics API version, and each Simics version |
| 29 | +supports a number of such API versions. Features reach end-of-life when moving |
| 30 | +to a new Simics major version, the features belonging to a previous Simics API |
| 31 | +version are dropped. Since Simics is currently the primary distribution channel |
| 32 | +for DML, this deprecation scheme is used for DML features as well. |
| 33 | + |
| 34 | +This scheme allows users with a large code base to smoothly migrate from one |
| 35 | +Simics major version, N, to the next, N+1: |
| 36 | +* First, while still using version N, make sure all Simics modules are updated |
| 37 | + to use API version N. Modules can be migrated one by one. |
| 38 | +* Second, update the Simics version to N+1. This should normally have no |
| 39 | + effect on DML, but may come with other challenges. |
| 40 | +* Third, update modules to API N+1, one by one. Simics version N+1 will always |
| 41 | + offers full support for API N, so there is no rush to update, but changing |
| 42 | + the API version early makes sure deprecated features are not introduced in |
| 43 | + new code. |
| 44 | + |
| 45 | +In addition to the API version, DML offers some compiler flags for selectively |
| 46 | +disabling deprecated features that are normally part of the used API. This has |
| 47 | +some uses, in particular: |
| 48 | +* During migration to a new API version, disabling one deprecated feature at a |
| 49 | + time can allow a smoother, more gradual, migration. |
| 50 | +* If a legacy feature is still fully supported in the latest API version, then |
| 51 | + it cannot be disabled by selecting an API version, so selectively disabling |
| 52 | + it is the only way to turn it off. There are reasons to do this, e.g.: |
| 53 | + * Disabling a feature before it is deprecated guarantees that it is not |
| 54 | + relied upon in new code, which eases later migration. |
| 55 | + * Avoiding a feature that has a newer replacement makes the code base |
| 56 | + cleaner and more consistent. |
| 57 | + * Some legacy features can also bloat models, by exposing features in a |
| 58 | + redundant manner. This can also have a negative impact on performance. |
| 59 | + |
| 60 | +## Controlling deprecation on the DML command-line |
| 61 | +DMLC provides a command-line flag `--api-version` to specify the API version to |
| 62 | +be used for a model. When building with the standard Simics build system, this is controlled by the `SIMICS_API_VERSION` variable in `make`, or the `SIMICS_API`/`MODULE_SIMICS_API` variable in `CMake`. |
| 63 | + |
| 64 | +DMLC also provides the <code>--deprecate=_tag_</code> flag, which disables the |
| 65 | +feature represented by _`tag`_. The available tags are listed in the next |
| 66 | +section. The tag also controls the name of a global boolean parameter that the |
| 67 | +DML program may use to check whether the feature is available. The parameter's |
| 68 | +name is the tag name preceded by `_deprecate_`. |
| 69 | + |
| 70 | +## List of deprecated features |
0 commit comments