Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Most "active" coroutine library project?

Reply
Thread Tools

Most "active" coroutine library project?

 
 
Dennis Lee Bieber
Guest
Posts: n/a
 
      09-26-2009
On Fri, 25 Sep 2009 14:22:51 +0000 (UTC), Grant Edwards
<(E-Mail Removed)> declaimed the following in
gmane.comp.python.general:

>
> EXX accomplised much of the context switch operation. I don't
> remember how much RAM was available, but it wasn't much...
>

Zilog Z80... as with the rest of the "improved" 8080 family -- 64kB
address space...
--
Wulfraed Dennis Lee Bieber KD6MOG
http://www.velocityreviews.com/forums/(E-Mail Removed) HTTP://wlfraed.home.netcom.com/

 
Reply With Quote
 
 
 
 
Dennis Lee Bieber
Guest
Posts: n/a
 
      09-26-2009
On Fri, 25 Sep 2009 16:55:04 +0200, Piet van Oostrum <(E-Mail Removed)>
declaimed the following in gmane.comp.python.general:

>
> The first time I encountered coroutines was in Simula-67. Coroutine
> switching was certainly explicit there. IIRC, the keyword was resume.


Lucky you...

Xerox Sigma 6, CP/V, using Xerox Extended FORTRAN IV. It had, as I
recall, some means (besides the ASSIGNed GOTO) of passing labels between
caller and callee, such that the callee could "return" to a statement
not immediately following the call -- along with being able to call into
particular labels, not just the top of the routine.
--
Wulfraed Dennis Lee Bieber KD6MOG
(E-Mail Removed) HTTP://wlfraed.home.netcom.com/

 
Reply With Quote
 
 
 
 
Dave Angel
Guest
Posts: n/a
 
      09-26-2009
Dennis Lee Bieber wrote:
> On Fri, 25 Sep 2009 14:22:51 +0000 (UTC), Grant Edwards
> <(E-Mail Removed)> declaimed the following in
> gmane.comp.python.general:
>
>
>> EXX accomplised much of the context switch operation. I don't
>> remember how much RAM was available, but it wasn't much...
>>
>>

> Zilog Z80... as with the rest of the "improved" 8080 family -- 64kB
> address space...
>

I knew of one Z80 implementation which gave nearly 128k to the user.
Code was literally in a separate 64k page from data, and there were
special ways to access it, when you needed to do code-modification on
the fly. The 64k bank select was normally chosen on each bus cycle by
status bits from the CPU indicating whether it was part of an
instruction fetch or a data fetch.

Actually even 64k looked pretty good, compared to the 1.5k of RAM and 2k
of PROM for one of my projects, a navigation system for shipboard use.

DaveA
 
Reply With Quote
 
Grant Edwards
Guest
Posts: n/a
 
      09-26-2009
On 2009-09-26, Dennis Lee Bieber <(E-Mail Removed)> wrote:
> On Fri, 25 Sep 2009 14:22:51 +0000 (UTC), Grant Edwards
><(E-Mail Removed)> declaimed the following in
> gmane.comp.python.general:
>
>>
>> EXX accomplised much of the context switch operation. I don't
>> remember how much RAM was available, but it wasn't much...

>
> Zilog Z80... as with the rest of the "improved" 8080 family --
> 64kB address space...


Right. I meant I didn't recall how much RAM was available in
that particular product. Using the shadow register set to
store context is limiting when compared to just pushing
everything onto the stack and then switching to another stack,
but that does require more RAM.

--
Grant
 
Reply With Quote
 
Grant Edwards
Guest
Posts: n/a
 
      09-26-2009
On 2009-09-26, Dave Angel <(E-Mail Removed)> wrote:

> Actually even 64k looked pretty good, compared to the 1.5k of
> RAM and 2k of PROM for one of my projects, a navigation system
> for shipboard use.


I've worked on projects as recently as the past year that had
only a couple hundred bytes of RAM, and most of it was reserved
for a message buffer.

--
Grant

 
Reply With Quote
 
Piet van Oostrum
Guest
Posts: n/a
 
      09-27-2009
>>>>> Grant Edwards <(E-Mail Removed)> (GE) wrote:

>GE> On 2009-09-25, Piet van Oostrum <(E-Mail Removed)> wrote:
>>>>>>>> (E-Mail Removed) (e) wrote:
>>>

>e> I specifically left out all "yield" statements in my version, since that's
>e> exactly the point here. With "real" coroutines, they're not necessary -
>e> coroutine calls look just like any other call. With Python's enhanced
>e> generators, they are.
>>>
>>> The first time I encountered coroutines was in Simula-67. Coroutine
>>> switching was certainly explicit there. IIRC, the keyword was resume.


>GE> I'm not sure exactly what "coroutine calls" refers to, but the
>GE> "mis-feature" in Python co-routines that's being discussed is
>GE> the fact that you can only yeild/resume from the main coroutine
>GE> function.


Yes, I know, but the discussion had drifted to making the yield
invisible, if I understood correctly.

>GE> You can't call a function that yields control back to the other
>GE> coroutine(s). By jumping through some hoops you can get the
>GE> same effect, but it's not very intuitive and it sort of "feels
>GE> wrong" that the main routine has to know ahead of time when
>GE> calling a function whether that function might need to yield or
>GE> not.


I know. I think this is an implementation restriction in Python, to make
stack management easier. Although if you would lift this restriction
some new syntax would have to be invented to distinguish a generator
from a normal function.
--
Piet van Oostrum <(E-Mail Removed)>
URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4]
Private email: (E-Mail Removed)
 
Reply With Quote
 
Hendrik van Rooyen
Guest
Posts: n/a
 
      09-28-2009
On Saturday, 26 September 2009 16:55:30 Grant Edwards wrote:
> On 2009-09-26, Dave Angel <(E-Mail Removed)> wrote:
> > Actually even 64k looked pretty good, compared to the 1.5k of
> > RAM and 2k of PROM for one of my projects, a navigation system
> > for shipboard use.

>
> I've worked on projects as recently as the past year that had
> only a couple hundred bytes of RAM, and most of it was reserved
> for a message buffer.


There is little reason to do that nowadays - one can buy a single cycle 8032
running at 30 MHz with 16/32/64k of programming flash and ik of RAM, as well
as some bytes of eeprom for around US$10-00. - in one off quantities.

- Hendrik

 
Reply With Quote
 
Grant Edwards
Guest
Posts: n/a
 
      09-28-2009
On 2009-09-28, Hendrik van Rooyen <(E-Mail Removed)> wrote:
> On Saturday, 26 September 2009 16:55:30 Grant Edwards wrote:
>> On 2009-09-26, Dave Angel <(E-Mail Removed)> wrote:
>> > Actually even 64k looked pretty good, compared to the 1.5k of
>> > RAM and 2k of PROM for one of my projects, a navigation system
>> > for shipboard use.

>>
>> I've worked on projects as recently as the past year that had
>> only a couple hundred bytes of RAM, and most of it was reserved
>> for a message buffer.

>
> There is little reason to do that nowadays - one can buy a
> single cycle 8032 running at 30 MHz with 16/32/64k of
> programming flash and ik of RAM, as well as some bytes of
> eeprom for around US$10-00. - in one off quantities.


$10 is pretty expensive for a lot of applications. I bet that
processor also uses a lot of power and takes up a lot of board
space. If you've only got $2-$3 in the money budget, 200uA at
1.8V in the power budget, and 6mm X 6mm of board-space, your
choices are limited.

Besides If you can get by with 256 or 512 bytes of RAM, why pay
4X the price for a 1K part?

Besides which, the 8032 instruction set and development tools
are icky compared to something like an MSP430 or an AVR.

[The 8032 is still head and shoulders above the 8-bit PIC
family.]

--
Grant

 
Reply With Quote
 
Arlo Belshee
Guest
Posts: n/a
 
      09-28-2009
On Sep 25, 2:07*pm, Grant Edwards <(E-Mail Removed)> wrote:
> On 2009-09-25, Jason Tackaberry <(E-Mail Removed)> wrote:
>
> > And I maintain that requiring yield doesn't make it any less a
> > coroutine.

>
> > Maybe we can call this an aesthetic difference of opinion?

>
> Certainly.
>
> You've a very valid point that "transparent" can also mean
> "invisible", and stuff happening "invisibly" can be a source of
> bugs. *All the invisible stuff going on in Perl and C++ has
> always caused headaches for me.


There are some key advantages to this transparency, especially in the
case of libraries built on libraries. For example, all the networking
libraries that ship in the Python standard lib are based on the
sockets library. They assume the blocking implementation, but then add
HTTPS, cookie handling, SMTP, and all sorts of higher-level network
protocols.

I want to use non-blocking network I/O for (concurrency) performance.
I don't want to re-write an SMTP lib - my language ships with one.
However, it is not possible for someone to write a non-blocking socket
that is a drop-in replacement for the blocking one in the std lib.
Thus, it is not possible for me to use _any_ of the well-written
libraries that are already part of Python's standard library. They
don't have yields sprinkled throughout, so they can't work with a non-
blocking, co-routine implemented socket. And they certainly aren't
written against the non-blocking I/O APIs.

Thus, the efforts by lots of people to write entire network libraries
that, basically, re-implement the Python standard library, but change
the implementation of 7 methods (bind, listen, accept, connect, send,
recv, close). They end up having to duplicate tens of thousands of
LoC, just to change 7 methods.

That's where transparency would be nice - to enable that separation of
concerns.
 
Reply With Quote
 
Hendrik van Rooyen
Guest
Posts: n/a
 
      09-29-2009
On Monday, 28 September 2009 16:44:48 Grant Edwards wrote:

> $10 is pretty expensive for a lot of applications. I bet that
> processor also uses a lot of power and takes up a lot of board
> space. If you've only got $2-$3 in the money budget, 200uA at
> 1.8V in the power budget, and 6mm X 6mm of board-space, your
> choices are limited.
>
> Besides If you can get by with 256 or 512 bytes of RAM, why pay
> 4X the price for a 1K part?
>
> Besides which, the 8032 instruction set and development tools
> are icky compared to something like an MSP430 or an AVR.
>
> [The 8032 is still head and shoulders above the 8-bit PIC
> family.]


I am biased.
I like the 8031 family.
I have written pre-emptive multitasking systems for it,
as well as state-machine round robin systems.
In assembler.
Who needs tools if you have a half decent macro assembler?
And if the macro assembler is not up to much, then you write your own pre
processor using python.

The 803x bit handling is, in my arrogant opinion, still the best of any
processor. - jump if bit set then clear as an atomic instruction rocks.



Where do you get such nice projects to work on?

- Hendrik


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Need help writing coroutine Matthew Wilson Python 1 11-07-2007 05:38 PM
Flickr: difference between "most relevant" and "most interesting" Max Digital Photography 7 09-26-2007 10:38 PM
Question: How efficient is using generators for coroutine-likeproblems? Carlos Ribeiro Python 3 09-26-2004 05:50 PM
Invoking the Constructor of the Top Most Class in the Hierarchy from the Bottom most class H.MuthuKumaraRajan Java 3 02-04-2004 01:33 PM



Advertisments