Open Source & Linux Lab

It's better when it's simple

User Tools

Site Tools

You are here: О нас » /etc... » User pages » Осьмилис/jcmvbkbc/octofox sapiens » Opensource compiler for motorola internal language
etc:users:jcmvbkbc:isl

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
etc:users:jcmvbkbc:isl [2010/08/15 18:50] – + case naming jcmvbkbcetc: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/git/?p=dumb/isl.git;a=summary | Git repo (http)]]
 +
 +[[http://jcmvbkbc.spb.ru:8000/isle/trac | Project tracker]]
  
 ===== Orthogonal aspects ===== ===== 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. 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 ===== ===== 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'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 ===== ===== 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/Message ==== ==== Field/Message ====
   * 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/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 ===== ===== Language features =====
Line 166: Line 183:
     * it treats root package differently than named packages;     * it treats root package differently than named packages;
     * 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;
 +
  
 ===== Naming for C output ===== ===== Naming for C output =====
Line 171: Line 189:
 There are two generic rules: There are two generic rules:
   * type names are generated with suffix '_t' added to the base name;   * type names are generated with suffix '_t' added to the base name;
-  * when there's only one subfield in the field/message/... it gets reduced, like there's no container structure. Subfield gets basic name of its container.+  * 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 ==== ==== Field/message type ====
Line 210: Line 229:
 typedef enum { B_a_t_V1 = 1, B_a_t_V2 = 2 } B_a_t; typedef enum { B_a_t_V1 = 1, B_a_t_V2 = 2 } B_a_t;
 </code> </code>
 +
  
 ==== Case ==== ==== Case ====
Line 215: Line 235:
   * <C choice type> = <C container type>_<tag subfield name>_choice{index, if > 1}   * <C choice type> = <C container type>_<tag subfield name>_choice{index, if > 1}
   * <C choice type_t> = <C choice type>_t   * <C choice type_t> = <C choice type>_t
-  * case labels:+  * case labels (only literals, tag field enum values or global constants may be used):
     * for numeric labels <C case name> = case<case label>     * for numeric labels <C case name> = case<case label>
     * for enum labels <C case name> = <enum label>     * for enum labels <C case name> = <enum label>
  
-Choice with is always represented by the following structure:+Choice is always represented by the following structure:
 <code> <code>
 struct <C choice type_t> { <C choice type_t>_tag_enum _tag; <C choice type_t>_uunion U; }; struct <C choice type_t> { <C choice type_t>_tag_enum _tag; <C choice type_t>_uunion U; };
Line 227: Line 247:
  
 Ex: see case.pdu 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;
etc/users/jcmvbkbc/isl.1281883809.txt.gz · Last modified: 2010/08/15 18:50 by jcmvbkbc