Bitwise operators in OAL

Home Forums BridgePoint Development and Integrations Bitwise operators in OAL

Tagged: 

This topic contains 14 replies, has 6 voices, and was last updated by  john 6 days, 6 hours ago.

Viewing 15 posts - 1 through 15 (of 15 total)
Author Posts
Author Posts
July 27, 2018 at 1:02 am #6143

John Wolfe
Participant

To build a domain that knows how to encode, decode, and interpret a message protocol, bitwise operators in OAL would be very useful (e.g., bits 3-5 of byte 1 contain the message length).

Is anyone else craving bitwise operators in OAL?

July 30, 2018 at 7:20 pm #6144

keithbrown
Keymaster

I have wished for them before and I know other users have as well. In fact, one of the MASL-oriented engineers said this year “MASL doesn’t have bitwise operators, but we’ve often wished it did… maybe we’ll add them one day.”

Apparently this is one of those things that just never quite gets enough traction to make it happen!

July 30, 2018 at 7:43 pm #6147

Lee Riemenschneider
Participant

It never gets much traction, because it’s an implementation concern, not an analysis concern.
e.g., message length occupies bits 3-5 of byte 1 is something you specify in the model compiler for class, message, that has attribute, length.

July 30, 2018 at 9:13 pm #6148

John Wolfe
Participant

@Lee, perhaps I have been thinking about this incorrectly. Message length is but one of many fields — I used it only as an example. Suppose the protocol in question carries all sorts of information that must be extracted from bit fields within bytes (e.g., message length, message type, sensor ID, sensor values, etc.).

Consider how to build a domain that knows about this protocol and how to convert between messages packed into a byte stream and xtUML interface messages. Can you think of a way to do so without coupling the model compiler to the protocol?

In our case we would prefer to use MC-3020 as is.

July 30, 2018 at 11:40 pm #6149

Lee Riemenschneider
Participant

Here’s what I was thinking. The message structure as a class. Class and attribute mark that allow the code to match the byte stream representation.
You probably have something more complex, where a header has to be unpacked before the rest of the message can be processed, which makes my solution a mess of bridge calls. Maybe it’s a bad problem space for xtUML.

July 30, 2018 at 11:50 pm #6150

John Wolfe
Participant

Actually, I think it’s a good problem space for xtUML, as such a domain would allow us to generate code for the protocol in a number of different languages, while maintaining the knowledge of the protocol in precisely one place.

@Lee, are you saying that a need to examine bit fields within bytes (which causes the craving for bitwise operators) makes an application ill-suited for xtUML?

July 31, 2018 at 12:53 am #6151

Lee Riemenschneider
Participant

Bitfields in bytes are a physical storage packing mechanism for a specific implementation of data optimization. The idea of packing and unpacking in the smallest unit of storage might be a domain. Bit fields within bytes are the smallest unit of storage in some languages, but not all. How can we say it is implementation independent enough for inclusion in an AL?

July 31, 2018 at 4:32 am #6152

John Wolfe
Participant

>How can we say it is implementation independent enough for inclusion in an AL?
Because many other languages, including at least three that treat platform-independence as a primary requirement, do so?

But, let me try to restate the requirements because bitwise operators may be but one solution to the problem at hand.

At its core, this problem is one of mapping a collection of bits to a named field (ref. examples in previous posts). In some cases a field spans multiple bytes while in others it is contained within a single byte.

Ultimately, I would like to build a domain that knows how to:
1. Convert between a stream of bytes and a collection of instances of classes, where class attributes represent message fields. This semantic mapping between a bit field and a semantically named attribute is the crux of the problem.
2. Convert between these class instances and xtUML interface messages.

Bridge operations can likely be used in place of native OAL bitwise operators. But, perhaps I have been staring for too long at hand-written, imperative code that uses bitwise operators to map between bit fields and named message fields (semantics).There may be other approaches that meet the requirements while leveraging existing tooling without coupling the resulting model to non-existent model compiler features.

July 31, 2018 at 2:38 pm #6153

bgat
Member

Bitfields in bytes are a physical storage packing mechanism for a specific implementation of data optimization.

Bit fields are TWO very useful things, one of which is a storage packing mechanism.

The other, even-more-useful thing that bit fields provide is atomic, parallel evaluation of multiple related binary conditions. You can do that without bit-aware operators, but the math gets fairly blush-inducing unless you do cryptography on a regular basis.

When I use a bit field in a condition variable, I don’t care about the underlying representation because the value itself is never expressed outside of the scope where I’m using it. (I’m barely even a novice in xtUML, maybe condition variables have no equivalence there.)

  • This reply was modified 1 month, 2 weeks ago by  bgat.
July 31, 2018 at 2:44 pm #6155

bgat
Member

When I say “atomic”, I mean in the language “I can do this all on one line” sense. Maybe “concise”, or “terse”, or even “convenient” are better word choices…

Although it’s reasonable to presume that the underlying implementation supports atomicity, I don’t depend on it unless I’m working in a language that explicitly guarantees it.

July 31, 2018 at 5:07 pm #6156

cort
Keymaster

I would like to see the additional operators in OAL and yet am not sure explicit masking-in of bits is the best approach. Maybe something more declarative rather than imperative…

There is (was?) support in MC-3020 for marking bit fields on attributes (in the comment block) of classes.

Also, a feature to “fix” the extent at a specific location in memory was provided:

https://xtuml.github.io/docs/mcug/ch04s02.html#idm269943694752

What are your thoughts on this? If it worked, would it be a workable approach?

July 31, 2018 at 10:12 pm #6157

Lee Riemenschneider
Participant

[My last reply must have gone to the ether…]

I’ve encountered whole messages and partial messages. Partial messages have come ordered and unordered; one byte at a time or larger chunks, and I’ve seen bitfields across byte boundaries. I’ve never taken a communication domain model to production. (Leon Starr once told me he was working on one, but I never heard if it got finished.)

Field extraction and recombining was done through bridges.

July 31, 2018 at 10:23 pm #6158

Lee Riemenschneider
Participant

Condition variables equivalence in an xtUML model would be a Flag class with a many to one relationship with a thread. ;-)

“concise” isn’t a goal of class modeling in xtUML, whose goal is to expose information. It can be a goal of the model compiler.

August 2, 2018 at 1:37 am #6159

John Wolfe
Participant

@cort, maybe. Messages vary in length from one type to the next, but each message of a given type is the same length. Fields contained within messages vary from one type to the next. There are over 100 different message types. We could create a class for each message type with attributes leveraging the bitfield capability of MC-3020. If, upon arrival, the byte stream containing a message could be plopped at the base of the extent for the appropriate class, we could avoid imperative bit-whacking, so long as the content of a message does not vary with anything other than the message type. I have vague memories of “if byte 5, bit 3 is active, then bytes 6-7 contain this, otherwise they contain that,” so I need to have a closer look at the protocol.
I have sketched (in my head) the specification-class side of a model that once populated would describe each message type. This approach might eliminate the need to define a class for each message type (instead each one would be defined as preexisting instance data) or leverage the aforementioned model compiler features, but I need to find time to extract said model from my head and try out what I have in mind. However, it’s likely that using PEI data to define message structure is less convenient/accessible than doing so with classes.

September 12, 2018 at 5:17 pm #6179

john
Participant

Here are my two cents without reading through the entire discussion.

If the objective is to ‘just’ implement something like this, do it in C. It is both fast and easy to implement. I love C, but it sucks at communicating abstractions. If your objective is to explain the concepts of the solution to somebody other than yourself, model it with classes, state machines and associations. If the objective include both of the above, then you need to compromise. Runtime performance and time spent on implementing the solution, vs explainability, maintenance and so on.

I believe that and introduction of bitwise operators into the action language makes it harder to use xtUML methodology as intended.
In my experience, expanding a language to capture low-level encodings of problem tempts users to abandoned the quest for abstractions, and make compromises like the ones stated above without realizing it. Heck, why not allow inline assembly in OAL?

I can give you another example that would simplify the implementation of a solution in xtUML with a richer action language: an SQL parser. There are two common approaches, a handcrafted pattern matching tokenizer with a handwritten recursive decent parser, or regexp + parser generator with a DSL. Neither approaches are good at communicating HOW the implementation works, which is why I modeled it in BridgePoint using classes and state machines. Granted, I was unable to model the tokenisation well, I basically took my old C tokenizer and rewrote it in OAL, thus adding no new value in terms of readability etc. However, If you have no previous experience on LALR parser generators, you are likely to understand how an SQL parser works just by reading my model. It took a lot of time and energy implementing the model, but in the end, I think I managed to communicate the solution pretty well. Also, the parser is platform independent, and actually performs pretty well once I tweaked the model a bit.

Viewing 15 posts - 1 through 15 (of 15 total)

You must be logged in to reply to this topic.