Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.folklore.computers > #210897 > unrolled thread
| Started by | Gareth Evans <headstone255@yahoo.com> |
|---|---|
| First post | 2020-04-12 11:59 +0100 |
| Last post | 2020-08-22 18:55 -0700 |
| Articles | 20 on this page of 169 — 32 participants |
Back to article view | Back to alt.folklore.computers
CR or LF? Gareth Evans <headstone255@yahoo.com> - 2020-04-12 11:59 +0100
Re: CR or LF? John Levine <johnl@taugh.com> - 2020-04-12 20:35 +0000
Re: CR or LF? J. Clarke <jclarke.873638@gmail.com> - 2020-04-12 16:52 -0400
Re: CR or LF? John Levine <johnl@taugh.com> - 2020-04-13 22:16 +0000
Re: CR or LF? Gareth Evans <headstone255@yahoo.com> - 2020-04-12 22:48 +0100
Re: CR or LF? Mike Spencer <mds@bogus.nodomain.nowhere> - 2020-04-12 19:44 -0300
Re: CR or LF? Douglas Miller <durgadas311@gmail.com> - 2020-04-12 16:38 -0700
Re: CR or LF? John Levine <johnl@taugh.com> - 2020-04-13 19:03 +0000
Re: CR or LF? Douglas Miller <durgadas311@gmail.com> - 2020-04-13 14:12 -0700
Re: CR or LF? John Levine <johnl@taugh.com> - 2020-04-13 22:30 +0000
Re: CR or LF? Douglas Miller <durgadas311@gmail.com> - 2020-04-13 16:00 -0700
Re: CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-04-13 21:22 +0000
Re: CR or LF? Thomas Koenig <tkoenig@netcologne.de> - 2020-04-14 09:40 +0000
Re: CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-04-13 17:56 -0700
Re: CR or LF? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-04-13 03:32 +0000
Re: CR or LF? "Carlos E.R." <robin_listas@es.invalid> - 2020-04-14 05:26 +0200
Re: CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-04-12 22:11 -0700
Re: CR or LF? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-04-13 17:15 +0000
Re: CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-04-13 16:40 -0700
Re: CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-04-13 17:29 -0700
Re: CR or LF? Douglas Miller <durgadas311@gmail.com> - 2020-04-13 18:18 -0700
Re: CR or LF? Niklas Karlsson <anksil@yahoo.se> - 2020-04-16 13:40 +0000
Re: CR or LF? maus <maus@dmaus.org> - 2020-04-17 11:00 +0000
Re: CR or LF? Niklas Karlsson <anksil@yahoo.se> - 2020-04-18 09:56 +0000
Re: CR or LF? J. Clarke <jclarke.873638@gmail.com> - 2020-04-13 21:37 -0400
Re: CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-04-14 14:51 -0700
Re: CR or LF? Bob Eager <news0073@eager.cx> - 2020-04-14 07:45 +0000
Re: CR or LF? Gareth Evans <headstone255@yahoo.com> - 2020-04-14 11:38 +0100
Re: CR or LF? "Carlos E.R." <robin_listas@es.invalid> - 2020-04-14 15:28 +0200
Re: CR or LF? nobody@example.org (Scott) - 2020-04-14 15:27 +0000
Re: CR or LF? Gareth Evans <headstone255@yahoo.com> - 2020-04-14 17:37 +0100
Re: CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-04-14 15:00 -0700
Re: CR or LF? fred_weigel@hotmail.com - 2020-05-22 17:09 -0700
Re: CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-05-23 03:37 -0700
Re: CR or LF? J. Clarke <jclarke.873638@gmail.com> - 2020-05-23 08:36 -0400
Re: CR or LF? robin.vowels@gmail.com - 2020-05-23 05:38 -0700
Re: CR or LF? Dan Espen <dan1espen@gmail.com> - 2020-05-23 08:58 -0400
Re: base64, not really CR or LF? John Levine <johnl@taugh.com> - 2020-05-23 18:42 +0000
Re: CR or LF? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-05-23 19:28 +0000
Re: CR or LF? Bob Eager <news0073@eager.cx> - 2020-05-23 20:27 +0000
Re: CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-05-23 14:30 -0700
Re: CR or LF? "Kerr-Mudd,John" <notsaying@invalid.org> - 2020-05-24 10:21 +0000
Re: CR or LF? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-05-24 06:06 +0000
Re: CR or LF? Bob Eager <news0073@eager.cx> - 2020-05-24 10:45 +0000
Re: CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-05-24 07:03 -0700
Re: CR or LF? J. Clarke <jclarke.873638@gmail.com> - 2020-05-24 10:43 -0400
Re: CR or LF? Jan van den Broek <fortytwo@xs4all.nl> - 2020-06-05 22:22 +0100
Re: CR or LF? Mike Spencer <mds@bogus.nodomain.nowhere> - 2020-04-14 17:49 -0300
Re: CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-04-14 06:29 -0700
Re: CR or LF? Ahem A Rivet's Shot <steveo@eircom.net> - 2020-04-18 08:42 +0100
Re: CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-04-18 11:33 -0700
Re: CR or LF? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-04-18 19:11 +0000
Re: CR or LF? Dan Espen <dan1espen@gmail.com> - 2020-04-18 18:32 -0400
Re: CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-04-19 01:55 +0000
Re: CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-04-18 20:03 +0000
Re: CR or LF? Ahem A Rivet's Shot <steveo@eircom.net> - 2020-04-18 22:44 +0100
Re: CR or LF? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-04-19 08:46 +0000
Re: CR or LF? Ahem A Rivet's Shot <steveo@eircom.net> - 2020-04-19 10:58 +0100
Re: CR or LF? John Levine <johnl@taugh.com> - 2020-04-18 22:22 +0000
Re: CR or LF? J. Clarke <jclarke.873638@gmail.com> - 2020-04-18 18:55 -0400
re: CRLF Peter Flass <peter_flass@yahoo.com> - 2020-04-18 18:03 -0700
Re: CR or LF? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-04-19 08:55 +0000
Re: CR or LF? J. Clarke <jclarke.873638@gmail.com> - 2020-04-19 08:16 -0400
Re: CR or LF? Dan Espen <dan1espen@gmail.com> - 2020-04-19 09:19 -0400
Re: CR or LF? J. Clarke <jclarke.873638@gmail.com> - 2020-04-19 10:24 -0400
Re: CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-04-19 10:47 -0700
Re: CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-04-20 16:02 +0000
Re: CR or LF? Jan van den Broek <fortytwo@xs4all.nl> - 2020-05-05 16:32 +0100
Re: CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-04-19 14:54 +0000
Re: CR or LF? Dan Espen <dan1espen@gmail.com> - 2020-04-19 12:19 -0400
Re: CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-04-19 10:47 -0700
Re: CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-04-19 09:26 -0700
Re: CR or LF? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2020-04-20 17:40 +0800
Re: CR or LF? Fred Smith <fred@thejanitor.corp> - 2020-04-20 23:05 +0000
Re: CR or LF? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-04-21 06:07 +0000
Re: CR or LF? Rich Alderson <news@alderson.users.panix.com> - 2020-04-22 15:08 -0400
Re: CR or LF? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-04-22 20:22 +0000
Re: CR or LF? Dan Espen <dan1espen@gmail.com> - 2020-04-22 19:40 -0400
Re: CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-04-22 23:23 -0700
Re: CR or LF? robin.vowels@gmail.com - 2020-04-23 03:01 -0700
Re: CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-04-19 10:47 -0700
Re: CR or LF? Ahem A Rivet's Shot <steveo@eircom.net> - 2020-04-13 19:54 +0100
Re: CR or LF? hancock4@bbs.cpcn.com - 2020-08-22 11:18 -0700
Re: CR or LF? "Carlos E.R." <robin_listas@es.invalid> - 2020-04-14 05:24 +0200
Re: CR or LF? Ahem A Rivet's Shot <steveo@eircom.net> - 2020-04-18 08:44 +0100
Re: CR or LF? "Carlos E.R." <robin_listas@es.invalid> - 2020-04-18 12:08 +0200
Re: CR or LF? Ahem A Rivet's Shot <steveo@eircom.net> - 2020-04-18 12:02 +0100
Re: CR or LF? "Carlos E.R." <robin_listas@es.invalid> - 2020-04-18 21:50 +0200
Re: CR or LF? usenet@only.tnx (Questor) - 2020-04-18 03:40 +0000
Re: CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-05-23 03:40 -0700
Re: CR or LF? J. Clarke <jclarke.873638@gmail.com> - 2020-05-23 08:38 -0400
Re: CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-05-23 08:02 -0700
Re: CR or LF? J. Clarke <jclarke.873638@gmail.com> - 2020-05-23 11:07 -0400
Re: CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-05-23 11:27 -0700
Re: CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-05-23 12:27 -0700
Re: CR or LF? J. Clarke <jclarke.873638@gmail.com> - 2020-05-23 18:21 -0400
Re: CR or LF? John Levine <johnl@taugh.com> - 2020-05-23 20:10 +0000
Re: CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-05-24 08:32 -0700
Re: CR or LF? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-05-24 16:25 +0000
Re: CR or LF? John Levine <johnl@taugh.com> - 2020-05-24 18:29 +0000
Re: CR or LF? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-05-25 02:00 +0000
Re: CR or LF? John Levine <johnl@taugh.com> - 2020-05-25 16:28 +0000
Re: CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-05-26 14:06 +0000
Re: CR or LF? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-05-26 15:14 +0000
Re: CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-05-25 10:55 -0700
Re: CR or LF? Dan Espen <dan1espen@gmail.com> - 2020-05-25 15:04 -0400
Re: CR or LF? robin.vowels@gmail.com - 2020-05-24 21:32 -0700
Re: CR or LF? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-05-25 15:44 +0000
Re: mainframe I/O, was CR or LF? John Levine <johnl@taugh.com> - 2020-05-25 16:32 +0000
Re: mainframe I/O, was CR or LF? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-05-26 00:39 +0000
Re: mainframe I/O, was CR or LF? antispam@math.uni.wroc.pl - 2020-05-31 00:21 +0000
Re: mainframe I/O, was CR or LF? J. Clarke <jclarke.873638@gmail.com> - 2020-05-30 21:59 -0400
Re: mainframe I/O, was CR or LF? David Wade <g4ugm@dave.invalid> - 2020-05-31 09:30 +0100
Re: mainframe I/O, was CR or LF? antispam@math.uni.wroc.pl - 2020-05-31 15:48 +0000
Re: mainframe I/O, was CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-05-31 13:49 -0700
Re: mainframe I/O, was CR or LF? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-06-01 16:28 +0000
Re: mainframe I/O, was CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-06-01 18:48 +0000
Re: mainframe I/O, was CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-06-01 16:27 +0000
Re: mainframe I/O, was CR or LF? usenet@only.tnx (Questor) - 2020-06-02 19:12 +0000
Re: mainframe I/O, was CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-06-02 20:28 +0000
Re: mainframe I/O, was CR or LF? David Wade <g4ugm@dave.invalid> - 2020-06-03 09:13 +0100
Re: mainframe I/O, was CR or LF? Fred Smith <fred@thejanitor.corp> - 2020-06-03 08:33 +0000
Re: mainframe I/O, was CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-06-03 16:20 +0000
Re: mainframe I/O, was CR or LF? usenet@only.tnx (Questor) - 2020-06-03 18:25 +0000
Re: mainframe I/O, was CR or LF? Rich Alderson <news@alderson.users.panix.com> - 2020-06-03 17:20 -0400
Re: mainframe I/O, was CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-06-04 15:20 +0000
Re: mainframe I/O, was CR or LF? John Levine <johnl@taugh.com> - 2020-06-04 19:51 +0000
Re: mainframe I/O, was CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-06-04 16:26 -0700
Re: mainframe I/O, was CR or LF? usenet@only.tnx (Questor) - 2020-06-05 18:46 +0000
Re: mainframe I/O, was CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-06-05 12:26 -0700
Re: mainframe I/O, was CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-06-05 13:28 -0700
Re: mainframe I/O, was CR or LF? David Lesher <wb8foz@panix.com> - 2020-06-08 01:03 +0000
Re: PDP-11s, was mainframe I/O, was CR or LF? John Levine <johnl@taugh.com> - 2020-06-06 00:08 +0000
Re: mainframe I/O, was CR or LF? usenet@only.tnx (Questor) - 2020-06-04 17:41 +0000
Re: mainframe I/O, was CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-06-04 16:26 -0700
Re: mainframe I/O, was CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-06-04 17:04 -0700
Re: mainframe I/O, was CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-06-04 15:18 +0000
Re: memory sizes, mainframe I/O, was CR or LF? John Levine <johnl@taugh.com> - 2020-06-04 20:53 +0000
Re: memory sizes, mainframe I/O, was CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-06-04 22:22 +0000
Re: memory sizes, mainframe I/O, was CR or LF? Dan Espen <dan1espen@gmail.com> - 2020-06-04 19:27 -0400
Re: memory sizes, mainframe I/O, was CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-06-05 16:10 +0000
Re: memory sizes, mainframe I/O, was CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-06-05 10:03 -0700
Re: memory sizes, mainframe I/O, was CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-06-05 20:29 +0000
Re: memory sizes, mainframe I/O, was CR or LF? usenet@only.tnx (Questor) - 2020-06-05 18:47 +0000
Re: mainframe I/O, was CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-06-04 16:26 -0700
Re: mainframe I/O, was CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-06-01 16:32 +0000
Re: CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-05-25 10:55 -0700
Re: CR or LF? Anne & Lynn Wheeler <lynn@garlic.com> - 2020-05-25 15:04 -1000
Re: CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-05-26 12:56 -0700
Re: CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-05-26 14:15 -0700
Re: CR or LF? robin.vowels@gmail.com - 2020-05-25 21:41 -0700
Re: CR or LF? Thomas Koenig <tkoenig@netcologne.de> - 2020-05-28 11:50 +0000
Re: CR or LF? Bob Eager <news0073@eager.cx> - 2020-05-28 11:56 +0000
Re: CR or LF? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-05-30 14:49 +0000
Re: CR or LF? John Levine <johnl@taugh.com> - 2020-05-30 17:39 +0000
Re: CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-05-30 19:07 +0000
Re: CR or LF? John Levine <johnl@taugh.com> - 2020-05-30 19:32 +0000
Re: CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-05-30 13:10 -0700
Re: CR or LF? John Levine <johnl@taugh.com> - 2020-05-30 20:43 +0000
Re: CR or LF? Dan Espen <dan1espen@gmail.com> - 2020-05-30 15:50 -0400
Re: CR or LF? J. Clarke <jclarke.873638@gmail.com> - 2020-05-30 16:30 -0400
Re: CR or LF? Dan Espen <dan1espen@gmail.com> - 2020-05-30 19:42 -0400
Re: CR or LF? J. Clarke <jclarke.873638@gmail.com> - 2020-05-30 22:17 -0400
Re: CR or LF? Ahem A Rivet's Shot <steveo@eircom.net> - 2020-05-31 09:45 +0100
Re: CR or LF? usenet@only.tnx (Questor) - 2020-05-25 18:37 +0000
Re: CR or LF? Bob Eager <news0073@eager.cx> - 2020-05-25 19:52 +0000
Re: CR or LF? usenet@only.tnx (Questor) - 2020-05-25 07:37 +0000
Re: CR or LF? hancock4@bbs.cpcn.com - 2020-08-22 11:15 -0700
Re: CR or LF? Robin Vowels <robin.vowels@gmail.com> - 2020-08-22 18:55 -0700
Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2020-06-05 16:10 +0000 |
| Subject | Re: memory sizes, mainframe I/O, was CR or LF? |
| Message-ID | <88uCG.561376$Xk.532800@fx46.iad> |
| In reply to | #211765 |
Dan Espen <dan1espen@gmail.com> writes: >scott@slp53.sl.home (Scott Lurndal) writes: > >> John Levine <johnl@taugh.com> writes: >>>In article <1h8CG.525299$TM6.280020@fx42.iad>, >>>Scott Lurndal <slp53@pacbell.net> wrote: >>>>>I think making the page size only 512 bytes was a big mistake and wasn't forward >>>>>looking, given the trends of increasingly larger and increasingly less expensive >>>>>memory. >>>> >>>>Although in the late 70's, I'm not sure how evident that trend was... >>> >>>4K DRAM chips appeared in 1973, 16K DRAM chips in 1974, and chip >>>densities were doubling every year or two. >>> >>>IBM's S/370 in the early 1970s had both 2K and 4K pages. The 512 byte >>>VAX pages were obviously too small at the time. >> >> I wonder if they wanted the size of the page to match the basic >> disk sector size; perhaps to avoid checkerboarding when managing >> the working set (another, hmmm, interesting VMS feature). > >Makes sense. > >By going down to 512 they drastically increase the odds that they can >page things out that they never have to page in again. > >When I worked on S/360 I always wondered how many 4K pages I had where I >only really accessed one byte with any frequency. > >The OS has to keep some kind of map, each real page is mapped to some >address space/real address. It's been too long since I read POPs on >this but assuming each 512 virtual bytes needs 2 addresses to track it, >that's only an overhead of 8 bytes for every 512 virtual bytes. Page tables are interesting beasts. Generally there are slightly more than four bytes per page (in a 32-bit architecture, eight bytes in 64-bit) of page table overhead (most page tables are tree structures three or four levels deep - some support final entries at higher levels in the tree which provides larger page sizes (e.g. intel x86-64 supports 4k, 2M and 1G pages, ARM64 has three basic 'granule' sizes, 4k, 16k and 64k, and by terminating the lookup at higher levels, supports two or three larger block sizes per each of the granule sizes). Then you have the hardware virtualization solutions, where the page tables are nested (the guest page table physical addresses are in turn translated by another set of hypervisor page tables into real physical addresses). For performance, you need a bunch of TLBs, since a single table walk in the nested case, where both levels used 4k pages, requires 23 memory accesses; can be reduced to 11 using 1GB pages on the hypervisor side.
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2020-06-05 10:03 -0700 |
| Subject | Re: memory sizes, mainframe I/O, was CR or LF? |
| Message-ID | <1319586643.613069250.828750.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #211773 |
Scott Lurndal <scott@slp53.sl.home> wrote: > Dan Espen <dan1espen@gmail.com> writes: >> scott@slp53.sl.home (Scott Lurndal) writes: >> >>> John Levine <johnl@taugh.com> writes: >>>> In article <1h8CG.525299$TM6.280020@fx42.iad>, >>>> Scott Lurndal <slp53@pacbell.net> wrote: >>>>>> I think making the page size only 512 bytes was a big mistake and wasn't forward >>>>>> looking, given the trends of increasingly larger and increasingly less expensive >>>>>> memory. >>>>> >>>>> Although in the late 70's, I'm not sure how evident that trend was... >>>> >>>> 4K DRAM chips appeared in 1973, 16K DRAM chips in 1974, and chip >>>> densities were doubling every year or two. >>>> >>>> IBM's S/370 in the early 1970s had both 2K and 4K pages. The 512 byte >>>> VAX pages were obviously too small at the time. >>> >>> I wonder if they wanted the size of the page to match the basic >>> disk sector size; perhaps to avoid checkerboarding when managing >>> the working set (another, hmmm, interesting VMS feature). >> >> Makes sense. >> >> By going down to 512 they drastically increase the odds that they can >> page things out that they never have to page in again. >> >> When I worked on S/360 I always wondered how many 4K pages I had where I >> only really accessed one byte with any frequency. >> >> The OS has to keep some kind of map, each real page is mapped to some >> address space/real address. It's been too long since I read POPs on >> this but assuming each 512 virtual bytes needs 2 addresses to track it, >> that's only an overhead of 8 bytes for every 512 virtual bytes. > > Page tables are interesting beasts. Generally there are slightly more > than four bytes per page (in a 32-bit architecture, eight bytes in 64-bit) > of page table overhead (most page tables are tree structures three or four > levels deep - some support final entries at higher levels in the tree > which provides larger page sizes (e.g. intel x86-64 supports 4k, 2M and 1G > pages, ARM64 has three basic 'granule' sizes, 4k, 16k and 64k, and by > terminating the lookup at higher levels, supports two or three larger block > sizes per each of the granule sizes). > > Then you have the hardware virtualization solutions, where the page tables > are nested (the guest page table physical addresses are in turn translated > by another set of hypervisor page tables into real physical addresses). For > performance, you need a bunch of TLBs, since a single table walk in the > nested case, where both levels used 4k pages, requires 23 memory accesses; > can be reduced to 11 using 1GB pages on the hypervisor side. > VM/370 has handshaking, I guess it’s called paravirtualization, where the guest hands off all paging to the hypervisor, eliminating half the overhead. I don’t know what x86 hypervisors do. -- Pete
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2020-06-05 20:29 +0000 |
| Subject | Re: memory sizes, mainframe I/O, was CR or LF? |
| Message-ID | <NWxCG.166000$VX.114767@fx34.iad> |
| In reply to | #211780 |
Peter Flass <peter_flass@yahoo.com> writes: >Scott Lurndal <scott@slp53.sl.home> wrote: >> Dan Espen <dan1espen@gmail.com> writes: >>> scott@slp53.sl.home (Scott Lurndal) writes: >>> >>>> John Levine <johnl@taugh.com> writes: >>>>> In article <1h8CG.525299$TM6.280020@fx42.iad>, >>>>> Scott Lurndal <slp53@pacbell.net> wrote: >>>>>>> I think making the page size only 512 bytes was a big mistake and wasn't forward >>>>>>> looking, given the trends of increasingly larger and increasingly less expensive >>>>>>> memory. >>>>>> >>>>>> Although in the late 70's, I'm not sure how evident that trend was... >>>>> >>>>> 4K DRAM chips appeared in 1973, 16K DRAM chips in 1974, and chip >>>>> densities were doubling every year or two. >>>>> >>>>> IBM's S/370 in the early 1970s had both 2K and 4K pages. The 512 byte >>>>> VAX pages were obviously too small at the time. >>>> >>>> I wonder if they wanted the size of the page to match the basic >>>> disk sector size; perhaps to avoid checkerboarding when managing >>>> the working set (another, hmmm, interesting VMS feature). >>> >>> Makes sense. >>> >>> By going down to 512 they drastically increase the odds that they can >>> page things out that they never have to page in again. >>> >>> When I worked on S/360 I always wondered how many 4K pages I had where I >>> only really accessed one byte with any frequency. >>> >>> The OS has to keep some kind of map, each real page is mapped to some >>> address space/real address. It's been too long since I read POPs on >>> this but assuming each 512 virtual bytes needs 2 addresses to track it, >>> that's only an overhead of 8 bytes for every 512 virtual bytes. >> >> Page tables are interesting beasts. Generally there are slightly more >> than four bytes per page (in a 32-bit architecture, eight bytes in 64-bit) >> of page table overhead (most page tables are tree structures three or four >> levels deep - some support final entries at higher levels in the tree >> which provides larger page sizes (e.g. intel x86-64 supports 4k, 2M and 1G >> pages, ARM64 has three basic 'granule' sizes, 4k, 16k and 64k, and by >> terminating the lookup at higher levels, supports two or three larger block >> sizes per each of the granule sizes). >> >> Then you have the hardware virtualization solutions, where the page tables >> are nested (the guest page table physical addresses are in turn translated >> by another set of hypervisor page tables into real physical addresses). For >> performance, you need a bunch of TLBs, since a single table walk in the >> nested case, where both levels used 4k pages, requires 23 memory accesses; >> can be reduced to 11 using 1GB pages on the hypervisor side. >> > >VM/370 has handshaking, I guess it’s called paravirtualization, where the >guest hands off all paging to the hypervisor, eliminating half the >overhead. I don’t know what x86 hypervisors do. Paravirtualization is what x86/amd hypervisors did, prior to 2012 when AMD added nested paging hardware support. Paravirt page tables are horribly inefficient by comparison to hardware solutions.
[toc] | [prev] | [next] | [standalone]
| From | usenet@only.tnx (Questor) |
|---|---|
| Date | 2020-06-05 18:47 +0000 |
| Subject | Re: memory sizes, mainframe I/O, was CR or LF? |
| Message-ID | <5eda9324.4694550@news.dslextreme.com> |
| In reply to | #211761 |
On Thu, 04 Jun 2020 22:22:02 GMT, scott@slp53.sl.home (Scott Lurndal) wrote: >John Levine <johnl@taugh.com> writes: >>In article <1h8CG.525299$TM6.280020@fx42.iad>, >>Scott Lurndal <slp53@pacbell.net> wrote: >>>>I think making the page size only 512 bytes was a big mistake and wasn't forward >>>>looking, given the trends of increasingly larger and increasingly less expensive >>>>memory. >>> >>>Although in the late 70's, I'm not sure how evident that trend was... >> >>4K DRAM chips appeared in 1973, 16K DRAM chips in 1974, and chip >>densities were doubling every year or two. >> >>IBM's S/370 in the early 1970s had both 2K and 4K pages. The 512 byte >>VAX pages were obviously too small at the time. > >I wonder if they wanted the size of the page to match the basic >disk sector size; perhaps to avoid checkerboarding when managing >the working set (another, hmmm, interesting VMS feature). working set pre-loading = no fault insurance
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2020-06-04 16:26 -0700 |
| Subject | Re: mainframe I/O, was CR or LF? |
| Message-ID | <428133481.613005465.120498.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #211752 |
Scott Lurndal <scott@slp53.sl.home> wrote: > usenet@only.tnx (Questor) writes: >> On Tue, 02 Jun 2020 20:28:45 GMT, scott@slp53.sl.home (Scott Lurndal) wrote: >>> usenet@only.tnx (Questor) writes: >>>> On Sun, 31 May 2020 09:30:37 +0100, David Wade <g4ugm@dave.invalid> wrote: > >>>> I strongly suspect it had a "line mode" input model >>>> similar to the PDP-10 that was used by most programs. I very much doubt that >>>> the processor was interrupted on every character typed by every user. I could >>>> be wrong though; VMS certainly made some other big mistakes. >>> >>> Do you have any examples to share? >> >> In old age first thing to go is memory. >> >> I forget what the second thing is. >> >> >> I have to offer the following caveats. I don't remember a lot of the details. >> One person's feature is another one's mistake. The time period would be the >> mid-1980s. >> >> I think making the page size only 512 bytes was a big mistake and wasn't forward >> looking, given the trends of increasingly larger and increasingly less expensive >> memory. > > Although in the late 70's, I'm not sure how evident that trend was... Multics used 1K (word) pages, IIRC. VM used 2KB initially and later 4KB. VMS came from too much of a minicomputer background. Of course they could have, and maybe did, made up for this by handling physical pages only in groups of four or eight. > >> >> VMS lacked some useful queue options that the TOPS-10/20 systems had. (For the >> uninitiated, the queueing system is how one submitted and controlled print >> requests, card or paper tape punching, and batch jobs, a form of automated >> script processing.) > > One of my first tasks after being hired was to develop a print symbiont > for remote printers that included accounting (rpsacc - remote printing > accounting); the mainframe folks had been billing various departments > for lines printed, cards read, cpu seconds, memory seconds, tape I/O, > disk I/O, etc. VMS didn't at the time have any accounting provisions > for printed output (and remote printing was not well supported in VMS 2.x), > so they tasked me to write a print symbiont for that. The print symbiont > was written in Macro-32, RPSACC in Vax PASCAL. > -- Pete
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2020-06-01 16:32 +0000 |
| Subject | Re: mainframe I/O, was CR or LF? |
| Message-ID | <W4aBG.195905$AE7.3602@fx41.iad> |
| In reply to | #211667 |
antispam@math.uni.wroc.pl writes: >John Levine <johnl@taugh.com> wrote: >> >> I suppose that hypothetically someone could have built a TTY channel >> interface that interrupted on every character but I would be surprised >> if anyone did. More likely they'd sell you an 1130 or later a Sys/7 to >> be an overpriced front end processor. > >Around 1992 I was using Internet connection (email) that did it. >Connection was from a PC via modem to IBM mainframe. AFAIU doing >it "proper" way would be complicated/expensive, do guys operating >mainframe hacked hardware to take interrupt on each incoming >character. They said that "IBM does not like interrupts", but >this was for single 9600 bps line, so mainframe could handle >interrupts without serious degradation of response. > >Doing this on multiple lines probably would overload mainframe >with interrput processing. This mainframe probably had about 20 >discs and 100 block mode terminals and my guesstimate is that >the single character mode line generated comparable number >of interrupts to all other periferials taken together... The burroughs medium systems had real-time interrupts. they were used to handle the check sorters, where you needed to fully handle the interrupt while the document (at 2500DPM) was in transit between the MICR read station and the pocket-select station (if it took too long to process, the item would be placed in the too-late-to-pocket-select slot and would need to be resorted, which made the customer unhappy). The B4900 could handle 10 sorters at full speed while processing batch workloads. A few years later, the pocket-select criteria was "offloaded" to the sorter and the real-time interrupts were no longer required. I/O on the burroughs systems was far more efficient than on IBM; no channel programs, no separate disk seek ops, no CPU interactions; the CPU fired off a 8 digit I/O descriptor and the I/O hardware handled everything else.
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2020-05-25 10:55 -0700 |
| Message-ID | <1331759369.612121933.574417.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #211584 |
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> On 2020-05-25, robin.vowels@gmail.com <robin.vowels@gmail.com> wrote:
>
>> On Monday, May 25, 2020 at 4:29:04 AM UTC+10, John Levine wrote:
>>
>>> In article <r......@news2.newsguy.com>,
>>> Charlie Gibbs <c......@kltpzyxm.invalid> wrote:
>>>
>>>> On 2020-05-24, Quadibloc <j......@ecn.ab.ca> wrote:
>>>>
>>>>> And what I'm used to is the Michigan Terminal System.
>>>>>
>>>>> Text files are normally line files.
>>>>>
>>>>> The format of a line file is:
>>>>>
>>>>> An ISAM file with two fields.
>>>
>>> Yeah, TSS VISAM files were sort of like that, too.
>>>
>>>> It's a matter of parallel evolution. File systems like your MTS example
>>>> ("Bright college days, oh, carefree days that fly..." -- Tom Lehrer)
>>>> were born on mainframe systems that had lots of buffering capability and
>>>> processing power. ASCII text files were born on Teletype networks which
>>>> had very little processing capability and even less buffering. Given the
>>>> constraints of the time, I'd say that each system served its purposes well.
>>>> ASCII text files are so much simpler that their limitations are often not
>>>> a serious factor - e.g., when transmitting text.
>>>
>>> Quite right. IBM mainframes have I/O channels that can only do block
>>> I/O.
>>
>> Didn't they also have a multiplexor unit that handled byte
>> devices such as teletypes?
>
> Multiplexor channels handled all sorts of low-speed record-oriented
> peripherals as well, e.g. card readers, line printers, and slower
> tape drives. However, when handling character-mode terminals, they
> imposed as much overhead per byte as they would for an entire block
> of data on those other peripherals - at least if you wanted the
> flexibility of responding to each byte as the user typed it.
>
There were channel attached third-party boxes, like the Hydra, that let
dumb CRT’s, possibly dial-up, emulate 3270s to the mainframe. Later IBM
came out with their own (forget the model number).
--
Pete
[toc] | [prev] | [next] | [standalone]
| From | Anne & Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2020-05-25 15:04 -1000 |
| Message-ID | <875zcj4ibq.fsf@localhost> |
| In reply to | #211584 |
Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes: > Multiplexor channels handled all sorts of low-speed record-oriented > peripherals as well, e.g. card readers, line printers, and slower > tape drives. However, when handling character-mode terminals, they > imposed as much overhead per byte as they would for an entire block > of data on those other peripherals - at least if you wanted the > flexibility of responding to each byte as the user typed it. 270x controllers handled terminals ... they had different type of terminal/port scanner for handling different kinds of terminals. The scanner buffered chars and only presented interrupt on specific signals (not each character) when cp67/cms was installed at the univ (last week Jan1968), it had automagic terminal type identification for 2741 and 1052 terminals and would use the controller "SAD" ccw to switch the type of scanner ... trying operations until it got the scanner that worked for that terminal type. the univ. had some number of ASCII TTY 33&35 terminals ... and so added ascii support ... extending the automagic logic of switching type of scanner until got the one for the type of terminal. I wanted to have a single dial-up number for all terminals (single "hunt group") ... which almost worked ... except that while IBM allowed the type of line scanner to be switched for each port ... the line speed was hardwired ... aka 2471 & 1052 were same line-speed ... so could share a common "hunt group" ... but TTY had slower line-speed and would only reliably work on ports that had been wired for that speed. That was part of motivation for the univ. clone controller project, build channel interface board for Interdata/3, programmed to simulate IBM terminal controller ... with the addition that line-speed was (internally) software controlled and could change speed for each line/port. Two early "bugs" ... 1) this was 360/67 with "high" resolution timer that updated storage on each tic. When the interface acquired the memory bus for data transfer ... if it held it for too long, the timer storage update would redlight and stop the machine. 2) turns out standard ibm terminal controller convention reversed the bit order in each byte ... leading bit went into low-order bit position (instead of high position). We had overlooked that detail until we were trying to figure out why data in memory was all garbage. Later this was enhanced to Interdata/4 handling the IBM channel interface and a cluster of Interdata/3s to handle the line/port interfaces. Interdata (and later Perkin/Elmer) sells the boxes as clone controllers and four of us got written up for (some part of) IBM clone controller business. In 80s, supporting UNIX on mainframe, IBM provided a Series/1 front end terminal controller, programmed to handle wider range of ascii character interrupting (and full-duplex) options -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2020-05-26 12:56 -0700 |
| Message-ID | <2069360081.612215579.698520.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #211605 |
Anne & Lynn Wheeler <lynn@garlic.com> wrote: > Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes: >> Multiplexor channels handled all sorts of low-speed record-oriented >> peripherals as well, e.g. card readers, line printers, and slower >> tape drives. However, when handling character-mode terminals, they >> imposed as much overhead per byte as they would for an entire block >> of data on those other peripherals - at least if you wanted the >> flexibility of responding to each byte as the user typed it. > > 270x controllers handled terminals ... they had different type of > terminal/port scanner for handling different kinds of terminals. > The scanner buffered chars and only presented interrupt on specific > signals (not each character) > > when cp67/cms was installed at the univ (last week Jan1968), it had > automagic terminal type identification for 2741 and 1052 terminals and > would use the controller "SAD" ccw to switch the type of scanner > ... trying operations until it got the scanner that worked for that > terminal type. > > the univ. had some number of ASCII TTY 33&35 terminals ... and so added > ascii support ... extending the automagic logic of switching type of > scanner until got the one for the type of terminal. > > I wanted to have a single dial-up number for all terminals (single "hunt > group") ... which almost worked ... except that while IBM allowed the > type of line scanner to be switched for each port ... the line speed was > hardwired ... aka 2471 & 1052 were same line-speed ... so could share a > common "hunt group" ... but TTY had slower line-speed and would only > reliably work on ports that had been wired for that speed. > > That was part of motivation for the univ. clone controller project, > build channel interface board for Interdata/3, programmed to simulate > IBM terminal controller ... with the addition that line-speed was > (internally) software controlled and could change speed for each > line/port. > > Two early "bugs" ... 1) this was 360/67 with "high" resolution timer > that updated storage on each tic. When the interface acquired the memory > bus for data transfer ... if it held it for too long, the timer storage > update would redlight and stop the machine. 2) turns out standard ibm > terminal controller convention reversed the bit order in each byte > ... leading bit went into low-order bit position (instead of high > position). We had overlooked that detail until we were trying to figure > out why data in memory was all garbage. That drove me crazy for a while, too.It took me a while to un-learn it later. > > Later this was enhanced to Interdata/4 handling the IBM channel > interface and a cluster of Interdata/3s to handle the line/port > interfaces. Interdata (and later Perkin/Elmer) sells the boxes as clone > controllers and four of us got written up for (some part of) IBM clone > controller business. > > In 80s, supporting UNIX on mainframe, IBM provided a Series/1 front end > terminal controller, programmed to handle wider range of ascii character > interrupting (and full-duplex) options > -- Pete
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2020-05-26 14:15 -0700 |
| Message-ID | <229465c6-4ea3-4306-8fb3-9c456151aa8b@googlegroups.com> |
| In reply to | #211617 |
On Tuesday, May 26, 2020 at 1:56:24 PM UTC-6, Peter Flass wrote: > Anne & Lynn Wheeler <lynn@garlic.com> wrote: > > 2) turns out standard ibm > > terminal controller convention reversed the bit order in each byte > > ... leading bit went into low-order bit position (instead of high > > position). We had overlooked that detail until we were trying to figure > > out why data in memory was all garbage. > That drove me crazy for a while, too.It took me a while to un-learn it > later. I know that if you put a PTTC/EBCD element on a 2741, that terminal sends data high-order bit first, the reverse of what an ASCII terminal does. That could be the reason for that... John Savard
[toc] | [prev] | [next] | [standalone]
| From | robin.vowels@gmail.com |
|---|---|
| Date | 2020-05-25 21:41 -0700 |
| Message-ID | <3a20bf50-9e91-402f-8d72-82c1cbb94abd@googlegroups.com> |
| In reply to | #211584 |
On Tuesday, May 26, 2020 at 1:45:08 AM UTC+10, Charlie Gibbs wrote:
> On 2020-05-25, r.....@gmail.com <r.....@gmail.com> wrote:
>
> > On Monday, May 25, 2020 at 4:29:04 AM UTC+10, John Levine wrote:
> >
> >> In article <r......@news2.newsguy.com>,
> >> Charlie Gibbs <c......@kltpzyxm.invalid> wrote:
> >>
> >>> On 2020-05-24, Quadibloc <j......@ecn.ab.ca> wrote:
> >>>
> >>>> And what I'm used to is the Michigan Terminal System.
> >>>>
> >>>> Text files are normally line files.
> >>>>
> >>>> The format of a line file is:
> >>>>
> >>>> An ISAM file with two fields.
> >>
> >> Yeah, TSS VISAM files were sort of like that, too.
> >>
> >>> It's a matter of parallel evolution. File systems like your MTS example
> >>> ("Bright college days, oh, carefree days that fly..." -- Tom Lehrer)
> >>> were born on mainframe systems that had lots of buffering capability and
> >>> processing power. ASCII text files were born on Teletype networks which
> >>> had very little processing capability and even less buffering. Given the
> >>> constraints of the time, I'd say that each system served its purposes well.
> >>> ASCII text files are so much simpler that their limitations are often not
> >>> a serious factor - e.g., when transmitting text.
> >>
> >> Quite right. IBM mainframes have I/O channels that can only do block
> >> I/O.
> >
> > Didn't they also have a multiplexor unit that handled byte
> > devices such as teletypes?
>
> Multiplexor channels handled all sorts of low-speed record-oriented
> peripherals as well, e.g. card readers, line printers, and slower
> tape drives.
I know that. They were the byte multiplexor channels.
> However, when handling character-mode terminals, they
> imposed as much overhead per byte as they would for an entire block
> of data on those other peripherals - at least if you wanted the
> flexibility of responding to each byte as the user typed it.
The byte multiplexor channel also serviced teletype units,
breaking up records in order to send/receive individual bytes
when required. It did not transmit to the CPU until it had
receive an entire line. It received an entire record from
the CPU, and then forwarded individual bytes to the
terminal when required.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2020-05-28 11:50 +0000 |
| Message-ID | <rao8im$1ra$1@newsreader4.netcologne.de> |
| In reply to | #211576 |
John Levine <johnl@taugh.com> schrieb: > Quite right. IBM mainframes have I/O channels that can only do block > I/O. The only way to attach terminals is via front end systems that > handle the individual characters and turn them into blocks to send to > and from the channel. I once worked on an IBM mainframe compatible vector computer, a Siemens / Fujitsu VP 600. Nice machine, had 1024 parallel memory channels. As long as your Fortran arrays didn't have 1024 elements along the first dimension, this was very fast. Anyway, this started out on an MVS-compatible OS. Then, they switched to a UNIX variant, with interactive shells and all. The UNIX felt really strange. So, each time somebody pressed a key in an interactive sesssion, a data block was sent to the CPU, and one was sent back. I thought that _strange_. I also wrote a rant to UNIX-haters about this, but I cannot find that any more.
[toc] | [prev] | [next] | [standalone]
| From | Bob Eager <news0073@eager.cx> |
|---|---|
| Date | 2020-05-28 11:56 +0000 |
| Message-ID | <hj9n7uF7gtqU3@mid.individual.net> |
| In reply to | #211641 |
On Thu, 28 May 2020 11:50:46 +0000, Thomas Koenig wrote: > So, each time somebody pressed a key in an interactive sesssion, > a data block was sent to the CPU, and one was sent back. I thought that > _strange_. I also wrote a rant to UNIX-haters about this, but I cannot > find that any more. It didn't make it into the book - I just checked! -- Using UNIX since v6 (1975)... Use the BIG mirror service in the UK: http://www.mirrorservice.org
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2020-05-30 14:49 +0000 |
| Message-ID | <slrnrd4sk2.1r7q.grahn+nntp@frailea.sa.invalid> |
| In reply to | #211642 |
On Thu, 2020-05-28, Bob Eager wrote: > On Thu, 28 May 2020 11:50:46 +0000, Thomas Koenig wrote: > >> So, each time somebody pressed a key in an interactive sesssion, >> a data block was sent to the CPU, and one was sent back. I thought that >> _strange_. I also wrote a rant to UNIX-haters about this, but I cannot >> find that any more. > > It didn't make it into the book - I just checked! I somehow (in the 1990s) got the impression this was a later development, and not intrinsically Unix. Specifically, that people were horrified when vi came, with a design that meant every keystroke during text editing would use up computing resources. That may be a garbled account, but at least the idea survived: that at some point this level of interactivity was seen as an absurd waste. Much later, I was horrified when I learned you need a gigabyte of RAM to run the Eclipse IDE. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2020-05-30 17:39 +0000 |
| Message-ID | <rau5p3$tuh$1@gal.iecc.com> |
| In reply to | #211658 |
In article <slrnrd4sk2.1r7q.grahn+nntp@frailea.sa.invalid>, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote: >I somehow (in the 1990s) got the impression this was a later development, >and not intrinsically Unix. Specifically, that people were horrified when >vi came, with a design that meant every keystroke during text editing >would use up computing resources. No doubt some people were, but Unix always had tty raw mode that let you read a character at a time. In practice, raw mode wasn't very useful until most people had switched from Teletypes to video terminals. As I recall it was mostly used at the login prompt to try and guess whether you had an upper/lower or upper case only terminal. When I was an undergraduate in the early 1970s we had a PDP-10 with video terminals and a screen editor that interpreted characters one a a time. It worked fine. When we later reimplemented the editor on a PDP-11/45 with early bitmap terminals, I added a half-baked mode to the tty driver which would buffer input characters until you entered one that needed a more complex response than just an echo. I think it used a program settable bitmap. Then someone added insert mode to the editor which meant redrawing the rest of the line on each character to push the rest of the line one to the right. I was worried it would be too slow, but it was fine, too. The bitmap terminals were driven by a terminal emulator on an 11/05 and I think at some point I added insert mode to the emulator. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2020-05-30 19:07 +0000 |
| Message-ID | <s9yAG.62006$1y4.35288@fx23.iad> |
| In reply to | #211659 |
John Levine <johnl@taugh.com> writes:
>In article <slrnrd4sk2.1r7q.grahn+nntp@frailea.sa.invalid>,
>Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>>I somehow (in the 1990s) got the impression this was a later development,
>>and not intrinsically Unix. Specifically, that people were horrified when
>>vi came, with a design that meant every keystroke during text editing
>>would use up computing resources.
>
>No doubt some people were, but Unix always had tty raw mode that let
>you read a character at a time. In practice, raw mode wasn't very
>useful until most people had switched from Teletypes to video
>terminals. As I recall it was mostly used at the login prompt
>to try and guess whether you had an upper/lower or upper case only
>terminal.
I'm not sure raw mode is necessary for determining case, I would have
expected 'login.c' to check the username that was entered, and if it
was all uppercase, set the appropriate tty driver ioctl to map upper
case to lower case.
However, in looking at v6/s1/login.c, I don't see any such check; nor
does such a check exist in v7/usr/src/cmd/login.c
V7 does have this interesting code at the beginning of main:
alarm(60);
signal(SIGQUIT, SIG_IGN);
signal(SIGINT, SIG_IGN);
nice(-100);
nice(20);
nice(0);
gtty(0, &ttyb);
ttyb.sg_erase = '#';
ttyb.sg_kill = '@';
stty(0, &ttyb);
The triple nice call is noted in the nice man page:
For
a privileged process to return to normal priority from an unknown
state, nice should be called successively with arguments -40 (goes to
priority -20 because of truncation), 20 (to get to 0), then 0 (to main-
tain compatibility with previous versions of this call).
UW2.01 reverted to a single nice(0);
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2020-05-30 19:32 +0000 |
| Message-ID | <rauccr$1k3m$1@gal.iecc.com> |
| In reply to | #211660 |
In article <s9yAG.62006$1y4.35288@fx23.iad> you write: >>terminals. As I recall it was mostly used at the login prompt >>to try and guess whether you had an upper/lower or upper case only >>terminal. > >I'm not sure raw mode is necessary for determining case, I would have >expected 'login.c' to check the username that was entered, and if it >was all uppercase, set the appropriate tty driver ioctl to map upper >case to lower case. > >However, in looking at v6/s1/login.c, I don't see any such check; nor >does such a check exist in v7/usr/src/cmd/login.c It wasn't login.c, it was getty.c which cycled through a bunch of raw mode tty settings. On modem ports, you could hit break until it switched to the right speed and you got a legible prompt. https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/getty.c -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2020-05-30 13:10 -0700 |
| Message-ID | <9e1b2179-367a-47b1-84b8-ccc860644e24@googlegroups.com> |
| In reply to | #211659 |
On Saturday, May 30, 2020 at 11:39:48 AM UTC-6, John Levine wrote: > The bitmap terminals were driven by a terminal emulator > on an 11/05 and I think at some point I added insert mode to the > emulator. If you've got an 11/05 driving a terminal - vector, though, not bitmap - you could play Lunar Lander on it... so I'm not surprised insert mode is possible. John Savard
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2020-05-30 20:43 +0000 |
| Message-ID | <raughu$1v86$1@gal.iecc.com> |
| In reply to | #211663 |
In article <9e1b2179-367a-47b1-84b8-ccc860644e24@googlegroups.com>, Quadibloc <jsavard@ecn.ab.ca> wrote: >On Saturday, May 30, 2020 at 11:39:48 AM UTC-6, John Levine wrote: >> The bitmap terminals were driven by a terminal emulator >> on an 11/05 and I think at some point I added insert mode to the >> emulator. > >If you've got an 11/05 driving a terminal - vector, though, not bitmap - you could >play Lunar Lander on it... so I'm not surprised insert mode is possible. This was 40 years ago, it was definitely bit map, and the 11/05 was driving 16 screens running out of bitmap memory. Doing insert mode wasn't hard, since our characters were 8 bits wide, it just rippled down the rest of the line moving the image one byte ahead. Read all about it here: https://www.academia.edu/5519074/An_Overview_of_the_Yale_Gem_System -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | Dan Espen <dan1espen@gmail.com> |
|---|---|
| Date | 2020-05-30 15:50 -0400 |
| Message-ID | <rauddf$dbu$1@dont-email.me> |
| In reply to | #211658 |
Jorgen Grahn <grahn+nntp@snipabacken.se> writes: > On Thu, 2020-05-28, Bob Eager wrote: >> On Thu, 28 May 2020 11:50:46 +0000, Thomas Koenig wrote: >> >>> So, each time somebody pressed a key in an interactive sesssion, >>> a data block was sent to the CPU, and one was sent back. I thought that >>> _strange_. I also wrote a rant to UNIX-haters about this, but I cannot >>> find that any more. >> >> It didn't make it into the book - I just checked! > > I somehow (in the 1990s) got the impression this was a later development, > and not intrinsically Unix. Specifically, that people were horrified when > vi came, with a design that meant every keystroke during text editing > would use up computing resources. > > That may be a garbled account, but at least the idea survived: that at > some point this level of interactivity was seen as an absurd waste. I don't think so. I was working at Bell Labs when Emacs and VI were being born. They had a whole bunch of PDP machines, if you overloaded one, there were plenty of others to use. I started out using ed, it really wasn't any fun so I hunted down an Emacs version. It ran fine. Later on I heard Bill Joy had invented something called VI, I saw no reason to change. In the same time frame, IBM had released TSO (which used block mode terminals). A few of us got to experiment with TSO but there was no way to release that for general use, it used way too much mainframe resources. So, for at least a couple of years, we could do mainframe interactive development, but only by using a bunch of Unix systems with Emacs. Oh, yeah, we did have an IMS/DC full screen editor we could use, but it was so clunky that few of us suffered through it . So, perhaps character at a time was resource intensive, but UNIX cycles were abundant and cheap compared to mainframe cycles even with block mode terminals. > Much later, I was horrified when I learned you need a gigabyte of > RAM to run the Eclipse IDE. Fortunately, never had to go that way. I prefer the cleaner code that comes from hand crafting. -- Dan Espen
[toc] | [prev] | [next] | [standalone]
Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
Back to top | Article view | alt.folklore.computers
csiph-web