ASNSDK TCE-C++
Version 4.3 enhancements
This section presents the new services and the improvements added to the TCE-C++ v4.2 release.
Runtime performances optimizations
The runtime has been enhanced to improve the performances (both space and time).
Some of these improvements have to be explicitly enabled by the user :
- The choice between table driven technology or code generation technology,
- The choice of the memory management,
- The choice of an API with or without exceptions,
- The removal of code unused in the user configuration.
The other improvements do not need any user action.
New table driven technology for PER
The TCE-C++ V4.3 release contains a new PER encoding/decoding engine using the table driven technology.
The table driven technology produces far less code than the existing code generation technology.
The code generation technology usually saves CPU time (CPU time is very platform-dependent).
The existing PER encoding/decoding engine using code generation technology remains available using the new -tech codegen compilation option.
New technology option
This new compilation option allows to select the preferred technology :
- Use -tech tabledriven when the table driven technology is preferred,
- Use -tech codegen when the code generation technology is preferred.
When this option is not used, the table driven technology is preferred.
The table driven technology is available for all features.
The code generation technology is available only for Aligned PER, Unaligned PER and Constraint Check.
New optional memory managements
The V4.3 release introduces two new optional memory management features :
- A basic memory management,
- A memory management with memory-leak survey.
These optional memory management features can be used alone or together.
Usual memory management
The user has the possibility to modify these macros to call other functions that satisfy the same needs.
This memory management is used for all objects created and destroyed with the C++ new and delete operators of the ASNSDK classes and for all buffers allocated and released with the asnalloc and asnfree functions.
This memory management is straighforward but it can produce a large number of memory requests when complex values are encoded or decoded.
In some cases(*), to reduce the number of memory requests, the runtime asks for a large memory block in which it can satisfy several smaller memory requests. The size of this large memory block is configurable using the asnCAD10_TMPALLOCSIZE macro definition (2000 bytes by default).
Basic memory management
Instead of calling the asnllalloc macro for each small memory request, the runtime calls the asnllalloc macro only for large memory blocks in which it can satisfy several smaller memory requests. Furthermore, the large blocks are only freed when the context is destroyed.
The basic memory management has several advantages :
- It reduces largely the time used to allocate memory,
- It reduces to almost 0 the time used to free the memory,
- It saves the code of the destructors of the values.
But it has also some drawbacks:
- It requires the use of the context for each memory allocation and release.
- When the context is destroyed, the memory is freed. So, when the context is destroyed, the user must not keep references to data stored in this memory.
- Space can be wasted when the size of the large memory blocks is badly configured.
This feature is enabled by defining the asnCodBalloc macro in the ascupdef file.
The size of the large memory blocks is configurable using the asnCAD12_BALLOCSIZE macro definition (10200 bytes by default).
Memory management with memory-leak survey
When this feature is enabled, the context keeps track of all memory allocations and memory releases that go through the ASNSDK memory management. When the context is destroyed, all unreleased memory blocks are released.
Depending on the trace configuration, it is possible to :
- Trace the number of unreleased memory blocks,
- Trace each memory allocation and memory release,
- Dump the content of the unreleased memory blocks.
This feature has some requirements:
- It requires the use of the context for each memory allocation and release.
- When the context is destroyed, the memory is freed. So, when the context is destroyed, the user must not keep references to data stored in this memory.
This feature is enabled by defining the asnCodXalloc macro in the ascupdef file.
Common requirements
- The context must be created before the first memory allocation and destroyed after the last memory release(**).
- It must be possible to obtain the context currently used by the current thread.
The first requirement makes mandatory a good-programming practice. The second requirement has two impacts :
- It is not possible to have several context variables at the same time in one thread.
- When the ASNSDK runtime is used by several threads in an application, there must be a way to obtain the context used by the current thread.
The way to obtain the context used by the current thread is system dependent. The ASNSDK runtime provides three customizable macros in the aipupdef file that have to be adapted to the system.
The default implementation of these macros (based on a global variable) can be used when only one context is alive at each point in time in the whole application (single-threaded application or application were only one thread uses the ASNSDK runtime).
When the ASNSDK runtime is used simultaneously in several threads, the macros have to be modified in a system dependant way. For example, a solution on a VxWorks system is to declare the global variable as a new VxWorks task variable or better to replace it by a field in an existing VxWorks task variable.
New C++ API without exceptions
In some platforms, mainly real-time, the use of exceptions in the C++ code decreases the performances very significantly, not only in error cases but also in the normal cases.
To workaround this performances decrease, the V4.3 introduces a new C++ API where the exceptions are replaced by return codes.
The C++ API without exceptions is derived from the C++ API with exceptions :
- the C++ new operator is replaced by the C++ new (nothrow) operator,
- if the method cannot fail, the API are identical,
- if the method can fail, the return code is the result of the method in API without exceptions (a non-void result in the API with exceptions is moved at the end of the parameter list in the API without exceptions),
- in some few cases, the API are identical but a special value of the result of the method (like a null pointer) is used to signal an error in the API without exceptions when an exception is thrown in the API with exceptions,
- the asnException class is suppressed (the errorCode is now available through the result of the method call and the error location is available in an enhanced format in the asnContext::getErrorLocation() method).
The C++ API without exceptions is not compatible with the code generation technology (-tech codegen option), the XER-like value trace (-v1trace option) and the decoding-constructor option (-dector option).
By default, the C++ API with exceptions is selected. To select the C++ API without exceptions, it is necessary to define the asnCodExceptLess flag in the aipupdef file and to undefine the asnCodCODE flag and the asnCodVTRA flag in the ascupdef file.
New debugging trace feature
The V4.3 introduces a debugging trace feature.
Several traces are available :
- Trace of the number of unreleased memory blocks,
- Trace of each memory allocation and memory release,
- Dump the content of the unreleased memory blocks,
- Trace of each error returned on the user API (either by an exception or a return code).
The enabled traces are defined by a global variable in the asccstz.c file. By default, only the trace of the number of unreleased memory blocks is enabled (but the memory management with memory-leak survey is disabled by default).
By default, the trace functions write on the standard error file stderr. It is possible to customize these trace functions to adapt them to the user needs. They are located in the asccstz.c file and the aipcstz.cc file.
New features removable from the runtime
The ascupdef file contains the definition of preprocessor flags governing the features of the runtime. By removing some definitions of this file, it is possible to reduce the same of the runtime.
It is now possible to remove the support of the code generation technology (asnCodTable flag) and the support of the table driven technology (asnCodTABLE flag).
It is now possible to remove the source code used for the encoding trace (asnCodETRA flag).
It is now possible to remove the source code used to manage files (asnCodFile flag).
New methods on streams
The streams classes have been enriched with a seek method and a flush method.
Better support of the non-unicode string types in XER
The non-Unicode String types (TeletexString, T61String, VideotexString, GraphicString, GeneralString and ObjectDescriptor) need a conversion to Unicode to be encoded in XER and a conversion from Unicode to be decoded from XER.
These conversions are now supported through two new customization functions in the asxcstz.c file.
The provided implementation of these functions handles correctly the characters in the US-ASCII subset doing a simple byte per byte conversion.
If characters outside of this subset have to be encoded or decoded, the user has to enhance these functions to add the support of these characters.
Passing options to the Java virtual machine
With some large ASN.1 syntaxes, the ASN.1 compiler could throw an Java OutOfMemory exception because the Java memory was exhausted altough memory remained available on the computer.
It is now possible to pass options to the Java Virtual machine through the new ASNSDK_JAVA_OPTION environment variable.
This allows to specify a larger memory limit to the Java Virtual machine.
(*) These cases are mainly the encoding processes.
(**) It is recommended to allocate the context on the stack but it is possible to allocate it dynamically : the new and delete operators of the context are mapped by default to the low-level allocation and release functions that bypass these memory managements.