www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Another little question...

reply Ron <Ron_member pathlink.com> writes:
I was just wanting to know how to translate this to D:

struct gdt_entry
{
unsigned short limit_low;
unsigned short base_low;
unsigned char base_middle;
unsigned char access;
unsigned char granularity;
unsigned char base_high;
} __attribute__((packed));

NOT the struct -or- type syntax, but the "__attribute__((packed))" part... I'm
needing this struct's data to be back-to-back (no gaps inbetween). I want to
express this in D. 

This is GCC code, BTW.

Thanks,
--Ron
Feb 24 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 24 Feb 2005 22:01:48 +0000 (UTC), Ron wrote:


 I was just wanting to know how to translate this to D:
 
 struct gdt_entry
 {
 unsigned short limit_low;
 unsigned short base_low;
 unsigned char base_middle;
 unsigned char access;
 unsigned char granularity;
 unsigned char base_high;
 } __attribute__((packed));
 
 NOT the struct -or- type syntax, but the "__attribute__((packed))" part... I'm
 needing this struct's data to be back-to-back (no gaps inbetween). I want to
 express this in D. 
 


I don't know the answer, Ron. But I just wanted to say this is why
languages like D need to *also* be able to express a RAM memory layout
which may be different from an 'optimised' struct.

Something like ...

struct gdt_entry
{
byte[2] as unsigned short limit_low;
byte[2] as unsigned short base_low;
byte[1] as unsigned char base_middle;
byte[1] as unsigned char access;
byte[1] as unsigned char granularity;
byte[1] as unsigned char base_high;
}

which would describe the exact layout of an 8-byte area of contiguous RAM,
and how the compiler should access the elements.

-- 
Derek
Melbourne, Australia
25/02/2005 9:20:08 AM
Feb 24 2005
next sibling parent reply brad domain.invalid writes:
Derek Parnell wrote:

 On Thu, 24 Feb 2005 22:01:48 +0000 (UTC), Ron wrote:
 
 

I was just wanting to know how to translate this to D:

struct gdt_entry
{
unsigned short limit_low;
unsigned short base_low;
unsigned char base_middle;
unsigned char access;
unsigned char granularity;
unsigned char base_high;
} __attribute__((packed));

NOT the struct -or- type syntax, but the "__attribute__((packed))" part... I'm
needing this struct's data to be back-to-back (no gaps inbetween). I want to
express this in D. 


 
 
 I don't know the answer, Ron. But I just wanted to say this is why
 languages like D need to *also* be able to express a RAM memory layout
 which may be different from an 'optimised' struct.
 
 Something like ...
 
 struct gdt_entry
 {
 byte[2] as unsigned short limit_low;
 byte[2] as unsigned short base_low;
 byte[1] as unsigned char base_middle;
 byte[1] as unsigned char access;
 byte[1] as unsigned char granularity;
 byte[1] as unsigned char base_high;
 }
 
 which would describe the exact layout of an 8-byte area of contiguous RAM,
 and how the compiler should access the elements.
 


Isn't this done by simply using the align attribute?
ie
align(1): // set byte alignment
struct gdt_entry
{
unsigned short limit_low;
unsigned short base_low;
unsigned char base_middle;
unsigned char access;
unsigned char granularity;
unsigned char base_high;
}

align: // set back to default alignment

However, I would like to know why D doesn't support the bit size 
specifier, ie in C
struct foo
{
unsigned blah:10;
unsigned packed:22;
}

It is quite useful in some instances - is there a solid reason for D not 
supporting it?

Brad
Feb 24 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
brad domain.invalid wrote:


 However, I would like to know why D doesn't support the bit size 
 specifier, ie in C
 struct foo
 {
 unsigned blah:10;
 unsigned packed:22;
 }
 
 It is quite useful in some instances - is there a solid reason for D not 
 supporting it?


In D logic, the bit fields are obsolete - but bit[] are neat...

http://www.digitalmars.com/d/overview.html:



    Bit fields are a complex, inefficient feature rarely used.



 Bit type
 The fundamental data type is the bit, and D has a bit data type.
 This is most useful in creating arrays of bits:
 
 	bit[] foo;


Then it goes on to assign those arrays in multiples of 32 bits...


I'd stay clear of both ;-) (you can use bitshifting and masking?)

--anders
Feb 24 2005
parent reply brad domain.invalid writes:
Anders F Björklund wrote:


 In D logic, the bit fields are obsolete - but bit[] are neat...
 
 http://www.digitalmars.com/d/overview.html:
 


    Bit fields are a complex, inefficient feature rarely used.


 
 

 Bit type
 The fundamental data type is the bit, and D has a bit data type.
 This is most useful in creating arrays of bits:

     bit[] foo;


 
 
 Then it goes on to assign those arrays in multiples of 32 bits...
 
 
 I'd stay clear of both ;-) (you can use bitshifting and masking?)
 
 --anders


:) Yeah, I'd had a play with bit fields and noticed that they weren't 
the correct size.  Using shifting and masking is no real issue (and is 
what the compiler has to do behind the scenes anyhow).
And infact, I have just found that you can quite nicely hide the bit 
packing with the use of properties to access packed data :)

Brad
Feb 24 2005
parent reply "Alex Stevenson" <ans104 cs.york.ac.uk> writes:
On Fri, 25 Feb 2005 11:44:41 +1300, <brad domain.invalid> wrote:


 Anders F Björklund wrote:


 In D logic, the bit fields are obsolete - but bit[] are neat...
  http://www.digitalmars.com/d/overview.html:



    Bit fields are a complex, inefficient feature rarely used.



 Bit type
 The fundamental data type is the bit, and D has a bit data type.
 This is most useful in creating arrays of bits:

     bit[] foo;


   Then it goes on to assign those arrays in multiples of 32 bits...
   I'd stay clear of both ;-) (you can use bitshifting and masking?)
  --anders


 :) Yeah, I'd had a play with bit fields and noticed that they weren't  
 the correct size.  Using shifting and masking is no real issue (and is  
 what the compiler has to do behind the scenes anyhow).
 And infact, I have just found that you can quite nicely hide the bit  
 packing with the use of properties to access packed data :)

 Brad


I found bit arrays very useful when dealing with some things... I started  
one program with






Rather more convenient than messing about with masking, oring/anding etc.  
In fact, might it not be a useful things to add 'asBits' as a standard  
property to built in integer types, since they're the ones that get  
bit-twiddled?



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
Feb 25 2005
parent =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Alex Stevenson wrote:


 I found bit arrays very useful when dealing with some things... I 
 started  one program with





 
 Rather more convenient than messing about with masking, oring/anding 
 etc.  In fact, might it not be a useful things to add 'asBits' as a 
 standard  property to built in integer types, since they're the ones 
 that get  bit-twiddled?


You can't use unions, though, since that'll only work for
int and long since D rounds bit[] up to 32-bit boundaries...

(but you could use a (bit*) pointing at the byte, for instance,
so such an "asBits" feature would still be doable I suppose)

So it does have it's uses, but it's still a doubtful feature.
Especially for speed freaks, as pointed out in the sieve tests ?

--anders
Feb 25 2005
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Fri, 25 Feb 2005 11:33:23 +1300, brad domain.invalid wrote:


 Derek Parnell wrote:

 On Thu, 24 Feb 2005 22:01:48 +0000 (UTC), Ron wrote:
 

I was just wanting to know how to translate this to D:

struct gdt_entry
{
unsigned short limit_low;
unsigned short base_low;
unsigned char base_middle;
unsigned char access;
unsigned char granularity;
unsigned char base_high;
} __attribute__((packed));

NOT the struct -or- type syntax, but the "__attribute__((packed))" part... I'm
needing this struct's data to be back-to-back (no gaps inbetween). I want to
express this in D. 


 
 I don't know the answer, Ron. But I just wanted to say this is why
 languages like D need to *also* be able to express a RAM memory layout
 which may be different from an 'optimised' struct.
 
 Something like ...
 
 struct gdt_entry
 {
 byte[2] as unsigned short limit_low;
 byte[2] as unsigned short base_low;
 byte[1] as unsigned char base_middle;
 byte[1] as unsigned char access;
 byte[1] as unsigned char granularity;
 byte[1] as unsigned char base_high;
 }
 
 which would describe the exact layout of an 8-byte area of contiguous RAM,
 and how the compiler should access the elements.
 


 Isn't this done by simply using the align attribute?
 ie
 align(1): // set byte alignment
 struct gdt_entry
 {
 unsigned short limit_low;
 unsigned short base_low;
 unsigned char base_middle;
 unsigned char access;
 unsigned char granularity;
 unsigned char base_high;
 }
 
 align: // set back to default alignment


Lovely! You learn something everyday. Thanks.

-- 
Derek
Melbourne, Australia
25/02/2005 9:49:23 AM
Feb 24 2005
prev sibling parent reply Ron <Ron_member pathlink.com> writes:
In article <12t32p2qd7xw9$.tfs84dtrh9ke$.dlg 40tude.net>, Derek Parnell says...

On Thu, 24 Feb 2005 22:01:48 +0000 (UTC), Ron wrote:


 I was just wanting to know how to translate this to D:
 
 struct gdt_entry
 {
 unsigned short limit_low;
 unsigned short base_low;
 unsigned char base_middle;
 unsigned char access;
 unsigned char granularity;
 unsigned char base_high;
 } __attribute__((packed));
 
 NOT the struct -or- type syntax, but the "__attribute__((packed))" part... I'm
 needing this struct's data to be back-to-back (no gaps inbetween). I want to
 express this in D. 
 


I don't know the answer, Ron. But I just wanted to say this is why
languages like D need to *also* be able to express a RAM memory layout
which may be different from an 'optimised' struct.

Something like ...

struct gdt_entry
{
byte[2] as unsigned short limit_low;
byte[2] as unsigned short base_low;
byte[1] as unsigned char base_middle;
byte[1] as unsigned char access;
byte[1] as unsigned char granularity;
byte[1] as unsigned char base_high;
}

which would describe the exact layout of an 8-byte area of contiguous RAM,
and how the compiler should access the elements.

-- 
Derek
Melbourne, Australia
25/02/2005 9:20:08 AM


Thanks, but unfortunately it didn't work... complained:
"semicolon expected, not 'ushort'"

--Ron
Feb 24 2005
parent Derek Parnell <derek psych.ward> writes:
On Thu, 24 Feb 2005 22:42:55 +0000 (UTC), Ron wrote:


 In article <12t32p2qd7xw9$.tfs84dtrh9ke$.dlg 40tude.net>, Derek Parnell says...

On Thu, 24 Feb 2005 22:01:48 +0000 (UTC), Ron wrote:


 I was just wanting to know how to translate this to D:
 
 struct gdt_entry
 {
 unsigned short limit_low;
 unsigned short base_low;
 unsigned char base_middle;
 unsigned char access;
 unsigned char granularity;
 unsigned char base_high;
 } __attribute__((packed));
 
 NOT the struct -or- type syntax, but the "__attribute__((packed))" part... I'm
 needing this struct's data to be back-to-back (no gaps inbetween). I want to
 express this in D. 
 


I don't know the answer, Ron. But I just wanted to say this is why
languages like D need to *also* be able to express a RAM memory layout
which may be different from an 'optimised' struct.

Something like ...

struct gdt_entry
{
byte[2] as unsigned short limit_low;
byte[2] as unsigned short base_low;
byte[1] as unsigned char base_middle;
byte[1] as unsigned char access;
byte[1] as unsigned char granularity;
byte[1] as unsigned char base_high;
}

which would describe the exact layout of an 8-byte area of contiguous RAM,
and how the compiler should access the elements.

-- 
Derek
Melbourne, Australia
25/02/2005 9:20:08 AM


 
 Thanks, but unfortunately it didn't work... complained:
 "semicolon expected, not 'ushort'"
 
 --Ron


Ummm, sorry. I was giving a hypothetical syntax that I just invented on the
fly. As Brad has pointed out, D already has the 'align' attribute.

  http://www.digitalmars.com/d/attribute.html


-- 
Derek
Melbourne, Australia
25/02/2005 9:52:13 AM
Feb 24 2005
prev sibling next sibling parent Kris <Kris_member pathlink.com> writes:
In article <cvlisc$23ck$1 digitaldaemon.com>, Ron says...

I was just wanting to know how to translate this to D:

struct gdt_entry
{
unsigned short limit_low;
unsigned short base_low;
unsigned char base_middle;
unsigned char access;
unsigned char granularity;
unsigned char base_high;
} __attribute__((packed));

NOT the struct -or- type syntax, but the "__attribute__((packed))" part... I'm
needing this struct's data to be back-to-back (no gaps inbetween). I want to
express this in D. 

This is GCC code, BTW.

Thanks,
--Ron 



From this page: http://www.digitalmars.com/d/htomodule.html


#pragma pack(1)
struct Foo
{
int a;
int b;
};
#pragma pack()


becomes:

struct Foo
{
align (1):
int a;
int b;
}
Feb 24 2005
prev sibling parent Dave <Dave_member pathlink.com> writes:
This should do that (it can be scoped like with __atribute__):

align(1) // set byte alignment
{
struct gdt_entry
{
ushort limit_low;
ushort base_low;
ubyte base_middle;
ubyte char access;
ubyte char granularity;
ubyte char base_high;
}
} // default alignment from here

More here: http://digitalmars.com/d/attribute.html

- Dave

In article <cvlisc$23ck$1 digitaldaemon.com>, Ron says...

I was just wanting to know how to translate this to D:

struct gdt_entry
{
unsigned short limit_low;
unsigned short base_low;
unsigned char base_middle;
unsigned char access;
unsigned char granularity;
unsigned char base_high;
} __attribute__((packed));

NOT the struct -or- type syntax, but the "__attribute__((packed))" part... I'm
needing this struct's data to be back-to-back (no gaps inbetween). I want to
express this in D. 

This is GCC code, BTW.

Thanks,
--Ron
Feb 24 2005