From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: Ada platforms and pricing, was: Re: a new language,
 designed for safety !
Date: Mon, 23 Jun 2014 21:40:40 +0100
Organization: A noiseless patient Spider
Message-ID: <lywqc7gy0n.fsf@pushface.org>
References: <lmj8s6$hhp$1@speranza.aioe.org> <85ioo9yukk.fsf@stephe-leake.org>
	<ln6tlg$1vc$1@dont-email.me>
	<255b51cd-b23f-4413-805a-9fea3c70d8b2@googlegroups.com>
	<ln6uv9$bk8$1@dont-email.me>
	<b22db9fb-a73d-438a-8cfd-f0bb1db70eed@googlegroups.com>
	<MPElv.491358$1w1.428312@fx03.iad>
	<5ebe316d-cd84-40fb-a983-9f953f205fef@googlegroups.com>
	<ln7ngt$c8a$1@dont-email.me>
	<2100734262424129975.133931laguest-archeia.com@nntp.aioe.org>
	<lnn5ko$ner$1@loke.gir.dk> <lnn8ff$k42$1@dont-email.me>
	<lnq58f$du2$1@loke.gir.dk> <lnsqus$d4j$1@dont-email.me>
	<lntmdq$p1j$1@loke.gir.dk> <lo7c2h$ura$1@dont-email.me>
	<lo7pea$cm3$1@loke.gir.dk> <c0pv51Ff927U1@mid.individual.net>
	<5156oy7vhg99.17wu6q2ef45ke.dlg@40tude.net>
	<ly1tufj2nh.fsf@pushface.org>
	<18et97c0c22vc$.y98lxxfblijn.dlg@40tude.net>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx05.eternal-september.org;
 posting-host="117da9042fa4d6f5956a9b8f72035635";
	logging-data="22965"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX18ILKsu+6hsIfjm3lNo89p2dNOSOYx4DSw="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (darwin)
Cancel-Lock: sha1:RJzmVZqU9Sr7fU2uGxF+gX02uN4=
	sha1:FbWRAoPG+lOJMf+22GU7+SoU7mY=
Xref: news.eternal-september.org comp.lang.ada:20566
Date: 2014-06-23T21:40:40+01:00
List-Id: <comp.lang.ada>

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Mon, 23 Jun 2014 12:17:38 +0100, Simon Wright wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> Programming a state machine is turning all design upside down. If
>>> there were user-defined task support one could program this as if it
>>> were in proper tasks.
>> 
>> I find it easier to think about state machines as state machines rather
>> than by encoding them using the program counter! I geuss it depends on
>> your starting point.
>
> As an example consider reading from a stream without blocking. When there
> is no more data available you switch to another co-routine (reading another
> stream). This is programmed as if reading from the stream was blocking. The
> co-routine is continued when more data become available. On top of these
> stream could be a mountain of protocols or a whole Ada compiler taking the
> stream as a source. Doing this as a state machine, upside-down driven by
> incoming characters would be extremely tedious.

I can see this would be tedious. As I said, it depends where you're
coming from; I was thinking in terms of buttons being pressed/switches
being closed/limits being reached (which are probably closer to what
small embedded systems are more commonly used for).

> The idea of user-defined tasking is that the user would also provide the
> pool to allocate the task stack and would activate/deactivate his tasks.

Something like green threads?