Recent

Author Topic: [SOLVED] question about bit field alignment in FPC records  (Read 6551 times)

engkin

  • Hero Member
  • *****
  • Posts: 3112
Re: [SOLVED] question about bit field alignment in FPC records
« Reply #30 on: July 12, 2019, 04:38:30 am »
440bx and JernejL, please accept my apology.
Apology accepted, no harm done.
Thank you.

It is documented but, not in a very visible way. From the Free Pascal Reference Guide:
Quote
Non-ordinal types - which include but are not limited to - sets, floats, strings, (bitpacked) records, (bitpacked) arrays, pointers, classes, objects, and procedural variables, are stored on the first available byte boundary.

It is also documented that the record may be empty (the syntax diagram shows it - section 3.3.2 of the reference guide.) 

Therefore, the compiler's behavior in that case is as spec-ed.  The compiler is aligning the record as documented and, has a size of zero because there are no fields in it, which is legal.
I am glad it is documented. Well spotted!

JernejL

  • Jr. Member
  • **
  • Posts: 92
Re: [SOLVED] question about bit field alignment in FPC records
« Reply #31 on: July 12, 2019, 10:14:59 am »
I can't wait until nameless records are added (if ever) to define the structure "ideally".

How exactly would this work? i'm curious, i never heard of this expression before, googling it also does not yield anything explaining it.
 
 

Thaddy

  • Hero Member
  • *****
  • Posts: 14211
  • Probably until I exterminate Putin.
Re: [SOLVED] question about bit field alignment in FPC records
« Reply #32 on: July 12, 2019, 10:24:03 am »
Yes, how would you reference such a nameless record? Such features belong to the DWIM compiler wish list.
Specialize a type, not a var.

440bx

  • Hero Member
  • *****
  • Posts: 3946
Re: [SOLVED] question about bit field alignment in FPC records
« Reply #33 on: July 12, 2019, 06:35:54 pm »
@JernejL

How exactly would this work? i'm curious, i never heard of this expression before, googling it also does not yield anything explaining it.

and

@Thaddy

Yes, how would you reference such a nameless record? Such features belong to the DWIM compiler wish list.

I will address both questions in one shot since they are rather related.

In C, it is valid to have a construction such as (construction 1):
Code: C  [Select][+][-]
  1. typedef struct _astruct
  2. {
  3.   char a;
  4.   struct       // note the unnamed struct here
  5.   {
  6.     char b;
  7.     char c;
  8.   };
  9.   char d;
  10.  };
  11.  
  12. ...
  13. ... some more stuff here
  14. ...
  15.  
  16.     _astruct Astruct;
  17.  
  18.     Astruct.a = 'a';
  19.     Astruct.b = 'b';
  20.     Astruct.c = 'c';
  21.     Astruct.d = 'd';
  22.  
using struct that way is simply a way to group fields, which can be used along with an alignment directive to have that group of fields start at a desired boundary.

That's what I believe the idea behind "nameless records" is but, as you both have correctly pointed out, in Pascal such a construct cannot be implemented using "record" because Pascal will not allow constructions that are semantically meaningless such as (constructions 2 & 3):
Code: C  [Select][+][-]
  1. typedef struct  // no data type name
  2. {
  3.   char a;
  4.   char b;
  5.  };            // no instance/variable of that unnamed type
  6.  
  7. struct         // close cousin of the above
  8. {
  9.   char a;
  10.   char b;
  11.  };
  12.  
both of those declarations are semantically meaningless, the C compiler emits a warning but, since they are syntactically correct, it accepts them.  Pascal (fortunately) won't.

a nameless group of fields (such as construction 1) would most likely require a new keyword since using "record" for that purpose opens the doors to meaningless constructions which are - fortunately - not acceptable to the Pascal language.

« Last Edit: July 12, 2019, 06:37:42 pm by 440bx »
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

jamie

  • Hero Member
  • *****
  • Posts: 6091
Re: [SOLVED] question about bit field alignment in FPC records
« Reply #34 on: July 12, 2019, 11:01:20 pm »
Its a basic concept...

Structs, Unions etc can be nameless..

What this means is you can address the members of this field as if they were in the parent struct/Record, there
is no requirement for using a additional identifier.

 As for alignment, especially bit fields, This will group the items together as a whole but not require you to
add additional identifier. In other words, it uses the name space of the parent of that record.

Now getting to the variant record..

You can have a variant record at the end and it requires no identifier, just the overlapping members of that
location. However, to get that work before the end of the Record is a nightmare without forcing a sub identifier..

 Currently when you use a Variant record the END statement also ENDS the main record, why that ever was
done that way is beyond me., but at least you aren't forced to add a sub ID to it...

If you wrap a variant with a Record you can then have a variant before the end of the record however, you
now are forced to also have a Identifier which in many I don't want. I want the fields of the variant to be
in the same name space as the host Record of the variant and if the RECORD is nameless this means the
Name Space will be that of the host before...

Let me see if I can give an example
Code: Pascal  [Select][+][-]
  1. MyRecord = Record
  2.   Record
  3.    Case
  4.      0:(A:Word;
  5.      1:(B.Short[10]);
  6.    End;
  7.  SomeByte:Byte;
  8. End;
  9.  

I want to do this.
MyRecord.A := 1;
or
MyRecord B:= 'hello';

But because we don't have nameless records this is what we need to do.
Code: Pascal  [Select][+][-]
  1. MyRecord = Record
  2.  Afield: Record
  3.    Case
  4.      0:(A:Word;
  5.      1:(B.Short[10]);
  6.    End;
  7.  SomeByte:Byte;
  8. End;
  9.  

MyRecord.AField.A := Whatever...
MyRecord.Afield.B := 'Something';

 Of course the Scope of the A,B in the nameless record version will also be in the same scope as
the SomeByte, you'll need unique ID's for those of course..

 But this solves cryptic variant cases and can be used for Bit alignment...
currently as noted in another thread, the empty Record can be used as a trialling pointer.

The only true wisdom is knowing you know nothing

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: [SOLVED] question about bit field alignment in FPC records
« Reply #35 on: July 14, 2019, 09:41:08 am »
Half my programs consist of code that encapsulate input and output. Like, if you read an integer, is it big or little endian? Is it MSB first or last? What is the packing?

First I design a neat structure, most likely a flat record or a class. And I probably put those into a list or a container class if there are more. And after that it becomes clear how the data is structured and easy to work with.

If I just tried to lever every crappy piece of data as-is in an array, my programs would become twice as large and look like spaghetti.

440bx

  • Hero Member
  • *****
  • Posts: 3946
Re: [SOLVED] question about bit field alignment in FPC records
« Reply #36 on: July 14, 2019, 10:15:08 am »
If I just tried to lever every crappy piece of data as-is in an array, my programs would become twice as large and look like spaghetti.
You're missing the point.  The need for bit field alignment comes from the definitions of some of the data structures used by the Windows API.

Being unable to describe the structure as it is defined in the Window API, complicates the code (particularly in the case of bitfields.)

Another thing you should consider is that, bitfields are fairly common in low-level programming.   A reasonably decent OS doesn't go around wasting memory.

Just because you don't use them or don't need them doesn't mean they are always bad.  They aren't.

It's like variable sized records, there are times when, they are the simplest and cleanest way of implementing some functionality.

(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: [SOLVED] question about bit field alignment in FPC records
« Reply #37 on: July 14, 2019, 10:58:36 am »
You're missing the point.  The need for bit field alignment comes from the definitions of some of the data structures used by the Windows API.

Being unable to describe the structure as it is defined in the Window API, complicates the code (particularly in the case of bitfields.)

I think you're missing the point. You're thinking C. You want to use those structures as they are in your code, instead of using comprehensible high-level structures.

Much of the data structures from Windows are still 16-bit deep down. They encapsulated them as good as they could in 32-bit structures, and later classes. To prevent programmers having to use those archaic constructs. While you demand that Pascal should use those constructs, instead of the nicely encapsulated higher-level containers we all love. That is the essence of Pascal. That's why I use it. If I want no-bounds, balls-to-the-wall spaghetti programming, I can use C or C++.

Quote
Another thing you should consider is that, bitfields are fairly common in low-level programming.   A reasonably decent OS doesn't go around wasting memory.

Just because you don't use them or don't need them doesn't mean they are always bad. They aren't.

It's like variable sized records, there are times when, they are the simplest and cleanest way of implementing some functionality.

Yes, support for bit fields in higher languages is bad. At least Pascal has Booleans and sets (and FPC TBits). It already has better support for them than C. The way to handle bits isn't trying to cram Pascal into C, but like ARM does it: allow you to handle bits like Pascal Booleans through bit-banding.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: [SOLVED] question about bit field alignment in FPC records
« Reply #38 on: July 14, 2019, 11:24:03 am »
Much of the data structures from Windows are still 16-bit deep down. They encapsulated them as good as they could in 32-bit structures, and later classes. To prevent programmers having to use those archaic constructs. While you demand that Pascal should use those constructs, instead of the nicely encapsulated higher-level containers we all love. That is the essence of Pascal. That's why I use it. If I want no-bounds, balls-to-the-wall spaghetti programming, I can use C or C++.
Newer parts of the WinAPI use that scheme as well. And when interfacing with an OS, especially from an open source project with finite man power, it's very important so be able to point the users to the existing documentation which in this case is MSDN. And if they see the structure shown in MSDN represented in Pascal code as closely as possible the users are easier able to use it.

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: [SOLVED] question about bit field alignment in FPC records
« Reply #39 on: July 14, 2019, 12:12:48 pm »
Documentation. Good point.

The "easiest" solution would be $HPPEMIT. Easy to use, lots of work to build.

Wouldn't it be possible to compile the header files with gcc to assembly? Then again, most C/C++ compilers only generate code for source files. Or use the symbol information generated?

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: [SOLVED] question about bit field alignment in FPC records
« Reply #40 on: July 14, 2019, 01:17:50 pm »
The "easiest" solution would be $HPPEMIT. Easy to use, lots of work to build.
What would be easy about that? The $HPPEMIT statements would need to be maintained and there use is only to generate C++ headers for Delphi code. So there would be no use for the documentation.

Wouldn't it be possible to compile the header files with gcc to assembly? Then again, most C/C++ compilers only generate code for source files. Or use the symbol information generated?
A C or C++ compiler might use features that FPC does not support (e.g. the C++ standard type library in case of C++ headers). So such headers need to be converted manually anyway - that includes the "flexible array member". Not to mention that this is a rather frickle approach as compilers sometimes change their debug format to improve it further while the structures themselves stay the same.

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: [SOLVED] question about bit field alignment in FPC records
« Reply #41 on: July 14, 2019, 01:40:48 pm »
Yes, easy to use, lots of work to build and maintain. But it allows you to link to that external code of which you have that documentation.

440bx

  • Hero Member
  • *****
  • Posts: 3946
Re: [SOLVED] question about bit field alignment in FPC records
« Reply #42 on: July 14, 2019, 06:29:59 pm »
Yes, easy to use, lots of work to build and maintain. But it allows you to link to that external code of which you have that documentation.
If complaining was a sport you'd be Olympic material.

Using the Windows API as an example of why bitfields and, the ability to describe structures that contains them, was done is simply because it is something that a lot of programmers should be familiar with and should be able to relate to.

Bitfields isn't about C/C++ and/or the Windows API.  The fact is, the _majority_ of the structures that are defined by the CPU, in hardware, use bitfields.  Go tell Intel, AMD and every company that designs CPUs, they can't use bitfields because that is "raping Pascal."  It might help if you offered to pay for the useless additional circuitry it takes to turn bitfields into bytes and the additional die space that useless stuff will occupy.  No doubt they will understand.


(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

jamie

  • Hero Member
  • *****
  • Posts: 6091
Re: [SOLVED] question about bit field alignment in FPC records
« Reply #43 on: July 14, 2019, 06:42:24 pm »
   I try to stay away from C/C++ because the syntax is ugly and I use Pascal instead due to the verbosity of the language which makes it so eye pleasing to read and simple to understand.

  Putting that aside,  you can't argue that C has some features in its language that make it nice to interface
at the code level. Fpc could in turn offer these options for data structures but still using the pascal interface verbosity structure to make it eye pleasing but yet a powerful option in its compiler.

 I know a few coders that use both pascal and C/C++ and they have quoted practically the same thing, It does not need the Syntax of C but the power of it.

 What we are talking about here is adding power to the language not adding C/C++ syntax.

 I know for a fact that this would attract many C/C++ coders if Fpc could do these data structures using pascal style easily to achieve the same naming, Sizing and alignment.

 Also the use of a alternate Quoted string can also add value. It's simple, what ever type of quote you
started with it should end in. And if it was a double quote then allow C escape chars within... This would solve many types of interfacing issues.

 You can go on the negative attitude train but we are not talking about making Fpc into C but making it perform with the same flexibilities using Pascal verbosity...

  I think that pretty much covers it. Have a good day.
The only true wisdom is knowing you know nothing

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: [SOLVED] question about bit field alignment in FPC records
« Reply #44 on: July 14, 2019, 06:44:14 pm »
Yes, easy to use, lots of work to build and maintain. But it allows you to link to that external code of which you have that documentation.

No it doesn't. It is about generating C++ windows headers from the Pascal headers. No linking compatibility even close.

 

TinyPortal © 2005-2018