Differences

This shows you the differences between two versions of the page.

--- etc:users:jcmvbkbc:isl [2010/08/15 13:43] – jcmvbkbc
+++ etc:users:jcmvbkbc:isl [2016/08/08 20:53] (current) – ↷ Page moved from users:jcmvbkbc:isl to etc:users:jcmvbkbc:isl kel
@@ Line 2: / Line 2: @@
 [[http://jcmvbkbc.spb.ru/git/?p=dumb/isl.git;a=summary | Git repo (http)]]
+[[http://jcmvbkbc.spb.ru:8000/isle/trac | Project tracker]]
 ===== Orthogonal aspects =====
@@ Line 56: / Line 58: @@
 When the header is absent Param1 corresponds to the trailer. If there's no trailer, its parameter number corresponds to the signal data.
+Interfaces visible from root package, not referenced from other interfaces visible from root package get translated to pack/unpack.
 ===== Decoding context =====
@@ Line 121: / Line 125: @@
 Only mandatory fields may have LengthRestriction > 1.
+===== Derived interfaces =====
+  * if derivation is by inversion, another interface is created and parent's pack-only messages become its unpack-only and vice versa;
+  * 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 =====
@@ Line 128: / Line 137: @@
   * every pack/unpack message has corresponding messagetype;
   * header and trailer follow the rules for fields;
+  * message types are all different;
 ==== Field/Message ====
   * types of subfields are visible, parameterized types has required arguments;
   * field names are unique in each field contents scope;
+  * no cyclic dependencies of fields/messages (mt does not allow it);
+    * 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's definition may only refer to other constants and literals;
+  * constants may not have recursive definition;
 ===== Language features =====
@@ Line 167: / Line 184: @@
     * sibling packages don't merge and don't collide, one defined later is effective, others are ignored;
-===== Things to think about =====
-  * Diagnostics/error handling
+===== Naming for C output =====
+There are two generic rules:
+  * type names are generated with suffix '_t' added to the base name;
+  * when there's only one subfield in the field it gets reduced, like there's no container structure. Subfield gets basic name of its container;
+    * 'one subfield' is literally one subfield. Presence of the special-purpose subfields that would not get into the structure or constant fillers cancels reduction.
+==== Field/message type ====
+<C field type> = <Field name>_t
+Ex:
+<code>
+field A
+{
+...
+}
+typedef struct {...} A_t;
+</code>
+==== 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>_<subfield name>_t;
+<C Enum value> = <C enum type>_<Enum value>
+Ex:
+<code>
+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;
+</code>
+==== Case ====
+  * <C choice type> = <C container type>_<tag subfield name>_choice{index, if > 1}
+  * <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<case label>
+    * for enum labels <C case name> = <enum label>
+Choice is always represented by the following structure:
+<code>
+struct <C choice type_t> { <C choice type_t>_tag_enum _tag; <C choice type_t>_uunion U; };
+typedef enum { <C choice type_t>_tag_enum_<C case name>, ... } <C choice type_t>_tag_enum;
+union <C choice type_t>_uunion { <C choice type>_<C case name>_t <C case name>; ... };
+</code>
+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/unpack;
+    * interfaces;
+    * optional/mandatory;
+    * alignment;
+    * type instantiation and deep referencing;
+  * test;
+  * presentation;