Path: utzoo!attcan!uunet!mcsun!tuvie!vmars!alex
From: alex@vmars.tuwien.ac.at (Alexander Vrchoticky)
Newsgroups: comp.realtime
Subject: Re: Software primitives for real-time programming languages
Message-ID: <1844@tuvie>
Date: 20 Sep 90 15:07:31 GMT
References: <12682@cs.utexas.edu>
Sender: news@tuvie
Lines: 57

rhwang@cs.utexas.edu (Rwo-Hsi Wang) writes:

>Sorry if the following questions have been asked before.  Could someone
>tell me:

>1. What kind of software primitives should a language provide in order
>   to be called a (hard) real-time programming language?

For soft real-time systems (i.e. systems where it is not mandatory to 
ascertain before run-time that the deadlines will indeed be met) there 
are a number of primitives that can conveniently be used to express 
real-time constraints, synchronization, priorities and so on. 
For those there exists a very comprehensive survey called the 
Ada Programming Language Reference Manual :-)

For hard real-time systems one could argue that the 
question should be put the other way round:

`What primitives should be specifically excluded from a language so that
 it may be called a hard real-time programming language'

To stimulate discussions I suggest that the 
following should *not* be used for hard real-time systems: 

	o  Explicit synchronization statements (semaphores, rendezvous).
	o  `delay' statements.
	o  Explicit scheduling statements (of the `at 16:30 start foo' type).
	o  Unbounded loops and recursions.
	o  Unstructured control-flow statements (goto).
	o  Dynamic memory allocation.
	o  Dynamic task creation and termination.


Before anyone sets out to commit a ritualistic murder let me state
that I do know of some techniques that can make *some* of the above work
in the hard real-time environment. The question whether this is a good
idea is an entirely different matter.
I strongly believe that for hard real-time systems an integrated
approach encompassing:

	1.  Architecture
	2.  Operating system
	3.  Scheduling strategy 
	4.  Programming language 

is to be preferred over augmenting a general-purpose language with a few 
constructs to express time and synchronization and letting a run-time system 
go through immense pains trying to support it.

I'd like to encourage discussions on this topic and hope that
we can get something more controversial and stimulating going on 
than discussions of the `anyone have a bar-compiler for the foo-board?' type.

--
Alexander Vrchoticky  Technical University Vienna, Dept. for Real-Time Systems
Voice:  +43/222/58801-8168   Fax: +43/222/569149
e-mail: alex@vmars.tuwien.ac.at or vmars!alex@relay.eu.net  (Don't use 'r'!)