• Mark T (16/16) Jan 05 2002 As you say Not for:
• Walter (7/22) Jan 05 2002 couldn't
• Juarez Rudsatz (4/6) Jan 07 2002 Maybe this could be changed to :
• Mike Wynn (28/40) Jan 21 2002 the
• Walter (4/7) Jan 21 2002 There won't be any barrier to this. Even in the alpha version, complete

"Mark T" <mt nospam.com> writes:

As you say Not for:
"Real time programming where latency must be guaranteed",

I haven't spent any time with the language except for a quick read of the
DDJ article but D looks a lot like the vapor-ware language I have been
designing in my head for the last year (I am not a compiler writer, I do
real-time programming) except that you have garbage collection. Why couldn't
garbage collection be designed to run as a low-priority background task?
Real time programming requires deterministic behavior but we almost always
have some dead-time. We have recently started to use C++ for real-time
programming and of course we have a very fat programming guidelines manual.

I don't think the language itself has to be open source but the definition
must absolutely be. I like to see both open source compilers like GNU and
commercial ones like Greenhills. GNU keeps the commercial guys "honest".

Either way good luck with your language, the world doesn't need another slow
VM language.

     Mark

"Walter" <walter digitalmars.com> writes:

"Mark T" <mt nospam.com> wrote in message
news:a181j1$1hj6$1 digitaldaemon.com...
 As you say Not for:
 "Real time programming where latency must be guaranteed",

 I haven't spent any time with the language except for a quick read of the
 DDJ article but D looks a lot like the vapor-ware language I have been
 designing in my head for the last year (I am not a compiler writer, I do
 real-time programming) except that you have garbage collection. Why

couldn't
 garbage collection be designed to run as a low-priority background task?

Nobody has figured out how to make that work!

 Real time programming requires deterministic behavior but we almost always
 have some dead-time. We have recently started to use C++ for real-time
 programming and of course we have a very fat programming guidelines

manual.
 I don't think the language itself has to be open source but the definition
 must absolutely be. I like to see both open source compilers like GNU and
 commercial ones like Greenhills. GNU keeps the commercial guys "honest".

 Either way good luck with your language, the world doesn't need another

slow
 VM language.

Thanks!

"Juarez Rudsatz" <juarez correio.com> writes:

 As you say Not for:
 "Real time programming where latency must be guaranteed",


Maybe this could be changed to :

"Real time programming is not in spec, but could be in the future".
This could be a point of competition between many implementations of
language.

"Mike Wynn" <mike.wynn l8night.co.uk> writes:

"Walter" <walter digitalmars.com> wrote in message
news:a187tl$1lm7$1 digitaldaemon.com...
 "Mark T" <mt nospam.com> wrote in message
 news:a181j1$1hj6$1 digitaldaemon.com...
 As you say Not for:
 "Real time programming where latency must be guaranteed",

 I haven't spent any time with the language except for a quick read of


the
 DDJ article but D looks a lot like the vapor-ware language I have been
 designing in my head for the last year (I am not a compiler writer, I do
 real-time programming) except that you have garbage collection. Why

 couldn't
 garbage collection be designed to run as a low-priority background task?

 Nobody has figured out how to make that work!

Several Java implementaions do have semi realtime behaviour,
Insignia for instance have a fully concurrent garbage collector,
the requirement on the OS is that you can place return barriers onto someone
elses stack and can see another threads stacks.
it is also not as simple as having the GC as a low prority task, there are
times when GC much run (if you are geting low on memory becuase there are a
lot of unclaimed objects)
some of these can be solved by allowing the real time thread to interact
with the GC, either triggering it early, or allowing a thread to not be
paused for a given time, but there can still be condidtions when the GC will
be unable to finish before the realtime thread requires it time slice back.
(concurrent and incremental GC do go partway to solving this)
there is also problems with heap management, Java had a realtime extension
that allowed a thread to preallocate memory (basically a thread local cache)
that would the satisfy allocations within a determined time. but only if
only that memory was used.

depending on how realtime you want to be,  you can do it,
I wrote, and have seen running a serial UART interrupt handler that was
written in Java, It was on VxWork x86 and was used by Insignia as a demo of
how realtime Java could be.. policeing the allowable operations was the
biggest hurdle in Java.

IMHO, if D as a language want to get popular commersial appeal it has to
make public the interface to the GC, and allow people access to implement
their own GC stratergies.

Mike

"Walter" <walter digitalmars.com> writes:

"Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
news:a2h51p$1f4p$1 digitaldaemon.com...
 IMHO, if D as a language want to get popular commersial appeal it has to
 make public the interface to the GC, and allow people access to implement
 their own GC stratergies.

There won't be any barrier to this. Even in the alpha version, complete
source to the gc is included.