Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 366798 - make primitive types part of the model
Summary: make primitive types part of the model
Status: CLOSED FIXED
Alias: None
Product: eTrice
Classification: Modeling
Component: Core (show other bugs)
Version: 0.1.0   Edit
Hardware: PC Windows 7
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard: 0.2.0M1
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-15 05:27 EST by Henrik Rentz-Reichert CLA
Modified: 2012-03-28 05:12 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Henrik Rentz-Reichert CLA 2011-12-15 05:27:12 EST
In bug 366782 a problem of porting a model to Java is described.
This is due to the fact that Java doesn't support unsigned integer types but ROOM has them in the list of primitive types.

A general solution for this could be that primitive types are modeled too.
E.g.

PrimitiveType JavaPrimitives {
  int8 -> byte
  int16 -> short
  int32 -> int
  // etc.
}

Then this could be used in an ActorClass like

ActorClass Act {
  Structure {
    Attribute number: JavaPrimitives.int8
  }
}

A standard collection of primitive types could be defined as part of the modellib.
Comment 1 Thomas Schuetz CLA 2011-12-15 17:35:09 EST
for more convenience I would suggest:

PrimitiveType int8 -> byte
PrimitiveType int16 -> short
PrimitiveType int32 -> int
  // etc.

this would allow a shorter notation:

ActorClass Act {
  Structure {
    Attribute number: int8
  }
}

imho the clustering of PrimitiveTypes (e.g. JavaPrimitives ) is not needed
Comment 2 Thomas Schuetz CLA 2011-12-15 17:44:16 EST
for future functionality, especially model checking and test generators more detailed information about the types will be needed

PrimitiveType int8 -> byte {
  range=-128..127
}

There might also be requirements for more exotic types

PrimitiveType int40 -> int40 (on some DSPs)
PrimitiveType fixed1616 -> fixed1616 {
  fixpoint=16.16
}
Comment 3 Henrik Rentz-Reichert CLA 2011-12-16 02:27:27 EST
(In reply to comment #1)
> imho the clustering of PrimitiveTypes (e.g. JavaPrimitives ) is not needed

I thought clustering those type declarations in a namespace would be a good idea.
But if this is desired it can be achieved by moving the declarations to a separate model.
This would allow one to write

RoomModel JavaPrimitiveTypes {
PrimitiveType int8 -> byte
PrimitiveType int16 -> short
PrimitiveType int32 -> int
  // etc.
}

RoomModel MyModel {
import model "JavaPrimitiveTypes.room"
ActorClass Act {
  Structure {
    Attribute number: JavaPrimitiveTypes.int8
  }
}}

or by importing the namespace

RoomModel MyModel {
import JavaPrimitiveTypes.* from "JavaPrimitiveTypes.room"
ActorClass Act {
  Structure {
    Attribute number: int8
  }
}}
Comment 4 Thomas Schuetz CLA 2011-12-16 03:35:29 EST
That is exactly how I would use the type definitions.
Every Project can define the types in a separate model.
Comment 5 Henrik Rentz-Reichert CLA 2012-02-27 13:24:26 EST
Done with
12d085d0c849291049c7fe1bf82508570518d592
Comment 6 Henrik Rentz-Reichert CLA 2012-03-28 05:12:53 EDT
closing bugs that went into 0.2.0M1