D vs. ISRs (interrupt service routines) or Which D language features implictly allocate memory?

Alexander Panek alexander.panek at brainsware.org
Sat May 5 01:04:41 PDT 2007


On Sat, 05 May 2007 02:11:08 -0400
Forest Ray <disto at flying-guillotine.com> wrote:

> One of D's intended uses is systems level programming.  These tasks
> include implementing ISR (interrupt service routines).  Generally
> speaking it is a very bad idea to allocate memory within an ISR,
> unless your memory system is reentrant.  Many memory managers,
> especially in the embedded environment, are not reentrant.  What
> language features of D implicitly allocate or resize memory?  I
> assume dynamic arrays, associative arrays, splicing, and
> concatenation will, but what else?  Obviously "new" allocates memory,
> but that is an explicit request by the programmer, not an implicit
> request as a side effect of a D language feature.  It would be very
> useful to have the ability to tag a scope of code as "native" or
> "pure" or "some_better_keyword" so the D compiler would issue an
> error for any expressions or statements within that scope that
> implicitly allocate/resized memory.  Thoughts, comments?
> 
> Forest

You can use any language features that do not require dynamic memory
allocation, as you said already. 

The things requiring the GC are:
 - dynamic arrays, associative arrays
 - array slicing when you .dup the slice (I think, at least. If you
don't duplicate the slice, it'll only be a from-to-reference to the
original array)
 - array concatination
 - dynamic class instantiation (new)
 - debug features: always use the -release or -frelease switch, as
there are debug functions added you would have to provide yourself if
you don't link with a runtime library. Also, most of 'em require a GC,
IIRC.

Unfortunately some internal stuffies use these kind of features, too,
at times, which means that you have to hack together either a memory
manager + GC that is available at compile time, or try to work around
that by providing functions which are only statically using memory.

Splicing seems to be concatination? If so, this also requires a GC.
Maybe this can be worked around with hacking the internals, too, but
that's not recommended.

Kind regards,
Alex



More information about the Digitalmars-d mailing list