flat assembler
Message board for the users of flat assembler.

Index > Projects and Ideas > fasm modification for expanded data types

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
Madis731



Joined: 25 Sep 2003
Posts: 2140
Location: Estonia
Madis731
Please, can we have a look at how the C structure is defined. Maybe its something as simple as
Code:
struc
{
 .a rb 3
}
    
Post 19 Feb 2011, 18:14
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
John Spera



Joined: 17 Feb 2011
Posts: 22
Location: Lowell, Massachusetts USA
John Spera
OK, This is the format I use in those programs

Quote:

/* 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];
};


That acct data field works in C.

John
Post 19 Feb 2011, 20:56
View user's profile Send private message Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2140
Location: Estonia
Madis731
I think most compilers pad 24 bits to 32 and 1 bit to 8 for speed. They will not pack stuctures very tight. If you try sizeof(ledmas) what does it tell you? Is it 44 or is it 47 or even 48? You can define a 24-bit length variable in FASM, but it needs some "getting used to" in code. Bitfields are very simple, just name your bits in a variable and use the Bcc-family of instructions, for example BT [bitfield],SIGN where SIGN equ 1, and so on.

Just a little quote from wiki:
http://en.wikipedia.org/wiki/Bit_field wrote:

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:
Post 23 Feb 2011, 12:02
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Madis731: that struct ought to take up 7 bytes for the bitfields, rounded up to 8 bytes if no "pragma pack" is used. Adding the char arrays gives a size of 45 bytes (when including the rounding), and this will be rounded up to a total size of 48 bytes (assuming DWORD alignment) because of padding.

Personally I wouldn't use bit packing unless I was dealing with hardware, but it works perfectly for that, and avoids having to drop down to assembly.
Post 23 Feb 2011, 13:20
View user's profile Send private message Visit poster's website Reply with quote
John Spera



Joined: 17 Feb 2011
Posts: 22
Location: Lowell, Massachusetts USA
John Spera
The sizeof(ledmas) is 44. See that LEDSIZ define statement, I am using a binary file format.

It is true that the ordering of bits in memory can be different on big endion machines. I am not aware of the Bcc family of instructions?? I last used an assembler in 1976 and lots has changed since then.

Still I am curious as to why I am receiving the particular error that I get. My efforts to learn may be a bit different but the goal is the same as any one else.

John
Post 23 Feb 2011, 16:15
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
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.

_________________
Image - carpe noctem
Post 23 Feb 2011, 16:34
View user's profile Send private message Visit poster's website Reply with quote
John Spera



Joined: 17 Feb 2011
Posts: 22
Location: Lowell, Massachusetts USA
John Spera
f0dder wrote:
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?

John
Post 23 Feb 2011, 17:03
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
John Spera wrote:
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.
Just be aware that if you don't have pragmas + errorchecks, you could be in for a world of pain if you ever switch to another compiler, switch from 32- to 64-bit build, et cetera.

John Spera wrote:
Do you have any insights on my fasm issue, as it relates to the error I mentioned?
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.
Post 23 Feb 2011, 17:25
View user's profile Send private message Visit poster's website Reply with quote
John Spera



Joined: 17 Feb 2011
Posts: 22
Location: Lowell, Massachusetts USA
John Spera
Quote:

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.


OK then, I was not aware that there would be this limitation.

There must be another method for working with 3-byte values. Both my computers are 64 bit machines. Even with different Linux operating systems, each is able to work with a 3-byte value.

Do you have any insights as to how this has been accomplished?

Thanks,
John
Post 23 Feb 2011, 19:42
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
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).
Post 23 Feb 2011, 19:46
View user's profile Send private message Visit poster's website Reply with quote
John Spera



Joined: 17 Feb 2011
Posts: 22
Location: Lowell, Massachusetts USA
John Spera
f0dder wrote:
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).


Yes I do realize these things. Essentially some compiler, either C or an assembler, was able to get around this, what I see, as a limitation.

For example, we can assign memory for a 3 byte character string. When I looked at the code for that it seemed quite involved. I suspect that I will need to re-visit that logic and evaluate it more extensively. I do recognize that hardware construction has reasons for everything. I do not wish to ignore them, however finding ways to work with it is another story.

I know in time I will build on my experience with current assemblers and fasm. I do appreciate the time and effort that you have expended explaining these things to me. It is my hope that I can build on your insights to accomplish this particular task.

Thanks,
John
Post 23 Feb 2011, 21:28
View user's profile Send private message Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2140
Location: Estonia
Madis731
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.
Post 25 Feb 2011, 15:00
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
John Spera



Joined: 17 Feb 2011
Posts: 22
Location: Lowell, Massachusetts USA
John Spera
Madis731 wrote:
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.


Yes I am finding this out, more and more, every day. At the moment I am working my way through a couple of issues. I can see why this type of programming is not popular. Yet I find it appealing.

My creative side will need to take a step back for now, there are other things that I need too figure out first. Since I work with the Linux operating systems, just appreciating all those system calls for it is a task in itself.

What OS do you have the most experience with?

Thanks,
John
Post 26 Feb 2011, 15:23
View user's profile Send private message Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2140
Location: Estonia
Madis731
Is this a poll? Smile I'm a Windows guy, but I do love everything about Linux.
Post 26 Feb 2011, 17:07
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
John Spera



Joined: 17 Feb 2011
Posts: 22
Location: Lowell, Massachusetts USA
John Spera
I was just curious. I was working with some assembler a number of years ago with Windows and it did not seem like the way to go for me.

I am happy to say that since my last post I did figure out one of my program issues. It can be fun when we have a bit of success.

John
Post 26 Feb 2011, 18:07
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.