   File   : /home/cvs/cvsroot/projects/visualstate/scope/README,v
   Comment: Implementation notes for SCOPE
   Release: scope-0-16_final

     Copyright (C) 2001-2002 Andrzej Wasowski
     
     This program is free software; you can redistribute it and/or modify
     it under the terms of the GNU General Public License as published by
     the Free Software Foundation; either version 2 of the License, or
     (at your option) any later version.
     
     This program is distributed in the hope that it will be useful,
     but WITHOUT ANY WARRANTY; without even the implied warranty of
     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
     GNU General Public License for more details.
     
     You should have received a copy of the GNU General Public License
     along with this program; if not, write to the Free Software
     Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

   README,v 1.26 2002/10/24 20:17:10 wasowski Exp

   ABOUT

   This file contains notes on implementation of code generation tool for
   IAR visualSTATE. It is a part of my ph.d project at IT-University.

   NOTES

   I belive that we handle nearly entire file structure as implemented
   in visualSTATE 4.0. Only Timer and Do actions are not implemented.

   I. Lexing, scanning and abstract syntax.

   Lexer, scanner and abstract syntax for vsr files has been borrowed from
   Jorn Lind Nielsen, who was working on verification for visualSTATE
   earlier. 

   PORTABILITY, DEPLOYMENT ETC

   	WARNING: currently it is impossible to deploy. Buddy should be
	bundled together (both for windows and linux versions) but it is
	not...

   NOTES on LEXICAL STRUCTURES

	Character constants are not translated to real characters
	internally for the sake of anonymizer.  But they are checked for
	correct escape sequences within lexer. However some non-escaped
	non-printable ascii character constants may still sneak in. I do not
	consider this a problem.

	Tags (portions delimited by [[ and ]], used to be called add-ons by
	Jorn) are lexical objects as whole (simlarly to strings or comments in
	C-like languages). This means that internal structure of tags is not
	examined at all. In contrary to original Jorn's work these are not
	skppied but returned as a specific token, which carries over the
	internal contents.


   NOTES ON (Jorn's) grammar and parsing: 

   	Directives sections is simply ignored by parser (no semantic action).

	Jorn put all the types under one category not distuinguishing
	arithmethic types etc.

	Timer actions are not supported by this grammar (even if Jorn allowed
	it). This is for forcing simpler models. We do not want to concern
	time at all. At least for some time. 

	The grammar for initializing array variables has been added. Currently
	arrays may be initialized with no restrictions on length of
	initialization sequence (which may be anything strongly greater than
	zero).

	Parametrized state machines are not supported at the moment. I
	consider them kind of generic programming constructs (like
	C-templates) -- or I may not be right. Nevertheless I do not think
	they are relevant to my work. Parameter present will just be detected
	as syntax error.

	Constant definitions work a bit like #define and should evaluate to
	numeric (integer or real) value. Formally chars are not allowed
	(according to Reference Guide p. 67), but I included them for
	uniformity. I suspect that they actually are allowed by visualSTATE
	and treated as plain integers (with automatic type promotion in C).
	
	MY VERSION OF GRAMMAR

	The grammar given in rulebase description is cluttered with
	typechecking like properties and lexical analysis like properties.
	Consequently it is hardly readable and usable. I made a new small
	grammar for the most cluttered section of the language (conditions and
	actions). I am not sure it covers the real language exactly, but at
	least correct programs should be parsable this way. I splitted it in
	3 parts: general expressions, conditions and actrions

	This grammar is an extension to what VS implements (my language
	contains their). They only allow direct accesses (no computed dynamic
	accesses).

	1. GENERAL EXPRESSIONS

	lvalue     -> id | id "[" expr "]"
	
	funCall    -> id | id "(" ")" | id "(" parameters ")"
	parameters -> expr "," parameters | expr

	expr       -> lvalue | varval | "(" expr ")" | unop expr | 
	              expr binop expr | funCall

	where binop and unop are all imaginable operators divided into
	different categories by visual state description (arithmetic,boolean,
	comparison, bitwise, etc). "varval" is the rulebase name for
	constants (decimal, real or boolean).

	Operator precedence is defined as in Ansi C (Section 2.12,
	K&R) wrt limited set of operators.

	2. CONDITIONS (sometimes  called GUARDS)

	condition     -> event guardDefSeq | event
	event         -> id optionalMembers
	guardDefSeq   -> guardDef  | guard guardDefSeq
	guardDef      -> stateName | "!" stateName | "[(" expr ")]" | "[|" expr "|]"
	
	Note that what model-checking people call guards is called negative
	and positive state conditions in visualSTATE. These are two first
	cases in guard production.  Also actualParams should be used in
	grammar elsewhere. I hav the impression that this construct appeared
	here and there.  

	3. GRAMMAR FOR ACTIONS

	actionSeq     -> action actionSeq | action
	action        -> "#" funCall | "[(" lvalue "=" expr ")]" 
	                 | stateName | ^id () | ^id

	Note that actionSide may never be empty, since at least next state
	condition must be included (last case in action production). If it is
	actually there you should check within Semantic analysis. 
	
	The last case of action (^id) is issuing a signal. Parameters are not
	supported for signals (in current visualSTATE), but empty brackets
	are allowed.

	visualSTATE distuingishes two kinds of expressions (better say:
	actions - they use of terminology is not very consistent): internal
	and external. Internal actions can only modify internal entities,
	external kan modify anything. They have a syntactical difference
	between them using different delimiters [| |] and [( )]. I think that
	the difference is actually semantical and disregard this syntactical
	difference for purity. Grammar is smaller then. If we ever need to
	classify actions this way it housl be done in semantical analysis
	(similarly to escaping/nonescaping parameters in standard C compiler).

	4. GRAMMAR FOR TAGS

	Tags are parsed as comma separated lists of 'assignments'. Left hand
	side may be any lexically correct identifier and RHS is a string.
	Some tags are specially recognized and parsed again (using local
	parser built with parser combinators). Those are put into special
	tags under vsr.tagfield datatype. All others are returned as
	vsr.PlainTag values which also belongs to tagfield datatype.
	PlainTag provides support for all the tags we do not care about (and
	all not recognized tags).

   PROJECT FILES, SYSTEMS, HANDLING OF MULTIPLE FILES

   	Officially project files have vsp extension and program (modules or
	however you call them) files have vsr extension. This parser does not
	look in to file name's extension. It only looks into the structure of
	the file to recognize the specific kind of file. This can be easily
	done by @Project and @RuleBase keywords in the preamble.

	One project may contain several systemsis very common though (one
	system per project is very common though). Each system may contain
	anything from one to any arbitrary number of vsr files.  Only state
	machines in the same system may refer to each other (via parameters
	or locally in guards etc). 
	
	Distinct systems within the same project may not communicate
	directly. Project file contains signals and internal variable
	sections, but they are not used currently (sections should be empty).
	Consequently there is no _clean_ way to communicate between systems.
	One can still do it in some implicit ways -- using implicit state in
	C functions or external variables. Yuck.

	Proposed way to parse project files (project file + associated set of
	files) is to mimic visualSTATE behaviour. If the tool is run with
	single vsr file as parameter then we simply process given file. If
	the file happens to be a project (vsp) file we process it, then
	extract the list of dependent vsr files and sequentially process them
	one by one using the same symbol table. In this way the symbols are
	anonymized uniformly in the whole project.

	Parsing of vsr file returns a syntax tree of certain program (vsr
	module). Parsing of vsp file returns an AST of project file with 
	associated vsr files as subtress. Code generation routines 
	receive the whole model in single uniform AST.

   NOTES ON ABSTRACT SYNTAX

	This abstract syntax is generally slightly to low-level. For example
	ranges of ranged types (or array sizes) are not kept as integers
	directly but encapsulated in Literal datatype preserving their
	original format (hex/dec/char/real). Whenever you see a bit too low
	level innformation being preserved in abstract syntax it is very
	probably due to the anonymizing part of the tool which I would like to
	save as much nice information as it can so we can later on better
	understand the examples. I do not exclude the possibility of
	developing of even MORE ABSTRACT SYNTAX to get rid of this features in
	priniting.

   	In current abstract syntax there is no way to distinguish between an
	event which is unparametarized and an event which is parametarized
	with no parameters (i.e. with unit parameter). I cannot work out if
	this two things really differ in visual state and if the EVENT() thing
	even exists. I simply accepted this abstract syntax and I always
	assume that anything of the EVENT() kind will be treated exactly as
	EVENT itself (this is the intended approach in translation/generation
	stage).

	Modified the treatment of explicit constants in lexer/parser and
	abstract syntax. Jorn only allowed integer constants written down in
	decimal radix.  I preserve the exact representation of numerals (hex,
	dec and real) in abstract syntax in order to print them correctly in
	the anonymizer. For this reason real numbers are stored in strings in
	abstract syntax (they can get printed out exactly in the way they have
	been read in). The type is called 'literal' for all explicit constant
	values (whatever the type is) and it preserves the real representation
	of the source file.

	Two "weird" entites are introduced. "funspec" represents a restricted
	version of C prototype (used for actions), while "recspec" represents
	all things a function has, but no return type. "recspec" is used to
	represents events and signals. There was a posibility to make a
	return type an option in functions and use this one, but 
	except for similar syntax I belive that events and actions have not
	much in common. Events (and signals which are like internal events)
	resemble records in that they have a name and they may carry a number
	of values which are also named (and typed). This explains the name
	for recspec. 

	Tag appended to @Implementation keyword is accepted but not passed
	forward by parser and it is not preserved in abstract syntax.
	According to IAR the absence of this tag in resulting file (in case
	of typechecking or anonymiazing) is not harmful. Thus I decided not
	to clutter abstract syntax with this (actually there was no nice
	place to plug it in within Jorn's strategy).

	The treatment of tags is peculiar. All tags are parsed by parser (and
	defined by grammer) as pair lists. Each pair is an assignment of
	string value to field dentifier (any proper id can be an identifier).
	These tags are called PlainTags in abstract syntax. Tag itself is a
	ML datatype incorporating other possibilities (system anme tag, file
	path tag and instantiation/call tag). These extra possibilities are
	never used buy mosmlyacc generated lexer (it always produces PlainTag
	values), but some of PlainTag values are parsed more finely later on
	and translated to some other Tag types if required.  This is done in
	parse.sml "postprocessing". Sorry for that -- module language in
	visualSTATE is very badly designed.

   HIGHER-LEVEL ABSTRACT SYNTAX (THIS WORK HAS BEEN SUSPENDED)
   SEE BELOW ON TRANSLATING TO ABSYN SYNTAX

   	There are only two levels of interface: project level and model
	level. The scope of stateMachine has been eliminated. Also note that
	the transforming function (TODO) should take care that this two
	scopes do not overlap: any project level names should not be included
	in model level interface.

	There is no special representation for internal transition. A
	and-state (this is a new name for region in this AS) containing an
	internal transition is translated to an and state with self
	transition as a direct substate of the given region. Then one region
	(and-state) is created in the new state and the previous content is
	placed there (TODO) 
	
	I split the states into "or" and "and" states instead of regions.
	This make the AST deeper, but the treatment is more uniform and UML
	like. This should help to publish results in UML framework. I also
	think this is cleaner. This brings a slight difference in naming
	conventions. Now we use or-state (used to be region) names building
	fully qualified names while regions where not used in these paths in
	visual state. Just be careful when speaking with visual state people.

	FIXME => Check with UML definition if my names of or and and-states
	are appropriate.

	There is no special treatment for systems. Systems should be
	translated to one model with new topstate and several and-states
	below containing given models. FIXME => this is not good. Sounds
	like much less efficient than in current visual state implementation
	where user switches between systems. Then only one system is involved
	in evaluating the event. In above solution all systems would be tried
	which is not good as only one of them should actually react (at least
	user should be able to choose which one). Perhaps it is sufficient 
	limit ourselves to one system projects and forget about the problem.
	Let us see what examples can we get.

	FIXME => I feel very tempted to compact events and signal types into
	one type with no distinction. I have the impression that it is
	enough to typecheck if only internal events are called. Otherwise it
	should be no difference in treatment. I am only not sure if really
	there is no difference (perhaps we can do more for signals than for
	events as we may exactly find out when they occur).

	I have made ranges compulsory on this level. So for variables of
	scalar types we have to introduce full ranges. (???)

	VisualSTATE only allows intialized constants -> test it. Thus we can
	create an environment for constants and make it the part of the model.
	All constants in expressions are translated directly to literals with
	use of this environment. Then we need a typing function which
	assignes a minimal type for given literal.

	I use one type ("prototype") for defining both functions and events
	(+signals). In case of events I assume that the return type is
	irrelevent (fill it with void - perhaps the safest thing to do).
	FIXME => Perhaps all this will go to symbol table.

	TODO => There is no abstract syntax for do reactions, termination
	transitions and final states. These are transformed directly to
	another state machine contained in the fresh or-state with new direct
	finalizing and leaving transitions as described in
	papers/questions.txt Q15.

	FIXME => This is also partly type checking (but I think we combine
	this translation with type checking). Where no intial state is
	specified in the machine we can follow coder way to treat  it - mark
	the first state in machine to be intial. See Q26. for more information
	on that - sometimes there is no reason to initialize a state machine
	as it will be reinitialized anyway (exactly like with variables in
	imperative languages). Perhaps there is a space for a small
	optimization there.

   NAME SPACES, SCOPES etc.

        CAUTION!!: this section is based more on beliefs than real
	knowledge.

   	I belive there is one sort of name spaces for all entities. So
	events, state machines, states and signals must have distinctive
	names. Although there might be possible some name overlapping with
	local nesting scopes as described below.

	Some names are declared in interface preamble of each vsr (or vsp)
	file. These include: events, actions, internal/external variables,
	constants, event groups and signals (some have also external
	defintions - f.eg. action functions, and some would have definition
	in place together with declaration - f.eg. event groups). I belive
	scoping rules for those names declared in preamble is very simple.
	
	i) Names declared in project preamble are visible in all modules.

	ii) names declared in module preamble are visible in whole module
	(and not outside).
	
	Events is a bit of a different story (probably). I guess all events
	and signals should have global names (since the event generator is
	often a global function).  

	The rules for state names scoping: states may only be used in the
	machine where they have been declared. If a machine needs to use a
	state up in hierarchy then the state needs to be explicitly declared
	as a parameter of state machine. The name used as formal parameter in
	@StateMachine or @TopStateMachine is local in the following
	definition of state machine. The binding with real (actual)
	parameters is performed in place where the state machine is
	instantiated as a nested state. The only "type" information to check
	is if the actual parameters are type names indeed.

	Next corollary is that state machine can only access states in the
	same vsr file (regardless of direction: both up and down hierarchy).
	States and machines are not defined/declared in interfaces so they
	may not be global. The whole state machine has to originate from one
	file (with all nested state machines) and may not access state
	machines from other files (even in guard conditions, etc).
	This simpifies code generation slightly.

	FIXME => Nevertheless: the first idea is to forget about the above.
	We compact all machines of the system into one model in higher level
	AST. This gives more uniform treatment.

   TRANSLATING VSR AST TO ABSYN AST

        Absyn.sml defines abstract syntax following the structure of
	semantics presented in paper "On the formal semantics of VS
	statecharts". 

	Absyn.sml is restricted comparing to vsr. For instance no sharing is
	allowed etc. Still my restrictions allow all things which are
	currently considered well typed in vsr (for instance sharing is not
	allowed semantically). Absyn is even more general in some aspects.
	ORstates are becoming fully-fledged states (regions are not really
	states in vsr), so they can be parts of pos/neg conditions, targets
	etc. (currently this is forbidden to conform to visual state). Also
	state name scope is strongly its parent. Each region may redefined
	the same state name locally (in vsr scope of state name is its
	and-parent, bcs regions are not really states).

	I reverse-engineered the naming convention in VS. There is a problem
	with name abundance. At first sight some objects get several names in
	vsr files and only one of them is user given. For instance state name
	is user given but then the state may contain a state machine having
	another name, only occasionally given by user. 

	The guess is that state machine names are always irrelevant in VS 4.3
	(tool generated) except for the TopStateMachine and Do state
	machines. The latter we currentlydo not habdle (12/05/2002). Former 
	should get its name instead of giving it a typical "root" or
	"topstate".

	Certain problem is exhibit with transitions referring to parameter
	states of state machines. This is solved by expansion of parameters
	from current nesting environment recursively in top down manner
	(expandtran function). 

	Another problem is fully qualified stte names. mkhierarchy returns a
	list of transitions which are fully qualified but perhaps not
	correctly (some orstates might be left out). This is because regions
	are not really states in vsr. The problem is corrected
	in second pass to insert missing intermediate states. 
	




   NOTES ON TYPECHECKING

   	"Declaretedness" of all names has to be checked according to the
	rules below. Environments should be implemented similarly as they are
	in tiger compiler.

	Typechecker will work simultanously with vsr -> hvsr translator to
	some extent. This typechecking is going to be liberal (C compiler may
	still do something more) but sufficient. For instance we will treet
	or integer values (together with boolean) as one integer entity.

	FIXME => There is no location information currently to return when
	typechecking error is detected. I should decorate vsr with locations
	(ONLY WHERE NEEDED).  

   	Directives are checked for presence (only @Field is optional,
	visualSTATE, Data and Time are compulsory). This is both enforced by
	syntax and type checked as the abstract syntax may come both from
	syntactical anayglysis or from some transformation/generation
	algorithm.

	FIXME => typechecking ranges should assure that both limits are of the
	integer or character type.

	FIXME => Currently I allowed any expressions to involve any varval
	which means any numeric (float/int) or character constant. Just give
	it a thought if this expressions should not be typechecked then...

	FIXME => also I do not know if var initialization are typechecked
	(both if initital value fits in type and in the range). The value
	should agree with the type and range of the simple variable and all
	the cells of the array ini string should agree with cell-type (and
	perhaps range - still wait for IAR to reply). The length of the string
	shall not be checked however (according to IAR). The semantics of code
	generation would be to initialize part of the array if ini sequence is
	shorter and to ignore the tail if its longer than declared array size.
	READ HERE: Currently vars are not type checked at all. After variable
	abstract syntax redesign I cut away all Jorn's type checking code on
	variable declarations as it was not useful anymore.
	
	FIXME => whenever an array is declared I allowed any Literal as size
	value, but please do type check if it is not float (integers and
	characters are allowed like in C)

	FIXME => type checking for actions does not exist. Possibly I could
	use the same routine as for external events. check it. Note that
	checkAction is a faked function (constantly true).

	Syntax of constant definitions assures their correctness. There is
	nothing to type check as far as I see at the moment (IAR still have
	to clarify this).

	FIXME => Event Groups are not type checked at all (the predicate is
	always true). It is not clear what are the conditions that should be
	imposed, but at current stage I would not like to ask IAR about it.
	Do it when implementing typechecking.

	FIXME => Signal specifications are not type checked at all.

	FIXME => Remember that machines list (part of program implementation)
	should not be empty (hmmm... this is probably not true. ask IAR).

	FIXME => Carefully examine constructs that were only introduced to
	the language to allow saving of incomplete projects (at any stage of
	drawing). This include empty EventGroups. May be some more. This
	things should not be allowed in the tool.

        TYPING RULES for EXPRESSIONS

   UNPARSING / PRETTY-PRINTING (?) / SAVING

        The first recursive version of Unparse.sml happened to be highly
	ineficient. I never thought that this is going to be an issue, but
	actually it happened. The inefficiency became an obstacle when I used
	the module in little companion utility txt2vsr (separate source
	directory). I discovered that Unparse is a bottleneck of the whole
	algorithm (even if some quadratic searches where done exhaustively in
	other parts of utility). A bt surprising. Further investigation was
	that concatanotion operator op^ is highly inefficient. Especially
	when you build a big thing from many chunks. I happened to build
	magabyte string from several bytes chunks. Each application of ^
	duplicates it operands in memory. So even if you only want to add
	one character it may be very costly (if the other operant is several
	hundred kilobytes size).

	As a result I decided to improve the unparsing algorithm. While
	keeping the same structure of functions (not a single function was
	added or even commands reordered). I added accumulating parameter to
	many functions (only left very little functions to operate in old
	recursive way) and used backwards algorithm. Thus we now generate the
	text of the model from the end towards the begining. This is a common
	approach due to properties of applicative lists (it is expensive to
	add something in the end). Visually some concatenation were displaced
	with list constructors and some others where moved to accumulating
	parameter passing. The whole thing is by no means optimal now (I mean
	there are still more little optimizations to be done), but the main
	bulk is squeezed from it. It operates nicely and fast even for big
	examples.

   NOTES ON SEMANTICS

   	ARRAY INITIALIZATION: sequence of values can have any length, thus it
	may happen that only a part of array is properly initialized or that
	tail of the sequence is ignored.



   INTERPRETER IN Interpr.sml

        I do not call C functions in interpreter. Instead I generate a global
	list of oinsts (output instances) in order they appear. This adds a
	new component to global state which was not described in semantics
	paper. It will not be present in code generetor (naturally replaced
	by actual C function calls).

   CODE GENERATOR IN CodGenC1.sml

        Hierarchy is explicitly represented.

	Only ANDStates are material at runtime.

	Actions are not reused (a function is generated for each single
	action and guard). Sharing is not sued at all for now. All tables are
	just lists which concatenate elements in the begining. Should be soon
	to proper interfaces in style of BDD MK operation.

	Outputs are not optimized (always wrapped into may function call).

	Dead events and signals are not eliminated. Dead transitions and
	states are not eliminated.

	Tarjan's algorithm for LCA computation is not employed. We use a
	trivial algorithm.

   NOTES ON RESTRICTION OF MODEL:

  	1. SE notation is not supported                  
                                                         
        2. 64 bit integer types are not supported
        3. 32 bit unsigned integer type is not supported

   EXTENSIONS TO THE MODEL LANGUAGE:

   	Arthmetic expressions, signal expressions and output expressions
	(function call expressions) have been made orthogonal, so now an
	exression can be used as function parameter or array index (or signal
	expression parameter).

	Names of fields in signal and event declarations are made
	meaningless. The order matters as in C (and as it used to be). So the
	names in bindings of events and signals are resolved using order. A
	bit less safe, but I think a bit more natural. STILL ARGUABLE.

   ANONYMIZING ALGORITHM

        The anonymizer is purely syntactical by assumption. The typechecking
	is possibly performed to reject incorrect files, but no results of
	semantic analysis are used in anonymizing algorithm. Thus some
	elements of semantics are preserved in syntax (exactly as it is done
	by IAR). May be it is not very good, but this allows to finish
	anonymizer before a full Semantic analysis is implemented.

   NOTES ON TRANSLATION TO HSE

	I disontinued support for VsrHse module from Jorn. I decided that it
	is to much work for me to make it agree with new features of the
	visualSTATE language I consider (it is probable that I would need to
	extend Jorn's language and I do not want to do this). At the stage I
	left it it did not even compile (bcs of changes in naming and types).

   DESCRIPTION OF AVAILABLE  STATISTICS

	The meaning of fields returned by scope -s is as follows:

	system - name of the system given
	states - total number of states (inluding top state, and states,
	 	 orstates and basic states)
	and    - the number of andstates (including basic states and
	         topstate)
	basic  - the number of basic states
	cb     - confbound: statically computed bound on size of active
	         configuration set
	depth  - depth of the model (empty model with single topstate has
	         depth 1, model containing any states is autmatically depth
		 3 because orstates are included in this count as well);
	lvl    - length of the longest vertical list of vertices in the model
	         (starting at andstate, including orstates). See notes all
		 algorithm in Stat.sml for details.
	

   NOTES ON TESTING

   1. anonymizer/typechecker should work on it result (circular aplication)
   2. anonymizer/typechecker should produce a fixpoint of transformation
      (so the result of applying to the result should yield the same result)

   XXIX. REFACTORING TO-DO LIST

   There is a huge set of rules for expressions in grammar definition. Factor
   out a rule for binary expressions.

   XXX. OPEN QUESTIONS LIST:

   1. I excluded timer actions from current considerations. Will including
   timers would change anything? Actually they probably do not spoil anything
   if there are pure function (not depending on state, but just reacting on
   outside environment). But even if they depend on state some things can be
   done certainly.

   2. It's quite obvious that performing floating point operations is much
   more expensive. Also fpu instructions are not normally implemented in
   embedded systems (I do not know about dsp'es). Special library routines
   need to be linked in if program uses floating point oeprations. Does
   visualSTATE deal with the problem somehow?

   XXXI. TODO

   1. add more test cases in test/parser (now you have them)
   2. Improve the test procedure (so errors are more easily visible)
   3. Unparse.sml and Typeset.sml need to be typeset in 80 char width
   4. CoderCommand is parsed and translated by parser. Very badly it has
      not_a_path assigned as a vale (regardless of what was in the file.
      Then Unparse discards CoderCommand regardless of the anonymizing mode.
      Fix it.
   5. Handle 32/64 bit types (this may be needed for signal processing).
      Apparently this is a wide application area which should be treated well
      (you can have 64 bit registered in DSP with very small memory I
      belive).
   6. Create example (under compilable) of famous Citizen Watch owned by
      D.Harel [Harel 87]
   

