Groups > comp.lang.forth > #46543 > unrolled thread

BBC MicroBit has arrived - which Forth in Python is recommended for now?

Started by	JUERGEN <epldfpga@aol.com>
First post	2016-04-06 00:14 -0700
Last post	2016-08-12 11:11 -0400
Articles	20 on this page of 107 — 24 participants

Back to article view | Back to comp.lang.forth

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →

#46687

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2016-04-19 05:15 -0500
Message-ID	<WKednbUBh__ImIvKnZ2dnUU78fmdnZ2d@supernews.com>
In reply to	#46685

Ron Aaron <rambamist@gmail.com> wrote:
> 
> 
> On 19/04/2016 12:04, Andrew Haley wrote:
>> Mark Wills <markwills1970@gmail.com> wrote:
>>>
>>> It's a good language to learn in order to learn about the hardware
>>> that your code is running on, but there's not even a standard,
>>> simple way to open a serial port in Forth, and the serial port has
>>> been obsolete for, what ten, maybe fifteen years?
>> 
>> In what language is there a standard way to open a serial port?
> 
> There is in 8th:  sio:open
> 
> You don't even need to know the name of the port.  You could just do
> this to open the first port:
> 
>  sio:enum a:shift sio:open
> 
> (assuming that there is at least one port)

OK, I shoulda asked in what standardized language is there a standard
way to open a serial port?  :-)

Andrew.

[toc] | [prev] | [next] | [standalone]

#46688

From	Ron Aaron <rambamist@gmail.com>
Date	2016-04-19 13:31 +0300
Message-ID	<nf518h$v8o$1@dont-email.me>
In reply to	#46687


On 19/04/2016 13:15, Andrew Haley wrote:

> OK, I shoulda asked in what standardized language is there a standard
> way to open a serial port?  :-)

Ah, well that's a different question :)

[toc] | [prev] | [next] | [standalone]

#46686

From	Raimond Dragomir <raimond.dragomir@gmail.com>
Date	2016-04-19 02:12 -0700
Message-ID	<d7ad7ca6-2e15-4f46-b037-07bc57c01be6@googlegroups.com>
In reply to	#46684

marți, 19 aprilie 2016, 12:04:27 UTC+3, Andrew Haley a scris:
> Mark Wills <markwills1970@gmail.com> wrote:
> > 
> > It's a good language to learn in order to learn about the hardware
> > that your code is running on, but there's not even a standard,
> > simple way to open a serial port in Forth, and the serial port has
> > been obsolete for, what ten, maybe fifteen years?
> 
> In what language is there a standard way to open a serial port?
> 
> Andrew.

Working in embedded systems for 20 years, still using uarts all over
the place. I have very few designs that don't need at least one...

[toc] | [prev] | [next] | [standalone]

#46689

From	rickman <gnuarm@gmail.com>
Date	2016-04-19 11:48 -0400
Message-ID	<nf5jpj$4no$1@dont-email.me>
In reply to	#46684

On 4/19/2016 5:04 AM, Andrew Haley wrote:
> Mark Wills <markwills1970@gmail.com> wrote:
>>
>> It's a good language to learn in order to learn about the hardware
>> that your code is running on, but there's not even a standard,
>> simple way to open a serial port in Forth, and the serial port has
>> been obsolete for, what ten, maybe fifteen years?
>
> In what language is there a standard way to open a serial port?

I thought you could use the same commands as opening a file?  Isn't that 
the way it works in C?  Or are you saying that the different names used 
under different OS makes it not standard?

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#46692

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2016-04-20 04:07 -0500
Message-ID	<T_ydnam545JU24rKnZ2dnUU78XWdnZ2d@supernews.com>
In reply to	#46689

rickman <gnuarm@gmail.com> wrote:
> On 4/19/2016 5:04 AM, Andrew Haley wrote:
>> Mark Wills <markwills1970@gmail.com> wrote:
>>>
>>> It's a good language to learn in order to learn about the hardware
>>> that your code is running on, but there's not even a standard,
>>> simple way to open a serial port in Forth, and the serial port has
>>> been obsolete for, what ten, maybe fifteen years?
>>
>> In what language is there a standard way to open a serial port?
> 
> I thought you could use the same commands as opening a file?  Isn't
> that the way it works in C?  Or are you saying that the different
> names used under different OS makes it not standard?

No, that's not the way it works in C.  It's the way it works in UNIX,
for sure, but in C we don't know that the serial port is accessed as a
file and we certainly don't know how to do simple things like setting
the baud rate.  If the serial port is a file then Forth can open it as
a file just like any other programming language.

Andrew.

[toc] | [prev] | [next] | [standalone]

#46693

From	minforth@arcor.de
Date	2016-04-20 04:35 -0700
Message-ID	<d7cf3640-40bd-489a-856e-c5441b93d943@googlegroups.com>
In reply to	#46692

> 
> No, that's not the way it works in C.  It's the way it works in UNIX,
> for sure, but in C we don't know that the serial port is accessed as a
> file and we certainly don't know how to do simple things like setting
> the baud rate.  If the serial port is a file then Forth can open it as
> a file just like any other programming language.
> 
> Andrew.

Correct. However many C compilers offer a _nonstandard_ library
conio.h with _inp/_outp functions to read/write ports.

[toc] | [prev] | [next] | [standalone]

#46696

From	Bernd Paysan <bernd.paysan@gmx.de>
Date	2016-04-20 21:11 +0000
Message-ID	<nf8r9v$4qn$1@dont-email.me>
In reply to	#46693

Am Wed, 20 Apr 2016 04:35:08 -0700 schrieb minforth:
> Correct. However many C compilers offer a _nonstandard_ library conio.h
> with _inp/_outp functions to read/write ports.

Oh, _inp/_outp is very DOS-related...

Most Forth systems that have access to serial ports have ways to access 
the serial port in a pretty simple way; usually, you can open it by name, 
and set the baud rate; the rest is usually set reasonable (8N1).

If I look at how much effort it is to set a serial port in Unix, it is 
way more complicated: Not only is it setting the baud rate, but you also 
need to set the serial tty into a "raw" mode, where it doesn't send 
signals, doesn't convert characters into other characters and so on; 
things you may need if the serial port is a terminal attached to an old 
Unix computer, but completely unrelated to using a serial port to an 
embedded device, where the PC is the terminal.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#46702

From	minforth@arcor.de
Date	2016-04-21 05:31 -0700
Message-ID	<fd648d6a-558c-49f0-80fc-1f9e684e679f@googlegroups.com>
In reply to	#46696

Am Mittwoch, 20. April 2016 23:14:51 UTC+2 schrieb Bernd Paysan:
> Am Wed, 20 Apr 2016 04:35:08 -0700 schrieb minforth:
> > Correct. However many C compilers offer a _nonstandard_ library conio.h
> > with _inp/_outp functions to read/write ports.
> 
> Oh, _inp/_outp is very DOS-related...
> 
> Most Forth systems that have access to serial ports have ways to access 
> the serial port in a pretty simple way; usually, you can open it by name, 
> and set the baud rate; the rest is usually set reasonable (8N1).
> 
> If I look at how much effort it is to set a serial port in Unix, it is 
> way more complicated: Not only is it setting the baud rate, but you also 
> need to set the serial tty into a "raw" mode, where it doesn't send 
> signals, doesn't convert characters into other characters and so on; 
> things you may need if the serial port is a terminal attached to an old 
> Unix computer, but completely unrelated to using a serial port to an 
> embedded device, where the PC is the terminal.
> 

Yes, you're right. And in microcontrollers, memory mapped I/O is very common. So there just is no golden way to circumvent the bare metal.

[toc] | [prev] | [next] | [standalone]

#46703

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2016-04-21 09:22 -0500
Message-ID	<d_qdnVnUrr2Cf4XKnZ2dnUU7-KvNnZ2d@supernews.com>
In reply to	#46696

Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Am Wed, 20 Apr 2016 04:35:08 -0700 schrieb minforth:
>> Correct. However many C compilers offer a _nonstandard_ library conio.h
>> with _inp/_outp functions to read/write ports.
> 
> Oh, _inp/_outp is very DOS-related...
> 
> Most Forth systems that have access to serial ports have ways to
> access the serial port in a pretty simple way; usually, you can open
> it by name, and set the baud rate; the rest is usually set
> reasonable (8N1).

That's right.  The early Forth way to do it (from Chuck Moore's Forth,
Inc. days on) was to have a task per serial port.  That task's TYPE
and EXPECT (and also STRAIGHT, for raw I/O) use its serial port.  You
don't need non- blocking I/O or anything like that because the task
can handle it asynchronously, and the task can be tiny.  If you need
to send a message to something connected to that serial port, ask the
task to do it.  The idea of "opening" a serial port didn't really
arise.

It was a completely different way to think about communications ports
than what I was used to, and it took me some time to get the hang of
it.  But after a while I came to love the approach: it is a powerful
and radically simple way to write applications which use multiple
communications ports.  Today the idea of structuring an application so
that it has a lot of asynchronous processes communicating through
mailboxes or queues is quite commonplace, but it was a revelation to
me.

Andrew.

[toc] | [prev] | [next] | [standalone]

#46740

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2016-04-24 15:45 +0000
Message-ID	<2016Apr24.174508@mips.complang.tuwien.ac.at>
In reply to	#46703

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>That's right.  The early Forth way to do it (from Chuck Moore's Forth,
>Inc. days on) was to have a task per serial port.  That task's TYPE
>and EXPECT (and also STRAIGHT, for raw I/O) use its serial port.  You
>don't need non- blocking I/O or anything like that because the task
>can handle it asynchronously, and the task can be tiny.

How does full duplex work with that?  Do you have one task for reading
from the port and one task for writing to it?  That would be two tasks
per port, then.

Certainly an interesting design, and it reminds me of the current
practice in the Linux kernel to have kernel threads in similar cases
where one would otherwise have to introduce asynchronous (non-blocking
etc.) interfaces.

So how did one communicate with these tasks?  Was this really simpler
than an asynchronous interface?  I can imagine that it's more
powerful, though; e.g., the task can buffer input if needed, or not,
if not.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

[toc] | [prev] | [next] | [standalone]

#46745

From	Paul Rubin <no.email@nospam.invalid>
Date	2016-04-24 11:23 -0700
Message-ID	<87inz6lvbx.fsf@nightsong.com>
In reply to	#46740

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> How does full duplex work with that?  Do you have one task for reading
> from the port and one task for writing to it?  That would be two tasks
> per port, then....  Certainly an interesting design

I never programmed multitasking Forth but two threads (or processes) per
port is a very typical way to do these things in other systems.

> So how did one communicate with these tasks?  Was this really simpler
> than an asynchronous interface?

With mailboxes.  There's an article by Brad Rodriguez about it and the
interface is similar to how it's done in Go, Python, Erlang, etc.
Whether it's simpler than async is yet another of those dreary
opinionated topics with proponents on both sides.  I myself find it
simpler.  Most Python users prefer async so I'm in the minority (Python
supports both styles).  In Go, Erlang, and Haskell, multiple lightweight
processes/threads/"goroutines" are the norm.  

Python users may be thread-averse because Python uses OS threads which
are fairly expensive.  Java also usually uses OS threads and for a long
time had no way to do async at all, but (true to form for Java) people
didn't care how expensive it was until they had to.

[toc] | [prev] | [next] | [standalone]

#48212

From	lawrencedo99@gmail.com
Date	2016-06-15 21:29 -0700
Message-ID	<a883f9c0-3a5a-415e-8047-e12630d06f5f@googlegroups.com>
In reply to	#46745

On Monday, April 25, 2016 at 6:23:31 AM UTC+12, Paul Rubin wrote:
> Python users may be thread-averse because Python uses OS threads which
> are fairly expensive.

Threading on modern OSes like Linux is quite cheap.

You’re not talking about Windows, are you?

Python users avoid threads because the GIL prevents them from taking full advantage of multiple CPUs.

In general, use of threading in any language can be fraught because their default “share everything” approach can lead to many hard-to-find bugs.

[toc] | [prev] | [next] | [standalone]

#46746

From	"Elizabeth D. Rather" <erather@forth.com>
Date	2016-04-24 09:40 -1000
Message-ID	<cfydnXQ0r-3YvIDKnZ2dnUU7-QHNnZ2d@supernews.com>
In reply to	#46740

On 4/24/16 5:45 AM, Anton Ertl wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> That's right.  The early Forth way to do it (from Chuck Moore's Forth,
>> Inc. days on) was to have a task per serial port.  That task's TYPE
>> and EXPECT (and also STRAIGHT, for raw I/O) use its serial port.  You
>> don't need non- blocking I/O or anything like that because the task
>> can handle it asynchronously, and the task can be tiny.
>
> How does full duplex work with that?  Do you have one task for reading
> from the port and one task for writing to it?  That would be two tasks
> per port, then.

No. The serial port is the task's "terminal". A task has a current input 
device and a current output device, and the serial port normally 
fulfills both functions.

> Certainly an interesting design, and it reminds me of the current
> practice in the Linux kernel to have kernel threads in similar cases
> where one would otherwise have to introduce asynchronous (non-blocking
> etc.) interfaces.
>
> So how did one communicate with these tasks?  Was this really simpler
> than an asynchronous interface?  I can imagine that it's more
> powerful, though; e.g., the task can buffer input if needed, or not,
> if not.

There are various ways. The intended design was that each task had a 
semi-autonomous job description, analogous to an employee in a business. 
There were variables and other data structures in shared memory that 
could be used for inter-task communication. Also, one task can assign 
another a function by a mechanism that equated to pushing the address of 
a definition onto its return stack. There was also a mechanism, usually 
used for printer tasks, wherein a human user could type PRINT followed 
by one or more commands in the input stream and the input stream 
following the word PRINT was moved to the printer's input stream and it 
would interpret it.

Much of this, including design guidelines, is discussed in the 
multitasker sections of Forth Application Techniques and other books.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#46747

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2016-04-24 20:18 +0000
Message-ID	<2016Apr24.221835@mips.complang.tuwien.ac.at>
In reply to	#46746

"Elizabeth D. Rather" <erather@forth.com> writes:
>On 4/24/16 5:45 AM, Anton Ertl wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> That's right.  The early Forth way to do it (from Chuck Moore's Forth,
>>> Inc. days on) was to have a task per serial port.  That task's TYPE
>>> and EXPECT (and also STRAIGHT, for raw I/O) use its serial port.  You
>>> don't need non- blocking I/O or anything like that because the task
>>> can handle it asynchronously, and the task can be tiny.
>>
>> How does full duplex work with that?  Do you have one task for reading
>> from the port and one task for writing to it?  That would be two tasks
>> per port, then.
>
>No. The serial port is the task's "terminal". A task has a current input 
>device and a current output device, and the serial port normally 
>fulfills both functions.

But then I don't see how "you don't need non-blocking I/O" works.

E.g., the task EMITs to the serial port and that blocks because the
other side is not ready; meanwhile, input is coming on the serial
port.  After the hardware buffers are full, data will be lost.

Or, the task KEYs from the serial port and waits for input; meanwhile,
some other task C wants to tell the serial-port task to send
something, and then something more.  But the serial-port task is
blocked and not reacting to the message, so at some point it's mailbox
is full, and C has to decide whether it wants to overwrite the stuff
in the mail box, or block itself.

Anyway, certainly not a full duplex connection.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

[toc] | [prev] | [next] | [standalone]

#46748

From	"Elizabeth D. Rather" <erather@forth.com>
Date	2016-04-24 14:56 -1000
Message-ID	<nNidnStqC7209oDKnZ2dnUU7-dfNnZ2d@supernews.com>
In reply to	#46747

On 4/24/16 10:18 AM, Anton Ertl wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> On 4/24/16 5:45 AM, Anton Ertl wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>> That's right.  The early Forth way to do it (from Chuck Moore's Forth,
>>>> Inc. days on) was to have a task per serial port.  That task's TYPE
>>>> and EXPECT (and also STRAIGHT, for raw I/O) use its serial port.  You
>>>> don't need non- blocking I/O or anything like that because the task
>>>> can handle it asynchronously, and the task can be tiny.
>>>
>>> How does full duplex work with that?  Do you have one task for reading
>>> from the port and one task for writing to it?  That would be two tasks
>>> per port, then.
>>
>> No. The serial port is the task's "terminal". A task has a current input
>> device and a current output device, and the serial port normally
>> fulfills both functions.
>
> But then I don't see how "you don't need non-blocking I/O" works.
>
> E.g., the task EMITs to the serial port and that blocks because the
> other side is not ready; meanwhile, input is coming on the serial
> port.  After the hardware buffers are full, data will be lost.
>
> Or, the task KEYs from the serial port and waits for input; meanwhile,
> some other task C wants to tell the serial-port task to send
> something, and then something more.  But the serial-port task is
> blocked and not reacting to the message, so at some point it's mailbox
> is full, and C has to decide whether it wants to overwrite the stuff
> in the mail box, or block itself.
>
> Anyway, certainly not a full duplex connection.

The design of a task is an integral aspect of the application. A task 
isn't just the owner of a port, it has a larger responsibility than 
that. A simple case (the original model) is a task supporting a human 
user who types on the keyboard and sees stuff on the screen. A data 
acquisition task is acquiring data on the port and storing it somewhere, 
possibly performing operations (validation, scaling, etc.) along the 
way. A port would not normally be shared; in the case of a printer, it 
would block while generating and printing a document at the request of 
another task, but in most applications it is not necessary or 
appropriate to treat a port as a resource in that sense.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#46754

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2016-04-25 03:13 -0500
Message-ID	<Ka6dnfbt-t8iTIDKnZ2dnUU7-K_NnZ2d@supernews.com>
In reply to	#46740

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>That's right.  The early Forth way to do it (from Chuck Moore's Forth,
>>Inc. days on) was to have a task per serial port.  That task's TYPE
>>and EXPECT (and also STRAIGHT, for raw I/O) use its serial port.  You
>>don't need non- blocking I/O or anything like that because the task
>>can handle it asynchronously, and the task can be tiny.
> 
> How does full duplex work with that?  Do you have one task for reading
> from the port and one task for writing to it?  That would be two tasks
> per port, then.

I have never seen separate tasks for send and receive.  But you're
quite right, it doesn't work with full duplex.  If you want that, you
have to do something different.  (This is a case of the more general
rule which is not to over-generalize solutions: just do the simple
thing that you need.)  Having said that, there is a race between
sending a packet and starting the recieve, so it is sometimes
necessary to have a version of TYPE which takes the address of a
receive buffer as well as a transmit buffer so that nothing gets lost.

> Certainly an interesting design, and it reminds me of the current
> practice in the Linux kernel to have kernel threads in similar cases
> where one would otherwise have to introduce asynchronous
> (non-blocking etc.) interfaces.

I think that's essentially the same idea.

> So how did one communicate with these tasks?  Was this really
> simpler than an asynchronous interface?  I can imagine that it's
> more powerful, though; e.g., the task can buffer input if needed, or
> not, if not.

The task handles the entire communications protocol and might even do
database updates as well.  The way to communicate with these tasks is
entirely application-dependent.  At its very simplest you'd write:

   : poll   taskname activate  do-some-stuff ;

Andrew.

[toc] | [prev] | [next] | [standalone]

#46763

From	Paul Rubin <no.email@nospam.invalid>
Date	2016-04-25 14:23 -0700
Message-ID	<87twipjscc.fsf@nightsong.com>
In reply to	#46754

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> I have never seen separate tasks for send and receive.  But you're
> quite right, it doesn't work with full duplex.  

Interesting, wonder why they did it that way, given how lightweight
Forth tasks are.

> If you want that, you have to do something different.  (This is a case
> of the more general rule which is not to over-generalize solutions:
> just do the simple thing that you need.) 

I think it's simpler to use two tasks than use extra logic to keep track
of which way the port is going, swap directions, etc.  I've always done
it with two (not in Forth yet though) and it's quite natural.

[toc] | [prev] | [next] | [standalone]

#46764

From	"Elizabeth D. Rather" <erather@forth.com>
Date	2016-04-25 14:07 -1000
Message-ID	<Fd2dnQ-KbvWgLIPKnZ2dnUU7-SXNnZ2d@supernews.com>
In reply to	#46763

On 4/25/16 11:23 AM, Paul Rubin wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> I have never seen separate tasks for send and receive.  But you're
>> quite right, it doesn't work with full duplex.
>
> Interesting, wonder why they did it that way, given how lightweight
> Forth tasks are.
>
>> If you want that, you have to do something different.  (This is a case
>> of the more general rule which is not to over-generalize solutions:
>> just do the simple thing that you need.)
>
> I think it's simpler to use two tasks than use extra logic to keep track
> of which way the port is going, swap directions, etc.  I've always done
> it with two (not in Forth yet though) and it's quite natural.

It really depends on how you think about what a "task" is. If you think 
of a task as a "person" with a set of responsibilities (e.g., accepting 
data from a device, processing it, and recording it) then you look at 
how that port is being used. I can't think offhand of a case in which a 
full-duplex port literally has concurrent streams of data flowing in and 
out. Examples that come to mind are a port that may be doing continuous 
output until an input signals that it should stop, or one that is 
receiving data and sends a signal to stop when it has enough. Both these 
examples make logical sense as the responsibility of a single task that 
knows what it's doing. The actual reception or transmission of 
individual events would be done in interrupt code. To actually set up 
two tasks, even though these tasks are pretty lightweight, adds the 
necessity for them to communicate in ways that complicate the process 
considerably.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#46770

From	Paul Rubin <no.email@nospam.invalid>
Date	2016-04-25 21:36 -0700
Message-ID	<87potdj89g.fsf@nightsong.com>
In reply to	#46764

"Elizabeth D. Rather" <erather@forth.com> writes:
> It really depends on how you think about what a "task" is. If you
> think of a task as a "person" with a set of responsibilities (e.g.,
> accepting data from a device, processing it, and recording it) then
> you look at how that port is being used.

One person accepting data, one sending data, and one recording it,
maybe.

> I can't think offhand of a case in which a full-duplex port literally
> has concurrent streams of data flowing in and out.

That's the *definition* of a full-duplex port! ;-)

> Examples that come to mind are a port that may be doing continuous
> output until an input signals that it should stop, or one that is
> receiving data and sends a signal to stop when it has enough. 

Think of a phone conversation where both people can talk at the same
time, or a rendezvous where two people each hand a suitcase full of
data to the other (simultaneous file transfers in both directions).

> To actually set up two tasks, even though these tasks are pretty
> lightweight, adds the necessity for them to communicate in ways that
> complicate the process considerably.

Shrug, I think it's more complicated to figure out how to juggle the
necessary stuff in one task.  Doing it with 2 tasks is simple and
general and I've done it that way tons of times.  I hear all kinds of
dire stories about locking and synchronization errors but none of that
has ever happened to me.  The main simplifying principles are 1)
communicate between tasks only through mailboxes (never through shared
memory) and 2) any piece of mutable data should be owned by exactly one
task and only accessed (whether reading or writing) by that task.  If
any other task something done with the data it can query the owning task
through a mailbox.

[toc] | [prev] | [next] | [standalone]

#46778

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2016-04-26 11:32 +0000
Message-ID	<2016Apr26.133217@mips.complang.tuwien.ac.at>
In reply to	#46764

"Elizabeth D. Rather" <erather@forth.com> writes:
>I can't think offhand of a case in which a 
>full-duplex port literally has concurrent streams of data flowing in and 
>out.

The other end is a user terminal, and is busy typing out the answer to
the user's last request, while the user is already typing in the next
request (typeahead).

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

[toc] | [prev] | [next] | [standalone]

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →

csiph-web

BBC MicroBit has arrived - which Forth in Python is recommended for now?

Contents

#46687

#46688

#46686

#46689

#46692

#46693

#46696

#46702

#46703

#46740

#46745

#48212

#46746

#46747

#46748

#46754

#46763

#46764

#46770

#46778