Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!iuvax!pur-ee!uiucdcs!uiucdcsp!johnson
From: johnson@uiucdcsp.UUCP
Newsgroups: comp.lang.smalltalk
Subject: Re: Smalltalk for (embedded) real-time
Message-ID: <80500016@uiucdcsp>
Date: Sat, 5-Sep-87 16:33:00 EDT
Article-I.D.: uiucdcsp.80500016
Posted: Sat Sep  5 16:33:00 1987
Date-Received: Sun, 6-Sep-87 19:57:49 EDT
References: <1881@tekig4.TEK.COM>
Lines: 43
Nf-ID: #R:tekig4.TEK.COM:1881:uiucdcsp:80500016:000:2498
Nf-From: uiucdcsp.cs.uiuc.edu!johnson    Sep  5 15:33:00 1987


I suppose that the reason why you think that Smalltalk is not suitable
for real-time applications is that it is too slow.  However, I knew
people who wrote real-time applications in Basic on a 6502, and
Smalltalk on a 68020 can run rings around that.  Thus,  you just have
to make sure that your computer is fast enough to keep up with the
real-time constraints of the problem.

Assuming that you think that speed is the problem, there are lots of
ways to speed up Smalltalk programs.  You mentioned two of them;
convert the whole program (automatically) to another language or
convert the inner loops to another language.  I am building an
optimizing compiler for Smalltalk that should make it much faster.
Other people are working on special hardware for Smalltalk that should
make it much faster.  Interpreters keep getting more efficient and
conventional microprocessors keep getting faster, so if Smalltalk is
only a factor of 2 too slow, just wait a year.

There is another problem with Smalltalk that is more severe.  Smalltalk
uses garbage collection a lot.  Garbage collection can easily interfere
with real-time requirements.  The solution is to go back to using the
reference counting techniques that implementors are now ignoring, use
parallel garbage collection, or program very carefully and ensure that
no garbasge is produced.  Of course, any program that produces a lot of
garbage won't convert to Objective C very well, since I think that it
has no garbage collector.  Please correct me if I am wrong.

Lisp systems also use dynamic memory management, so it would be
interesting to see whether anyone has built real-time systems in Lisp
and how they solved these problems.  I would be surprised if nobody has
tried it.

I have a student who is using Smalltalk for music composition.  Her
system is attached to a digital signal processor.  She converts her
compositions into a form that is interpreted by the d.s.p. and plays
them there.  The best way to describe this technique might be "build
special purpose programmable hardware to perform the real-time primitives
and use Smalltalk to control the hardware."  I suppose this is little
different from building these primitives in software using C or assembler.
However, special purpose hardware can be fast enough to completely eliminate
any supposed speed disadvantage of Smalltalk.  In addition, if Smalltalk
is not directly involved in real-time decisions, a second or two of garbage
collection may not make much difference.