Type Expressions

6 Type Expressions

type-expr	::=	typexpr-def
	\|	typexpr-spec
typexpr-def	::=	{ map (, map)^* } ([integer-literal])^?
typexpr-spec	::=	(signed)^? int {integer-ranges}
	\|	(signed)^? int (integer-literal)
	\|	bool
	\|	ident
	\|	typexpr-spec[integer-literal]
map	::=	(private)^? ident arrow bit-pattern
	\|	(private)^? ident(type-params) arrow algtype-def
type-params	::=	type-param (, type-param)^*
type-param	::=	ident : typexpr-spec
algtype-def	::=	bit-pattern
	\|	bit-pattern # algtype-def
arrow	::=	<= \| => \| <=>
bit-pattern	::=	bits-literal
	\|	integer-literal
type-definition	::=	(private)^? type ident = type-expr

A map-type definition consists of a list of map-type equations and is declared by using the {map (, map)^*} construct. It specifies an enumeration of identifiers that form the abstract values of the type being defined. A map-type can be thought of as enumerated type.

Map-type equation

A map-type equation is introduced by the identifier name of an abstract value, followed by whether a left (<=) or a right (=>) arrow and then a bits-literal or an integer-literal. The identifier on the left-hand side is the name of a value (abstract value) of the type being defined. The value on the right-hand side denotes the corresponding concrete value that is read or written to the corresponding variable. If the identifier name on the left-hand side is preceded by the private keyword, then the defined value is declared to be private to the Devil specification and will not be exported into the generated interface.

{
  ROTATE_IN_AEOI_CLEAR    => '000',
  NON_SPECIFIC            => '001',
  private NOP             => '010',
  SPECIFIC_EOI            => '011',
  ROTATE_IN_AEOI_SET      => '100',
  ROTATE_NON_SPECIFIC_EOI => '101',
  SET_PRIORITY            => '110',
  ROTATE_SPECIFIC_EOI     => '111' 
};

One of the private value of a map-type must be used at least once. Abstract values denote values of the types used in the generated interface. Concrete values are the corresponding bit-strings that are read or written in the register of a device. A map-type equation specifies both abstract and concrete values and defines if the abstract value can be read or written. The left arrow (<=) is used to specify that the concrete value can be read, and that its interpretation must be the abstract value defined on the left-hand side. The right arrow (=>) specifies that the concrete value can be written. The left-right arrow (<=>) can be used as a short hand notation when a concrete value, associated to the same abstract value, can be read or written. As an example, the following map-type equations

  X <= '10',
  X => '10'

are equivalent to

  X <=> '10'

Bit Patterns

If different concrete values are associated to the same abstract value in read map-type equations, then one can use a bit-pattern as a short hand notation. The * (star sign) in a bits-literal denotes any bit. As an example, the following map-type equations

  X <= '10',
  X <= '11'

are equivalent to

  X <= '1*'

Note that patterns are allowed only for read map-type equations.

Type abbreviations

The type-definition rule defines the type identifier name as an abbreviation for the type expression on the right-hand side of = (equal sign). If the type keyword is preceded by the private keyword, the type is not exported to the generated interface. A type declared as private must be used at least once in the Devil specification where it has been defined.

Algebraic types

An algebraic type equation denotes an abstract value which has a concrete representation that depends on values of other types. As an example, assuming that type t₁ is defined as follows :

  type t1 = {
     X => '10',
     Y => '11',
     Z => '01'
  };

one can define type t₂ by

  type t2 = {
    A (x : t1) => '10' # x # '00',
    B          => '110000'
  };

Any Devil type can be used as an algebraic type parameter. The # (sharp sign) denotes a concatenation of bits that forms the concrete value. Note that there is no cost penalty in using algebraic types for writing values. The cost for reading depends on the type representation complexity.