View mode: basic / threaded / horizontal-split · Log in · Help
February 24, 2005
Another little question...
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
February 24, 2005
Re: Another little question...
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
February 24, 2005
Re: Another little question...
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
February 24, 2005
Re: Another little question...
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 of arbitrary size.
>    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
February 24, 2005
Re: Another little question...
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
February 24, 2005
Re: Another little question...
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 of arbitrary size.
>>    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
February 24, 2005
Re: Another little question...
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
February 24, 2005
Re: Another little question...
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;
}
February 24, 2005
Re: Another little question...
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
February 25, 2005
Re: Another little question...
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 
>
>
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home