Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: transactions vs interactive, was The Design of Design
Date: Fri, 31 May 2024 12:46:46 +0300
Organization: A noiseless patient Spider
Lines: 53
Message-ID: <20240531124646.00006236@yahoo.com>
References: <v03uh5$gbd5$1@dont-email.me>
	<86a5k7qpal.fsf@linuxsc.com>
	<v3abln$bd1$1@gal.iecc.com>
	<eE46O.1030$nd%8.650@fx45.iad>
	<v3b648$bt4$1@gal.iecc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 31 May 2024 11:46:53 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="319c9bbb49675ac68434cef6b0b3335d";
	logging-data="2273624"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/q9wdPyreAtzsYNwBvxbC4k+o7rcVTN0c="
Cancel-Lock: sha1:d1QDNxjYDduBPORhVj+3syOdU5I=
X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
Bytes: 3447

On Fri, 31 May 2024 00:37:28 -0000 (UTC)
John Levine <johnl@taugh.com> wrote:

> According to Scott Lurndal <slp53@pacbell.net>:
> >>Among the many differences between IBM and DEC computers was that
> >>IBM's had channels ...  
> 
> >Burroughs I/O subsystem offloaded even more than IBM channel
> >programs could provide.   It was fire and forget from the MCP
> >perspective (e.g. read a set of cards or read a bunch of sectors
> >was one instruction that initiated a high level operation (read
> >card/cards, print line/lines, read sector/sectors, write
> >sector/sectors, backspace tape, etc) and the hardware took care of
> >all the fiddley little details.  
> 
> I can believe that Burroughs I/O was more flexible but IBM 360
> channels could ran channel progarms that could be arbitrarily long and
> had loops. If you wanted to write a channel program to read a dozen
> cards or read all the records on a disk track, that wasn't hard. There
> were even some self-modifying channel programs that were a pain to
> virtualize on CP/67.
> 
> >Modern server-grade I/O hardware is more along the fire-and-forget
> >model than bit-twiddling models from the 8086 timeframe.   Even SATA
> >(which is more capable than IDE) is fairly high level, as is FC and
> >NVMe.  Server-grade NICs are also pretty capable and require
> >far fewer interrupts than early NICs to transfer a given amount
> >of data.  
> 
> Yup, now it's all channels all the time.
> 
> 
> 

I don't think so.
The processor and the rest of the hardware on server-grade NIC are more
like IBM PP than like IBM CP.
There were attempts to use CP-like functionality in non-mainframe
computers, sometimes with some level of initial success. Even early IBM
PCs had host-side DMA channels. But long term all such attempts
[outside of mainframes] failed. On the other hand, PP-like things are
successful. The distinctions between CP and PP are two:
1. Physical. Which side of I/O bus?
2. Responsibility. Who writes programs that run on this intelligent
processing element? OS and apps programmer (seen like the same in this
particular case) or device manufacturer? And on which level the whole
thing standardized? Internal instructions or bus transfers/packets?

I am not happy about 2nd part of my definition, but right now can't
formulate it better.