www.digitalmars.com         C & C++   DMDScript  

D - Embedded D?

reply yale_ken yahoo.com writes:
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
Jan 01 2004
next sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
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
Jan 02 2004
prev sibling next sibling parent Mark T <Mark_member pathlink.com> writes:
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.
Jan 02 2004
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
<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.
Jan 02 2004
next sibling parent Ken Yale <Ken_member pathlink.com> writes:
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
Jan 02 2004
prev sibling parent reply Ken Yale <Ken_member pathlink.com> writes:
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)
Jan 02 2004
parent "Walter" <walter digitalmars.com> writes:
"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!
Jan 03 2004