Provide the ability to use bit fields in clusters

[Bun]

In C when you create a struct, you can create bit fields to assign identifiers to specific bits of a attribute.

For example:

Struct

{

unsigned short toAddress  : 5;

unsigned short wordCount  : 8;

unsigned short msgType    : 3;

unsigned short crc

} TCP_Header;

Once you have created the struct, you can cast the appropriate amount of data words into the struct and then access the structs attributes without having to do bit shifting & masking.

TCP_Header hdr = (TCP_Header) TCP_Stream.readWord();

if(hdr.toaddress == 1901 & hdr.msgType == 6)

{

process Message(hdr);

}

else

{

printf("\n Unexpected Address: %d\n",hdr.toAddress);

}

If we were able to create a cluster and specify which bits each control in the struct represents and then cast the data into said cluster, it would make working with bit packing and low level data manipulation much easier. This would save us from having to do a bunch of masking & shifting.

[ChristopherPovey]

I would extend this to be able to add FXP types to Clusters and they occupy the number of bits specified in the FXP.  Also allow the number of bits for Boolean types to be specified.

[AristosQueue (NI)]

This is actually a request to create a bit field data type in the first place, something I have wanted on multiple occassions in my years using LabVIEW. I'll throw my kudos behind this idea if only because that is a prerequisite to this one.

As a workaround today, you can build an XControl to give you this ability for a specific bit field -- worth it if you have one bit field that will be used in many places.

[Intaris]

Oh, you mean bringing Booleans back to where they used to be?  Weren't Booleans single bits instead of u8 at some time in the past?

I too would love a bitfield datatype in general.

[AristosQueue (NI)]

Intaris: No. Arrays of Booleans were bit fields padded to 8 bits, but to the best of my knowledge, Booleans have always been 1 byte. I don't know of any system LV has ever run on that was sub-byte addressable memory (FPGA doesn't count since it isn't addressable memory).

[Intaris]

Right, so boolean arrays used to be padded bitfields......  Close enough.

How cool would it be to have the operation "X to Boolean Array" being a NO-OP?

[AristosQueue (NI)]

> Right, so boolean arrays used to be padded bitfields......  Close enough.

They were variable sized arrays, meaning they were heap allocations with a length byte in front followed by (length mod 8 (+1)) bytes. And they were not particularly performant because systems are byte addressable, and iterating through the array was a lot of XOR and shifting, with no register inplaceness.

A bit field is a fixed-sized array that is not typically iterated over to check all of its elements -- bit fields tend to be used just with an XOR. They aren't resizable.

> How cool would it be to have the operation "X to Boolean Array" being a NO-OP?

Not very. We dropped it deliberately for performance around the LV 4.0 timeframe (memories of the architects are hazy as to the timeframe). The world is byte addressable, not bit addressable. A lot of loop unrolling, parallel operation and even just straight up indexing is substantially less efficient with a bit field. Take a For Loop that is indexing parallel arrays, one of Booleans and one of integers. With the current set up, a single index register is needed for both arrays. If the Bool array is a packed array, it needs two separate register allocations to track the index and the offset within the index. Clunky.

We do essentially have a packed array on FPGA implementations where each Boolean is a single "line" in the fabric.

[Omar_II]

I think most LabVIEW programmer don't know they want BIT fields and how easy it will make their life not having to do all the bit shifting & masking.

I do a lot of MIL-1553 communication and instead of bit shifting & masking I use 'Number To Boolean Array' to 'Index Array' to 'Build Array' to 'Boolean Array To Number' to parse out the data.

Every time I mumble wishing LabVIEW had BIT fields. 

This method might not be the most efficient, but it very self documenting.