I'm very interested in using D for an upcoming embedded project, and I have some
questions/comments/concerns that don't appear to be in {FAQ, News, Forum,
Future}
sections of this site:

1)  Is there a cross-compiler available?  I'd like to build "D" for an ARM9 or
ARM7.
Or do I have to wait for the GNU integration efforts I've heard mention of?

2)  Can the characteristics of the garbage collection be altered or monitored
for
real-time compatibility?  What I'd like to see is a spectrum of possiblities
along the lines of many other programming systems that offer capabilities
without attitude.  Something like this:
- hooks to force/suppress garbage collection for use by a specific thread.
- hooks to alter garbage collection attributes (e.g. run only every 1,000
allocations)
- ability to substitute a different allocator if needed.

3)  I'm thinking of using the eCos RTOS.  Is this a non-starter?  Any advice?

4)  For low-level drivers and other systems work, I've generally used
bit-fields,
even though they are not "portable".  But since I'm mostly concerned with
MY hardware,  I typically don't care about this.  The few times I've needed to
port bit fields, this type of kludge tends to work fine:

typedef struct Some32bitHardware
{
#ifdef  LITTLE_ENDIAN
unsigned int mStatusBits        :   7;
unsigned int mCommandBits : 25;
#else
unsigned int mCommandBits : 25;
unsigned int mStatusBits         :   7;
#endif
} ;

Here's my question  -- since D doesn't support bitfields,  can I bind enum
bitfields in some fashion to ensure the proper bits are set/cleared?
Can I embed the enums in their associated hardware structures?  Even
though this is ugly, it reduces naming confusion.

4)   Also, can I extract the "name" of a bitfield for use in a printf?  It seems
wasteful to have a separate array of names for enum items.  I'd like
this "code":
enum Days
{    Monday, Tuesday, ...};
Days d = Thursday;

printf("Day d is %s\n", d.name);
To print  "Day is Thursday"





Thanks in advance,
Ken Yale

yale_ken@yahoo.com wrote:
> I'm very interested in using D for an upcoming embedded project, and I have some
> questions/comments/concerns that don't appear to be in {FAQ, News, Forum,
> Future}
> sections of this site:
> 
> 1)  Is there a cross-compiler available?  I'd like to build "D" for an ARM9 or
> ARM7.
> Or do I have to wait for the GNU integration efforts I've heard mention of?

No, none is available. No, it doesn't make sense to wait since noone is
working on the GCC integration now. The only option is do-it yourself,
and i may (try to) join back in if you are interested. My interest would
be to have D on Dreamcast (SH4). But frankly, i really have too much to do.

> 2)  Can the characteristics of the garbage collection be altered or monitored
> for
> real-time compatibility?  What I'd like to see is a spectrum of possiblities
> along the lines of many other programming systems that offer capabilities
> without attitude.  Something like this:

Real-time collectors, such as 3-color, might requiere some change in the
storage... should not be hard to bolt on though, at the cost of some memory.

> - hooks to force/suppress garbage collection for use by a specific thread.
> - hooks to alter garbage collection attributes (e.g. run only every 1,000
> allocations)
> - ability to substitute a different allocator if needed.

You can already substitute a different allocator. The rest should be
easy enough to do. You can already suppress and force GC runs.

> 3)  I'm thinking of using the eCos RTOS.  Is this a non-starter?  Any advice?

?????????

> 4)  For low-level drivers and other systems work, I've generally used
> bit-fields,

> Here's my question  -- since D doesn't support bitfields,  can I bind enum
> bitfields in some fashion to ensure the proper bits are set/cleared?
> Can I embed the enums in their associated hardware structures?  Even
> though this is ugly, it reduces naming confusion.

D supports arrays of bits... but you never know how they get aligned
within a structure if more than one are used. So you could enumerate the
bit positions...

> 4)   Also, can I extract the "name" of a bitfield for use in a printf?  It seems
> wasteful to have a separate array of names for enum items.  I'd like
> this "code":
> enum Days
> {    Monday, Tuesday, ...};
> Days d = Thursday;
> 
> printf("Day d is %s\n", d.name);
> To print  "Day is Thursday"

Hmmm... If it's not already there, i'd vote for it!


Wishing happy new year,
-eye

In article <bt292j$2no$1@digitaldaemon.com>, yale_ken@yahoo.com says...
>
>I'm very interested in using D for an upcoming embedded project, and I have some
>questions/comments/concerns that don't appear to be in {FAQ, News, Forum,
>Future}
>sections of this site:
>
>1)  Is there a cross-compiler available?  I'd like to build "D" for an ARM9 or ARM7.

At this point only an x86 target would be available using a standard embedded C environment. You could probably use the Linux D complier. I can't remember if eCOS targets x86 yet.

D really needs to get more popular so it starts to appear for other targets. We mostly use PowerPC at work. The embedded market is pretty conservative about adopting new languages and OSes etc. But D is much better suited than Java for the embedded market which seems to be the current new kid on the block.

<yale_ken@yahoo.com> wrote in message news:bt292j$2no$1@digitaldaemon.com...
> I'm very interested in using D for an upcoming embedded project,

That's great news!

> and I have some
> questions/comments/concerns that don't appear to be in {FAQ, News, Forum,
> Future}
> sections of this site:
>
> 1)  Is there a cross-compiler available?  I'd like to build "D" for an
ARM9 or
> ARM7.

Sorry, only x86 code generators for D exist.

> Or do I have to wait for the GNU integration efforts I've heard mention
of?

Sadly, yes.

> 2)  Can the characteristics of the garbage collection be altered or
monitored
> for
> real-time compatibility?  What I'd like to see is a spectrum of
possiblities
> along the lines of many other programming systems that offer capabilities
> without attitude.  Something like this:
> - hooks to force/suppress garbage collection for use by a specific thread.
> - hooks to alter garbage collection attributes (e.g. run only every 1,000
> allocations)
> - ability to substitute a different allocator if needed.

The gc is modifiable and pluggable, i.e. it comes with source you can modify or you can plug in your own.

> 3)  I'm thinking of using the eCos RTOS.  Is this a non-starter?  Any
advice?

I don't know anything about it.

> 4)  For low-level drivers and other systems work, I've generally used
> bit-fields,
> even though they are not "portable".  But since I'm mostly concerned with
> MY hardware,  I typically don't care about this.  The few times I've
needed to
> port bit fields, this type of kludge tends to work fine:
>
> typedef struct Some32bitHardware
> {
> #ifdef  LITTLE_ENDIAN
> unsigned int mStatusBits        :   7;
> unsigned int mCommandBits : 25;
> #else
> unsigned int mCommandBits : 25;
> unsigned int mStatusBits         :   7;
> #endif
> } ;
>
> Here's my question  -- since D doesn't support bitfields,  can I bind enum
> bitfields in some fashion to ensure the proper bits are set/cleared?
> Can I embed the enums in their associated hardware structures?  Even
> though this is ugly, it reduces naming confusion.

I think I understand what you mean, and it should work.

> 4)   Also, can I extract the "name" of a bitfield for use in a printf?  It
seems
> wasteful to have a separate array of names for enum items.  I'd like
> this "code":
> enum Days
> {    Monday, Tuesday, ...};
> Days d = Thursday;
>
> printf("Day d is %s\n", d.name);
> To print  "Day is Thursday"

That feature is potentially pretty useful and has been requested a couple times already, but it has not been implemented.

To continue the enum discussion...

...
>> 4)   Also, can I extract the "name" of a bitfield for use in a printf?  It
>seems
>> wasteful to have a separate array of names for enum items.  I'd like
>> this "code":
>> enum Days
>> {    Monday, Tuesday, ...};
>> Days d = Thursday;
>>
>> printf("Day d is %s\n", d.name);
>> To print  "Day is Thursday"
>
>  (Walter)
>That feature is potentially pretty useful and has been requested a couple times already, but it has not been implemented.
>
>

I like this type of self-awareness.  In Perl and in the C preprocessor, there are capabilities (self-awareness) to extract the line number, method name, file name, etc.  This type of thing reduces the need for the preprocessor. Perhaps this is already part of D, but I haven't read the entire book yet.

Thanks,
Ken Yale

In article <bt4eha$a2j$1@digitaldaemon.com>, Walter says...

>> 4)  For low-level drivers and other systems work, I've generally used
>> bit-fields,
>> even though they are not "portable".  But since I'm mostly concerned with
>> MY hardware,  I typically don't care about this.  The few times I've
>needed to
>> port bit fields, this type of kludge tends to work fine:
>>
>> typedef struct Some32bitHardware
>> {
>> #ifdef  LITTLE_ENDIAN
>> unsigned int mStatusBits        :   7;
>> unsigned int mCommandBits : 25;
>> #else
>> unsigned int mCommandBits : 25;
>> unsigned int mStatusBits         :   7;
>> #endif
>> } ;
>>
>> Here's my question  -- since D doesn't support bitfields,  can I bind enum
>> bitfields in some fashion to ensure the proper bits are set/cleared?
>> Can I embed the enums in their associated hardware structures?  Even
>> though this is ugly, it reduces naming confusion.
>
>I think I understand what you mean, and it should work.

I actually dumbed-down my question by quite a bit, as my query
was getting long, and I was getting tired.   Here's a more accurate
question, potentially requiring some sort of change to make D a
systems language.

To read/modify/write a 32-bit I/O port mapped to a specific address in C, here's some naive code.  Assume that this port has 7 bits of status (read-only), 2 bits of read/write interrupt control, and 23 bits of command.

#define PORT                       0x1234
#define STATUS_BITS       0xFE00000
#define COMMAND_BITS 0x01FFFFFC
#define INTR_CONTROL_BITS  0x3


int
SetPortCommand_and_GetStatus(int cmd)
{
volatile int* pPort = (volatile int*) PORT
int tmp = *pPort & ~INTR_CONTROL_BITS;
tmp |= (cmd << 2) & COMMAND_BITS;
*pPort = tmp;
return *pPort >> 25;
}

Pretty ugly -- I'll try again using bit fields and better macros is a little better:

struct HardwarePort
{
unsigned int mStatus  :  7;
unsigned int mControl :  23;
unsigned int mIntr : 2;
};

#define BETTER_PORT (static_cast<volatile HardwarePort*> (0x1234))

int
BetterSetPortCommand_and_GetStatus(int cmd)
{
volatile int* pPort = BETTER_PORT;
HardwarePort tmp = *pPort;
tmp.mCommand = cmd;
*pPort = tmp;
return pPort ->mStatus;
}

Note the dual use of the HardwarePort - non-volatile so I'm not forced to use read/modify/write, and volatile when I actually declare the pointer to it.  The code could be reduced to this:

BETTER_PORT->mCommand = cmd;
return BETTER_PORT->mStatus;

which better captures the nature of the code.  Of course any such real code would control interrupts better:

int oldIntr = BETTER_PORT->mIntr;
BETTER_PORT->mIntr = DISABLE_PORT_INTERRUPTS;
BETTER_PORT->mCommand = cmd;
BETTER_PORT->mIntr = oldIntr;
return BETTER_PORT->mStatus;

Many C/C++ system programmers shy away from bit fields because
of portability, replacing this type of functionality with macros to handle
masking and shifting.  This makes the code less maintainable IMHO.

Can "D" do better?  I'd like to see this happen!

As a side issue, is there a self-awareness attribute that can be tested to deterimine endedness?

Many thanks, and keep up the Good Work, Walter!


Ken Yale

--- When the going gets wierd, the wierd turn professional ---  (H. S. Thompson)

"Ken Yale" <Ken_member@pathlink.com> wrote in message news:bt5p6q$2819$1@digitaldaemon.com...
> Can "D" do better?  I'd like to see this happen!

No, sorry. D doesn't improve on C's semantics there.

> As a side issue, is there a self-awareness attribute that can be tested to deterimine endedness?

Yes:
    version (LittleEndian)
or:
    version (BigEndian)

> Many thanks, and keep up the Good Work, Walter!

Thanks!