baos@caip.rutgers.edu (Bancroft Scott) (11/06/90)
This is in response to the posting last week by murthy%betaal@shakti.ernet.in. I tried responding directly as requested, but the response came back with "unknown host". The body of the response was: >... is there any one who has incorporated the macro notation in the ASN.1 >compiler (pepy)? Open Systems Solutions, Inc. (609-987-9073) has incorporated the macro notation into their ASN.1 compiler, but not as ISODE has. The approach taken by ISODE is to precode a few macros into the compiler. The approach taken by OSS is to, upon encountering a macro definition, build the equivalent of a compiler for that macro, then when an instance of the macro is encountered, the newly built macro compiler is invoked to handle the macro's type and value notation. In those cases where the macro instance is encountered before the macro definition (possibly a forward reference to a macro defined in another module), the macro instance is processed successfully (in a delayed fashion) only if no arguments were supplied. Effectively this says that the compiler has a restriction that the macro must be defined before it is used, unless in the (forward referenced) use of the macro no arguments are supplied. The approach taken by OSS has the advantage that it will handle any macro, including any arbitrary macro that one may wish to dream up, instead of a selected handful. This allows for full syntax checking of all macro arguments and replacement of macro instances with the type of the value that the macro returns. The approach taken by ISODE allows the compiler to interpret the semantics of a handful of macros, thus it can generate a certain amount of C code on behalf of the application. The OSS compiler does not attempt to interpret the semantics of macros, since the macro notation in itself does not support this sort of thing; hence, it simply replaces all instances of macros with the type associated with the macro's returned value. There is special handling for those degenerate cases where a single assignment to VALUE does not occur in the macro instance. The current work on Information Object Classes, Parameterization and Constraints that is ongoing in CCITT and ISO will provide the means whereby it will be possible for compilers to interpret a certain amount of the semantics that is being conveyed in the abstract syntax specification. Once this work reaches the status of Committee Draft (which is expected to happen next Spring), OSS intends to start supporting the generation of application code to the degree permitted by the new ASN.1 constructs. Note that ROSE and all protocols which use the ROS macros will be rewritten to use Information Object Classes, Parameterization and Constraints. It is anticipated that a good deal of this rewriting will be completed by Spring 1992. Since the use of Information Objects, etc. is transparent to the transfer syntax (just as the macro notation is), there will be no problem for implementations that use Information Objects, etc. to communicate with those that use macros or have expanded macros by hand. Information Objects, Parameterization and Constraints can be considered to be "macros, ANY, ANY DEFINED BY and EXTERNAL types done correctly". These new ASN.1 constructs are *much* simpler to understand, use and process than the macro notation; but they are (in my opinion) a bit harder to grasp than the subtype notation for a first time user of ASN.1. Bancroft Scott