anuragraghavan / franca

Automatically exported from code.google.com/p/franca
0 stars 0 forks source link

Extension of Franca Deployment Model - Support of different enumerator sizes (8 bits, 16 bits, 32 bits, 64 bits) #138

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Franca deployment model does not offer the possibility of specifying how 
enumerators are encoded (8 bits, 16 bits, 32 bits, 64 bits) for a given IPC 
backend.

Would it be possible to make the type of encoding configurable?

Rationale:
Enumerators are currently encoded as 32 bits unsigned integers.

Enumerators that are supposed to contain only a handful of values may be more 
efficiently encoded as 8 bits unsigned integers.

Enumerators that are used to define bitmasks may need to be encoded as 64 bit 
unsigned integers (in case the number of items is greater than 32).

Original issue reported on code.google.com by resid...@gmx.net on 30 Apr 2015 at 12:19

GoogleCodeExporter commented 9 years ago
In Franca IDL, the encoding of enumerators is not specified (even not as 32 
bits). Thus, it is not possible to use some integer number as default value for 
an enumerator, because there is no implicit conversion from an integer to an 
enumeration type.

However, in the context of a specific code generator (or language binding), the 
actual encoding of enumerations is important. 

IMO, the encoding of enumerations should be specified in the deployment model 
of the respective code generator. The IDL is not the right abstraction level to 
specify this.

Any comments?

Original comment by klaus.birken@gmail.com on 6 May 2015 at 1:46

GoogleCodeExporter commented 9 years ago
I agree that the encoding of enumerators is code generator specific and maybe 
even specific to the different usage locations of an enumeration type. 
Therefore, it is nothing that should go into the interface specification but 
rather into a code generator specific deployment file as it is already done in 
CommonAPI C++.

Original comment by klaus....@intel.com on 6 May 2015 at 3:26