按位结构定义语言生成C ++代码

Question

Before any question is asked: I am dealing with actual hardware.

I am searching for a meta-language that would allow me to specify data structure contents where fields have different bit length (this includes fields like 1, 3 or 24 or 48 bits long), with respect to endianess, and would generate C++ code accessing the data.

The question was put on hold due to being too vague, so I'll try to make it as clear as possible:

I am searching for a language that:

• accepts simple structure description and generate useful C++ code,
• would allow to precisely specify integers ranging from 1 bit to multiple (up to 8) bytes long, along with data (typically string),
• would isolate me from need to convert endianess,
• produces exact, predictable output that does not come with overhead (like in protocol buffers)

ASN.1 sounds almost good for the purpose, but it adds its own overhead (meaning, I cannot produce a simple structure that has 2 bytes split into 4 nibbles) - what i'm looking for is a language that would offer exact representation of the structure.

For example, I would want to abstract this:

struct Command {
  struct Record {
    int8_t track;
    int8_t point;
    int8_t index;
    int16_t start_position;  // big endian, misaligned
    int32_t length;          // big endian, misaligned;
  } __attribute__((packed)); // structure length = 11 bytes.

  int8_t current       : 1;
  int8_t command       : 7;
  int8_t reserved;
  int16_t side         : 3;  // entire int16_t needs to be
  int16_t layer        : 3;  // converted from big endian, because
  int16_t laser_mark   : 3;  // this field spans across bytes.
  int16_t laser_power  : 3;
  int16_t reserved_pad : 2;
  int16_t laser_tag    : 2;
  int32_t mode_number  : 8;  // again, entire 32 bit field needs to be converted
  int32_t record_count : 24; // from big endian to read this count properly.

  Record records[];
} __attribute__((packed));

the above needs to be packed exactly to the structure carrying 8 + record_count * 11 bytes, all formed accurately, no additional data, no additional bits or bytes set.

The above is just an example . it's made simple so that I don't clog the site with actual structures that have oftentimes hundreds of fields. It has been simplified , but shows many of the features that I am looking forward to see (two remaining features are 48 or 64-bit integers and plain data (bytes[]))

If this question is still too vague, please explain what it is that I should add in the comments. thanks!

Answer 1

A simple table that tracks individual field sizes and is used to spin out offsets of each element into your structure sounds like the easiest solution. This won't scale to deeply nested structures, but could be tuned to support handling of the unassigned bit cases you identify.

Then, you can use this to generate constants or even named property accessors to extract and update the individual fields. Given the size of the individual elements, macros are likely to make life even harder, but any mainstream compiler should inline the code. You mileage could vary with a template-based implementation.

If would help if you could use a common representation for both sides of the application (host and device) to further reduce the likelihood of transcription errors.

The PLC world has a number of different mechanisms for layout, but these are all very hardwired into their eco-systems and so would not really help.

Alternately, if you have the tooling available, you could consider something like ASN.1 structures for the representation. In the extreme, you could even use an open source generator to come up with an unencoded generator directly from the MIB.