struc
{
 .a rb 3
}
    

/* ledmas.s - ledmas structure */

#define LEDSIZ 44
#define LEDNEW 299 // is /lednew.bdf
#define LEDNUM 301 // is /ledmas.bdf

struct ledmas {
unsigned acct : 24;
unsigned fsnum : 16;
unsigned grnum : 8;
unsigned sign : 1;
unsigned type : 1;
unsigned omit : 1;
unsigned filler : 5;
char desc[31];
char fscd[3];
char schc[3];
};

However, bit members in structs have potential practical drawbacks. First, the ordering of bits in memory is cpu dependent and memory padding rules can vary between compilers. In addition, less well optimized compilers sometimes generate poor quality code for reading and writing bit members and there are potentially thread safety issues relating to bit fields because most machines cannot manipulate arbitrary sets of bits in memory, but must instead load and store whole words;[1] e.g. the following would not be thread-safe, in spite of the use of a mutex for each member:

The sizeof(ledmas) is 44. See that LEDSIZ define statement, I am using a binary file format.

John Spera wrote:

The sizeof(ledmas) is 44. See that LEDSIZ define statement, I am using a binary file format.

That is going to depend entirely on your compiler - if you use that LEDSIZ define blindly, you are asking for trouble... I hope you have the right #pragmas and compile-time checking that sizeof(ledmas) equals LEDSIZ.

Yes all the programs that use this file work correctly. Which would not be the case if the size was not 44. Thank you for your concerns about my C programs.

Do you have any insights on my fasm issue, as it relates to the error I mentioned?

"error: invalid operand" for "stos bytet [edi]. No doubt I would get a similar error when reserving memory.

If you're talking about the following:

John Spera wrote:
"error: invalid operand" for "stos bytet [edi]. No doubt I would get a similar error when reserving memory.

, then it's really simple - there's no x86 STOS instruction for 3-byte values, you're limited to B,W,D.

John, it's a limitation of the CPU - it can't be done, neither for x86 nor x64 hardware. An assembler can only utilize the instruction set exposed by the CPU, it can't create new instructions (not for x86 hardware, anyway).

That you can work with 3-byte quantities from HLLs is another thing; your compiler is going to generate multiple machine instructions for manipulating those, with bitmasking (and for packed structures, shifting).

macro stos tbyte
{
stos word (tbyte and 0FFFFh);word
stos byte (tbyte shr 16);byte
}
    

You can accomplish it with ASM, but instead of "STOS 3_bytes" you need to do consecutive "STOS 2_bytes; STOS 1_byte" meaning you would have to write something like:

Code:

macro stos tbyte
{
stos word (tbyte and 0FFFFh);word
stos byte (tbyte shr 16);byte
}
    

it won't work, I just made that up. Working code can be much more difficult.