etc:users:jcmvbkbc:isl
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
etc:users:jcmvbkbc:isl [2010/08/15 13:43] – jcmvbkbc | user:jcmvbkbc:isl [2016/08/07 00:17] – ↷ Page moved from etc:users:jcmvbkbc:isl to user:jcmvbkbc:isl kel | ||
---|---|---|---|
Line 2: | Line 2: | ||
[[http:// | [[http:// | ||
+ | |||
+ | [[http:// | ||
===== Orthogonal aspects ===== | ===== Orthogonal aspects ===== | ||
Line 56: | Line 58: | ||
When the header is absent Param1 corresponds to the trailer. If there' | When the header is absent Param1 corresponds to the trailer. If there' | ||
+ | |||
+ | Interfaces visible from root package, not referenced from other interfaces visible from root package get translated to pack/ | ||
===== Decoding context ===== | ===== Decoding context ===== | ||
Line 121: | Line 125: | ||
Only mandatory fields may have LengthRestriction > 1. | Only mandatory fields may have LengthRestriction > 1. | ||
+ | |||
+ | ===== Derived interfaces ===== | ||
+ | * if derivation is by inversion, another interface is created and parent' | ||
+ | * if derivation is by narrowing, another interface is created and extra messages are removed from there; | ||
+ | * derived interface is always represented by the DerivedInterface class; | ||
===== Validation constraints ===== | ===== Validation constraints ===== | ||
Line 128: | Line 137: | ||
* every pack/unpack message has corresponding messagetype; | * every pack/unpack message has corresponding messagetype; | ||
* header and trailer follow the rules for fields; | * header and trailer follow the rules for fields; | ||
+ | * message types are all different; | ||
==== Field/ | ==== Field/ | ||
* types of subfields are visible, parameterized types has required arguments; | * types of subfields are visible, parameterized types has required arguments; | ||
* field names are unique in each field contents scope; | * field names are unique in each field contents scope; | ||
+ | * no cyclic dependencies of fields/ | ||
+ | * however, even with the current naming rules there may be cyclic dependencies in optional_repeated parts and inside case constructs; | ||
+ | * generally every optional parts and case content may have cyclic dependencies; | ||
+ | |||
+ | ==== Constants ==== | ||
+ | * expression in constant' | ||
+ | * constants may not have recursive definition; | ||
===== Language features ===== | ===== Language features ===== | ||
Line 167: | Line 184: | ||
* sibling packages don't merge and don't collide, one defined later is effective, others are ignored; | * sibling packages don't merge and don't collide, one defined later is effective, others are ignored; | ||
- | ===== Things to think about ===== | ||
- | * Diagnostics/ | ||
+ | ===== Naming for C output ===== | ||
+ | |||
+ | There are two generic rules: | ||
+ | * type names are generated with suffix ' | ||
+ | * when there' | ||
+ | * 'one subfield' | ||
+ | |||
+ | ==== Field/ | ||
+ | |||
+ | <C field type> = <Field name>_t | ||
+ | |||
+ | Ex: | ||
+ | < | ||
+ | field A | ||
+ | { | ||
+ | ... | ||
+ | } | ||
+ | |||
+ | typedef struct {...} A_t; | ||
+ | </ | ||
+ | |||
+ | ==== Enum ==== | ||
+ | |||
+ | Enum type: | ||
+ | * if this is the only subfield (so that reduction takes place), <C enum type> = <C field type>; | ||
+ | * otherwise <C enum type> = <Field name> | ||
+ | |||
+ | <C Enum value> = <C enum type> | ||
+ | |||
+ | Ex: | ||
+ | < | ||
+ | field A | ||
+ | { | ||
+ | a : 1 byte { V1 = 1, V2 = 2 }; | ||
+ | } | ||
+ | field B | ||
+ | { | ||
+ | a : 1 byte { V1 = 1, V2 = 2 }, | ||
+ | b : 1 byte { V1 = 1, V2 = 2 }; | ||
+ | } | ||
+ | |||
+ | typedef enum { A_t_V1 = 1, A_t_V2 = 2 } A_t; // reduction | ||
+ | typedef enum { B_a_t_V1 = 1, B_a_t_V2 = 2 } B_a_t; | ||
+ | </ | ||
+ | |||
+ | |||
+ | ==== Case ==== | ||
+ | |||
+ | * <C choice type> = <C container type> | ||
+ | * <C choice type_t> = <C choice type>_t | ||
+ | * case labels (only literals, tag field enum values or global constants may be used): | ||
+ | * for numeric labels <C case name> = case< | ||
+ | * for enum labels <C case name> = <enum label> | ||
+ | |||
+ | Choice is always represented by the following structure: | ||
+ | < | ||
+ | struct <C choice type_t> { <C choice type_t> | ||
+ | typedef enum { <C choice type_t> | ||
+ | union <C choice type_t> | ||
+ | </ | ||
+ | |||
+ | Ex: see case.pdu | ||
+ | |||
+ | ===== Schedule ===== | ||
+ | * finalize naming for the following items: | ||
+ | * exported constants; | ||
+ | * cases; | ||
+ | * ranges; | ||
+ | * arrays of primitive types; | ||
+ | * strings; | ||
+ | * interfaces, derived and nested; | ||
+ | * ? | ||
+ | * separate compiler frontend and backend; | ||
+ | * implement validators; | ||
+ | * implement pack/ | ||
+ | * interfaces; | ||
+ | * optional/ | ||
+ | * alignment; | ||
+ | * type instantiation and deep referencing; | ||
+ | * test; | ||
+ | * presentation; |
etc/users/jcmvbkbc/isl.txt · Last modified: 2016/08/08 20:53 by kel