资源预览内容
第1页 / 共13页
第2页 / 共13页
第3页 / 共13页
第4页 / 共13页
第5页 / 共13页
第6页 / 共13页
第7页 / 共13页
第8页 / 共13页
第9页 / 共13页
第10页 / 共13页
亲,该文档总共13页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述
附录附录A High-performance ASN.1 compilerMichael Sample and Gerald NeufeldError managementError management is important, but it must be implemented without incurring too much cost for the common case where there are no errors. One method of streamlining error management is to eliminate it by assuming that the decoded values are always correct. This is not acceptable for a reliable implementation.To implement a complete yet light-weight error management scheme for the decoders, we used the setjmp and longjmp functions 23. Previously, the availability of these functions was very system dependent; however, they are now part of the ANSI Standard C Library. Before decoding begins, set jmp is called to record the current environment (processor registers,etc.). The environment value set by setjmp is then passed into the decoding routine. Every decoding routine takes this parameter. When the decoding routines encounter a serious error such as running out of memory for the decoded value, they call longjmp with the environment value they were given as a parameter, along with a unique error code. This returns execution directly to where setjmp was called along with the error code.The setjmp and longjmp based error management is simple and does not impact on the performance of decoding correctly encoded values (other than an extra parameter to each decoding routine). Other error management techniques, such as passing back error codes, that the calling functions must check will affect the decoding performance even for correctly encoded values.Buffer managementEncoding and decoding performance is greatly affected by the cost of writing to and reading from buffers. Thus, efficient buffer management is necessary. Flexibility is also important to allow integration of the generated encoders and decoders into existing environments. To provide both of these features, the calls to the buffer routines are actually macros that can be configured as desired. They must be configured prior to compiling the encode/decode library and the generated code. Since virtually all buffer calls are made from the encode/decode library routines, bufler routine macros should not bloat code size significantly. If a single, simple buffer type can be used in the target environment, the buffer routine macros can be defined to call the macros for the simple buffer type. This results in the buffer type being bound at the time the generated code is compiled, with no function call overhead from the encode or decode routines. However, this also means that the encode and decode library will only work with that buffer type.If multiple buffer formats must be supported at runtime, the buffer macros can be defined like the ISODE buffer calls, where a buffer type contains pointers to the buffer routines and data of user defined buffer type. This approach will hurt performance since each buffer operation will be an indirect function call. The backwards encoding technique used by snacc requires special buffer primitives that write from the end of the buffer towards the front. The decoder routines require forward buffer reading routines.Memory managementLike buffer management, memory management is very important for efficient decoders. Snacc decoders allocate memory to hold the decoded value. After the decoded value has been processed it is usually freed. The decoding and freeing routines in the library and the ones generated by snacc both use the memory manager. The decoders allocate memory with the AsnlAlloc routine and the freeing routines call AsnlFree.The configuration header file allows the user to change the default memory manager prior to compiling the library and the generated code. Snacc provides a particularly efficient memory manager, discussed shortly, called nibble memory.The memory manager must provide three routines: AsnlAlloc, Asnlfr ee and CheckAsnlAlloc. These memory routines should have the following interfaces:void * AsnlAlloc(unsigned longint size);void AnslFree(void * ptr);int CheckAsnlAlloc(void * ptr, ENV TYPE env);The decoders assume that AsnlAlloc returns a zeroed block of memory. This saves explicit initialization of OPTIONAL elements with NULL in the generated decoders. The ENV TYPE parameter is used with the error management system for calls to longjmp.To change the memory management system the configuration file needs to be edited. For example, ifperformance is not an issue and you want to use calloc and free, the configuration file would be as follows:#include malloc.h#define AsnlAlloc(size) calloc(l, size)#define AsnlFree(ptr) free (ptr)#define CheckAsnlAlloc(ptr, env)if (ptr)-NULL)longjmp(env,-27);The nibble memory system does not need explicit flees of each component so the generated free routines are not needed. However, if you change the memory management to use something like malloc and free you should use the generated free routines. By default, snacc uses a nibble m
收藏 下载该资源
网站客服QQ:2055934822
金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号