Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000835Taste[All Projects] OpenGeodepublic2019-02-28 16:032019-03-04 09:56
Assigned Tomaxime 
PlatformOSOS Version



I would like to be able to declare my own types in SDL, for example:

ARRAY (T_UInt16, T_UInt32)

DCL myList T_MyIntList;

OpenGeode accepts the NEWTYPE definition (which is legal SDL) but barfs on the declaration:

[ERROR] Type T_MyIntList not found in ASN.1 model - "myList T_MyIntList"

It would be good to be able to use this SDL feature. As things currently stand, I have to include definitions in my ASN.1 data model that are only needed for the internal implementation of the SDL model.

A good example is emulating the "save" symbol: [^]

The SeqOf type is only ever needed in the SDL, but since it appears in the ASN.1, it becomes available as a type across the whole project. It also gets its own encode/decode functions as if it were a message type.

TagsNo tags attached.
Attached Files

- Relationships

-  Notes
maxime (administrator)
2019-03-04 09:56

There are various things to consider here.

First of all, yes, I agree on the fact that local types are useful when you consider the context of a TASTE application. It is convenient to declare types without having to come back to the dataview.

(in the context of standalone opengeode applications, however all types are local anyway.)

There are however some questions and issues.

1) newtype/syntype/synonym (SDL types) vs native ASN.1 type (syntax-wise)

In most cases, the semantics for the types themselves is similar. There is one notable exception for arrays. SDL allows to index arrays with anything:

newtype T1
   array (someEnumerated, someType)

newtype T2
   array (someString, someType)

This is very powerful - the second one is basically like a Python dictionary (or a map).
The first one can be emulated in ASN.1 using named integers:
MyInt ::= INTEGER { first (0), second (1) } (0..1)

But maps don't exist in ASN.1, so if maps and enumerated indexing is what you need, then the SDL syntax is indeed the only option, and other part of the tool to support them would be modified. This is not the most important issue.

SDL also allows to define operators for the custom types, so that if you e.g declare a type named Stack you can define operators Pop and Push that are associated to it. It's useful in some cases but standard procedures can do the same thing (just less OO).

SDL additionally supports the definition of axioms that describe some kind of contracts associated to the types and their operators. This is extremely powerful (in theory) and could be translated to provable SPARK contract at code level.

The tool could therefore support the SDL syntax or directly ASN.1 syntax to declare new types within SDL textboxes. SDL syntax would offer more power but ASN.1 would make it more consistent (only one syntax to learn).

In both cases, we need to define a "reasonable" subset to be supported. Axioms are in the spirit of TASTE but clearly out of short-term scope. Re-implementing a complete ASN.1 parser would be extremely complicated too.

2) Code generation

When you work with variables, the tool generates code that uses the ASN1SCC data structures.
It is therefore essential that the custom types map to ASN.1 types so that the code is consistent.

For example, your array:

newtype SomeArray
   array (T_Uint16, T_UInt32)

needs to be internally translated to

SomeArray ::= SEQUENCE (SIZE (0..65535)) OF T-Uint32

We need to feed this to the ASN.1 compiler to get a structure that is identical to native ASN.1 types and avoid generating custom types in the target language. Otherwise we would need different implementations of the operators (append, length..) depending on the type.

But if we do that, we cannot support maps and enumerated-indexed arrays, since no equivalent types exist in ASN.1

3) Simulation

The simulator is in Python and uses a interface with the generated code using a "ctypes" interface (handled by the DMT tools). This allows to work with ASN.1 from Python to exchange data with the SDL model, fill in the value with the ASN.1 GUI (Value Editor), etc.

The interfaces (PI and RI) are always in ASN.1 but the simulator also allows to inspect and modify all internal variables of the model (this will also be used for model checking).

If we introduce non-ASN.1 types, all this would stop working and would require major refactoring.

CONCLUSION (for now)

The only custom/local types that are reasonably easy to implement are types that can directly map to ASN.1 types (as described in point 2 above).
Syntax-wise, I think a subset of ASN.1 inside SDL would be better than the full-blown SDL syntax, even if I like operators and axioms.

The ASN.1 syntax would use underscores instead of dashes, and would not be case sensitive, making things nicer to the user.
I would start with simple types (integer with single range, arrays, perhaps records and choices) without complex syntax (WITH COMPONENTS, OPTIONAL, DEFAULT)...
and generate an intermediate ASN.1 model to be compiled with asn1sc. This additional step will need some TASTE refactorings.


I did a proof of concept already in the latest version of opengeode (2.0.23)

to get this version and see the example:

$ cd tool-src/opengeode
$ git checkout master
$ git pull
$ pip install --user --upgrade .
$ cd tests/regression/test-newtype
$ make edit
$ make test-ada

- Issue History
Date Modified Username Field Change
2019-02-28 16:03 shd01 New Issue
2019-02-28 16:03 shd01 Status

new => assigned

2019-02-28 16:03 shd01 Assigned To

=> maxime

2019-03-04 09:56 maxime Note Added: 0003579

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker