Diabetic (alt.food.diabetic) This group is for the discussion of controlled-portion eating plans for the dietary management of diabetes.

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #81 (permalink)   Report Post  
Posted to alt.food.diabetic,alt.support.diabetes
external usenet poster
 
Posts: 135
Default unplugging...

On 9/19/2010 7:44 AM, cshenk wrote:
> "Bjørn Steensrud" wrote
>> Boomer wrote:

>
>> By that token I am - or was - a real programmer. I wrote a channel
>> program for an IBM 360, to drive a paper tape punch. IBM had delivered
>> the
>> hardware, but no software :-) I can't remember what the OS was ...

>
> BSD I think (Unix version), if not, System 5 comes to mind?
>
> They were still around in the early 80's and worked on them (among others).
>
> Now I just do SQL.


If it was an IBM operating system, I'd consider DOS (the mainframe
version, not the PC version), OS, and MVS more likely.

Robert Miles
  #82 (permalink)   Report Post  
Posted to alt.food.diabetic,alt.support.diabetes
external usenet poster
 
Posts: 6
Default unplugging...

Robert Miles > wrote:
> On 9/25/2010 12:52 AM, Chris Malcolm wrote:


Why respond *now*? Couldn't you wait a *little* longer for the first
anniversary!?

> > In alt.support.diabetes Ellen > wrote:
> >> "Chris > wrote in message
> >> ...
> >>> In alt.support.diabetes Ellen >
> >>> wrote:
> >>>> "Chris > wrote in message
> >>>> ...
> >>>>> In alt.support.diabetes Ellen >
> >>>>> wrote:
> >>>>>> "Chris > wrote in message
> >>>>>> ...

> [snip]
> > Coroutines differ in a number of ways from subroutines. For example
> > they're allowed to exit when they're only part finished, to be resumed
> > from where they broke off when the next coroutine call is made. That
> > allows a very natural and elegant programming solution to the kind of
> > interleaved multiple data hierarchies I've been describing.
> >
> > Another way of handling the same kind of data structuring problem
> > elegantly (but not quite as elegant as with coroutines) is by using
> > software interrupts which invoke the hardware interrupt mechanisms of
> > the computer by means of programmed software. In the early days of
> > computers not all computers had such a facility in the hardware of the
> > computer. These days (almost) all computers have it, but its use is
> > usually restricted to the systems programmers who program the
> > operating system.
> >
> > I brought in the idea of coroutines because folk were discussing
> > esoteric aspects of certain kinds of programming such as programming
> > in assembly language and hexadecimal. I just wondered if there were
> > any folk around who'd done enough serious complicated assembly
> > language coding to have heard of or even used coroutines.
> >
> > Seems not. Just wondered :-)

>
> I've used hexadecimal and done some assembly language programming,
> but that could have easily been before coroutines became known.
> I've never seen them mentioned before this thread. However, I
> have seen some multi-thread programs, not in assembler, that were
> written to have some parallel capability by being able to run on
> more than one core of a modern multi-core CPU at the same time.
> Perhaps a new name for the same thing?
>
> Robert Miles


--
Frank Slootweg,
"Australia, beautiful one day - perfect the next."
  #83 (permalink)   Report Post  
Posted to alt.food.diabetic,alt.support.diabetes
external usenet poster
 
Posts: 32
Default unplugging...

In alt.support.diabetes Robert Miles > wrote:
> On 9/25/2010 12:52 AM, Chris Malcolm wrote:
>> In alt.support.diabetes Ellen > wrote:
>>> "Chris > wrote in message
>>> ...
>>>> In alt.support.diabetes Ellen >
>>>> wrote:
>>>>> "Chris > wrote in message
>>>>> ...
>>>>>> In alt.support.diabetes Ellen >
>>>>>> wrote:
>>>>>>> "Chris > wrote in message
>>>>>>> ...


>> Coroutines differ in a number of ways from subroutines. For example
>> they're allowed to exit when they're only part finished, to be resumed
>> from where they broke off when the next coroutine call is made. That
>> allows a very natural and elegant programming solution to the kind of
>> interleaved multiple data hierarchies I've been describing.
>>
>> Another way of handling the same kind of data structuring problem
>> elegantly (but not quite as elegant as with coroutines) is by using
>> software interrupts which invoke the hardware interrupt mechanisms of
>> the computer by means of programmed software. In the early days of
>> computers not all computers had such a facility in the hardware of the
>> computer. These days (almost) all computers have it, but its use is
>> usually restricted to the systems programmers who program the
>> operating system.
>>
>> I brought in the idea of coroutines because folk were discussing
>> esoteric aspects of certain kinds of programming such as programming
>> in assembly language and hexadecimal. I just wondered if there were
>> any folk around who'd done enough serious complicated assembly
>> language coding to have heard of or even used coroutines.
>>
>> Seems not. Just wondered :-)


> I've used hexadecimal and done some assembly language programming,
> but that could have easily been before coroutines became known.
> I've never seen them mentioned before this thread. However, I
> have seen some multi-thread programs, not in assembler, that were
> written to have some parallel capability by being able to run on
> more than one core of a modern multi-core CPU at the same time.
> Perhaps a new name for the same thing?


No. See:

http://en.wikipedia.org/wiki/Coroutine

"Coroutines are computer program components that generalize
subroutines to allow multiple entry points for suspending and resuming
execution at certain locations. Coroutines are well-suited for
implementing more familiar program components such as cooperative
tasks, iterators, infinite lists and pipes.

"The term "coroutine" was originated by Melvin Conway in a 1963 paper."

[...]

"To implement a programming language with subroutines, only a single
stack that can be preallocated at the beginning of program execution
is needed. In contrast, coroutines, able to call on other coroutines
as peers, are best implemented using continuations.[citation needed]
Continuations may require allocation of additional stacks and
therefore are more commonly implemented in garbage-collected
high-level languages.[citation needed] Coroutine creation can be done
cheaply by preallocating stacks or caching previously allocated
stacks.[citation needed]"

The big difficulty with coroutines is that some computer hardware
instruction code sets made it a bit awkward to implement them,
e.g. upwards of half a dozen instructions rather than one or two, and
few programming languages reflected that basic native capability of
the instruction set hardware up into the programming language
capabilities.

It's a somewhat tricky concept which is rarely used, hence for
compiler writers under time and financial pressure it's probably the
first thing to be dumped from the original spec. If it was even in
the original spec. Because it's rarely used and not much known.
Despite being extremely useful, wonderfully elegant, and great fun :-)

So at levels above assembly language if they're used
they're often a rather unpleasant fudge.

I only used them once in my programming career. Re-organising a
complex buffering and batching problem in terms of coroutines made it
possible to produce a simple, elegant, easily understood, and easily
debugged, version of code which had previously been implemented in
terms of procedures. Which meant that a great deal of horrible
exception handling had to be patched into the coding of the primary
case around which the procedural structure had been built. Which was
so horrible that half a dozen programmers had each spent months or
heavy overtime trying to make it work, but instead had made it even
more complicated and difficult to debug.

I was the last of the programmers delegated to make the horrible thing
work. I came to realise that the problem was not only that the data
structure was not properly reflected in the code structure, but that
no purely procedural code structure could.

This was in the heyday of the theoretical programming controversies
over whether it was theoretically possible to code every possible kind
of programming problem without too much inelegant difficulty in a
language without the infamous structure-breaking "go to", the battle
between the high level language modernisers and the die-hard assembly
language enthusiasts.

So the fact that the theoretical answer was "yes" -- provided
coroutines were reflected into the higher level language tool-kit --
was a topical point of discussion among computer systems theoreticians
at the time. Which I wasn't, but I followed the debate with great
interest, which was how I learned about them.

--
Chris Malcolm
  #84 (permalink)   Report Post  
Posted to alt.food.diabetic,alt.support.diabetes
external usenet poster
 
Posts: 32
Default unplugging...

In alt.support.diabetes Ozlover > wrote:
> Robert Miles > wrote:
>> On 9/25/2010 12:52 AM, Chris Malcolm wrote:


> Why respond *now*? Couldn't you wait a *little* longer for the first
> anniversary!?


Another calendar slave boggles :-)

--
Chris Malcolm
Reply
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules

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



All times are GMT +1. The time now is 06:37 AM.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 FoodBanter.com.
The comments are property of their posters.
 

About Us

"It's about Food and drink"