Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.folklore.computers > #220214 > unrolled thread
| Started by | "Stephen M. Jones" <smj@ma.sdf.org> |
|---|---|
| First post | 2022-03-02 21:32 +0000 |
| Last post | 2022-03-08 16:32 +0100 |
| Articles | 20 on this page of 93 — 23 participants |
Back to article view | Back to alt.folklore.computers
TOPS-20 Boot Camp for VMS Users 05-Mar-2022 "Stephen M. Jones" <smj@ma.sdf.org> - 2022-03-02 21:32 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-03-03 14:30 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Ahem A Rivet's Shot <steveo@eircom.net> - 2022-03-03 16:38 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-03-03 17:13 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Rich Alderson <news@alderson.users.panix.com> - 2022-03-03 15:33 -0500
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-03-03 21:55 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Peter Flass <peter_flass@yahoo.com> - 2022-03-04 12:06 -0700
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Paul Rubin <no.email@nospam.invalid> - 2022-03-04 13:23 -0800
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Johnny Billquist <bqt@softjar.se> - 2022-03-06 17:29 +0100
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Peter Flass <peter_flass@yahoo.com> - 2022-03-06 11:34 -0700
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-03-06 19:40 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Charles Richmond <codescott@aquaporin4.com> - 2022-12-23 11:49 -0600
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Anne & Lynn Wheeler <lynn@garlic.com> - 2022-12-23 10:34 -1000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Ahem A Rivet's Shot <steveo@eircom.net> - 2022-12-23 21:42 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Vir Campestris <vir.campestris@invalid.invalid> - 2022-12-24 11:54 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 D.J. <chucktheouch@gmnol.com> - 2022-12-24 11:17 -0600
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 D.J. <chucktheouch@gmnol.com> - 2022-12-24 18:01 -0600
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Peter Flass <peter_flass@yahoo.com> - 2022-12-25 11:24 -0700
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Anne & Lynn Wheeler <lynn@garlic.com> - 2022-12-25 09:12 -1000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Vir Campestris <vir.campestris@invalid.invalid> - 2022-12-30 17:06 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2022-12-30 19:09 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 D.J. <chucktheouch@gmnol.com> - 2022-12-30 16:11 -0600
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Thomas Koenig <tkoenig@netcologne.de> - 2022-12-30 20:22 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 D.J. <chucktheouch@gmnol.com> - 2022-12-30 16:12 -0600
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2022-12-30 23:44 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Anne & Lynn Wheeler <lynn@garlic.com> - 2022-12-23 12:18 -1000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2022-12-24 03:43 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Anne & Lynn Wheeler <lynn@garlic.com> - 2022-12-24 07:55 -1000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Peter Flass <peter_flass@yahoo.com> - 2022-12-24 11:08 -0700
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-12-24 18:36 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2022-12-24 21:09 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Anne & Lynn Wheeler <lynn@garlic.com> - 2022-12-24 14:03 -1000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Anne & Lynn Wheeler <lynn@garlic.com> - 2022-12-24 14:46 -1000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Paul Rubin <no.email@nospam.invalid> - 2022-03-06 11:17 -0800
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Johnny Billquist <bqt@softjar.se> - 2022-03-07 17:53 +0100
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Vir Campestris <vir.campestris@invalid.invalid> - 2022-03-07 22:02 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Charles Richmond <codescott@aquaporin4.com> - 2022-12-23 11:55 -0600
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Peter Flass <peter_flass@yahoo.com> - 2022-12-23 12:27 -0700
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2022-03-07 03:11 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Quadibloc <jsavard@ecn.ab.ca> - 2022-12-30 13:57 -0800
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Niklas Karlsson <nikke.karlsson@gmail.com> - 2022-12-30 22:11 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2022-12-30 23:44 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Niklas Karlsson <nikke.karlsson@gmail.com> - 2022-12-30 23:56 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 cb@elaine.df.lth.se (Christian Brunschen) - 2022-12-31 09:02 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Rich Alderson <news@alderson.users.panix.com> - 2022-12-30 20:44 -0500
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Peter Flass <peter_flass@yahoo.com> - 2022-12-30 20:08 -0700
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Quadibloc <jsavard@ecn.ab.ca> - 2022-12-31 00:25 -0800
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Johnny Billquist <bqt@softjar.se> - 2022-12-31 13:39 +0100
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Bob Eager <news0009@eager.cx> - 2022-03-04 00:46 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 "Stephen M. Jones" <smj@ma.sdf.org> - 2022-03-04 18:49 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 drb@ihatespam.msu.edu (Dennis Boone) - 2022-03-04 14:55 -0600
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-03-04 22:14 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Bob Eager <news0009@eager.cx> - 2022-03-04 22:17 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 David Lesher <wb8foz@panix.com> - 2022-03-06 04:35 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Ahem A Rivet's Shot <steveo@eircom.net> - 2022-03-06 05:40 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Rich Alderson <news@alderson.users.panix.com> - 2022-03-04 22:46 -0500
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Johnny Billquist <bqt@softjar.se> - 2022-03-06 17:21 +0100
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Peter Flass <peter_flass@yahoo.com> - 2022-03-06 11:34 -0700
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Johnny Billquist <bqt@softjar.se> - 2022-03-07 17:42 +0100
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Rich Alderson <news@alderson.users.panix.com> - 2022-03-06 20:43 -0500
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-03-07 15:07 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Johnny Billquist <bqt@softjar.se> - 2022-03-07 17:51 +0100
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-03-07 17:07 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Peter Flass <peter_flass@yahoo.com> - 2022-03-07 11:47 -0700
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-03-07 19:19 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Andreas Eder <a_eder_muc@web.de> - 2022-03-08 10:08 +0100
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Peter Flass <peter_flass@yahoo.com> - 2022-03-08 07:49 -0700
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2022-03-08 19:47 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Bob Eager <news0009@eager.cx> - 2022-03-09 01:03 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Johnny Billquist <bqt@softjar.se> - 2022-03-07 20:18 +0100
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-03-07 19:37 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Dan Espen <dan1espen@gmail.com> - 2022-03-07 14:53 -0500
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-03-07 20:43 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Ahem A Rivet's Shot <steveo@eircom.net> - 2022-03-07 19:52 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Rich Alderson <news@alderson.users.panix.com> - 2022-03-07 17:18 -0500
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-03-07 22:33 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-03-07 22:58 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Johnny Billquist <bqt@softjar.se> - 2022-03-08 00:06 +0100
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Peter Flass <peter_flass@yahoo.com> - 2022-03-08 07:49 -0700
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-03-08 15:22 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Peter Flass <peter_flass@yahoo.com> - 2022-03-08 11:17 -0700
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Vir Campestris <vir.campestris@invalid.invalid> - 2022-03-08 21:09 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-03-08 21:33 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Johnny Billquist <bqt@softjar.se> - 2022-03-07 20:24 +0100
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Rich Alderson <news@alderson.users.panix.com> - 2022-03-03 15:24 -0500
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Ahem A Rivet's Shot <steveo@eircom.net> - 2022-03-03 21:06 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Rich Alderson <news@alderson.users.panix.com> - 2022-03-04 22:47 -0500
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Peter Flass <peter_flass@yahoo.com> - 2022-03-04 12:06 -0700
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 D.J. <chucktheouch@gmail.com> - 2022-03-07 10:48 -0600
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 scott@slp53.sl.home (Scott Lurndal) - 2022-03-07 17:03 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 D.J. <chucktheouch@gmail.com> - 2022-03-07 19:52 -0600
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Fred Smith <fred@thejanitor.corp> - 2022-03-08 04:13 +0000
Re: TOPS-20 Boot Camp for VMS Users 05-Mar-2022 Johnny Billquist <bqt@softjar.se> - 2022-03-08 16:32 +0100
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-03-07 15:07 +0000 |
| Message-ID | <CcpVJ.46114$mF2.31622@fx11.iad> |
| In reply to | #220256 |
Rich Alderson <news@alderson.users.panix.com> writes:
>Johnny Billquist <bqt@softjar.se> writes:
>
>
>I do not know VMS (or RSTS/E or RSX) internals. Is DCL a separate program,
>like the TOPS-20 EXEC? Or an interaction with the monitor/kernel?
VMS is an odd beast in that respect. The VAX had a four privilege
rings (aside: interestingly enough, the relatively recent ARMv8
architecture also has four privilege rings (with a fifth coming soon)).
The kernel ran in the most privileged ring, Kernel Mode. RMS (mainly
derived from RSX-11, IIRC, and authored by Andy Goldstein (IIRC again))
ran in the next most privileged ring (Executive Mode). The Command
Interpreter (DCL) ran in the next ring (Supervisor Mode), and user
applications ran in the least privileged ring (User Mode).
As with most[*] ring-based privilege architectures, ring switches were
expensive and I believe once they went to Alpha, that architecture was
pretty much dead.
>
>> EXEC is for most people a much nicer environment than DCL. Command name
>> completion, filename completion, guide words, interactive help... It's
>> just so much nicer than DCL.
I didn't miss any of those features during the four years (1979-1983) that
I was doing systems programming on a four-vax cluster (with MA-780!), but
then I had been using TSS8.24 prior to that :-).
[*] most non-risc-based architectures, anyway. ARMv8 ring switches
while not free, can be quite efficient - far different from Intel
ring switches, for which three generations of ring-switch instructions
were created over the decades to make them more efficient.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2022-03-07 17:51 +0100 |
| Message-ID | <t05d76$k1t$1@news.misty.com> |
| In reply to | #220260 |
On 2022-03-07 16:07, Scott Lurndal wrote: > Rich Alderson <news@alderson.users.panix.com> writes: >> Johnny Billquist <bqt@softjar.se> writes: >> > >> >> I do not know VMS (or RSTS/E or RSX) internals. Is DCL a separate program, >> like the TOPS-20 EXEC? Or an interaction with the monitor/kernel? > > VMS is an odd beast in that respect. The VAX had a four privilege > rings (aside: interestingly enough, the relatively recent ARMv8 > architecture also has four privilege rings (with a fifth coming soon)). > > The kernel ran in the most privileged ring, Kernel Mode. RMS (mainly > derived from RSX-11, IIRC, and authored by Andy Goldstein (IIRC again)) > ran in the next most privileged ring (Executive Mode). The Command > Interpreter (DCL) ran in the next ring (Supervisor Mode), and user > applications ran in the least privileged ring (User Mode). > > As with most[*] ring-based privilege architectures, ring switches were > expensive and I believe once they went to Alpha, that architecture was > pretty much dead. People are always making the multiple processor modes a thing way bigger than it is. To comment more towards what Rich was thinking/asking, DCL is not a normal user program. It is possible to have other "shells" than DCL, which would live at the same level as DCL, but that almost was non-existant in real life. People instead have shells as programs running while DCL is still lurking in the background. So it's less flexible than in Unix or TOPS-20, where it's just a program like any other. RSX is in a way maybe the most weird of them all. In the goal to minimize memory and process resources, there is usually no program associated with your terminal when you are at the DCL prompt. Instead, it's all the responsibility of the terminal driver. Only when you've completed a line and hit enter will DCL (or MCR) be started for you, to process the line you typed. In VMS, DCL is there the whole time. >>> EXEC is for most people a much nicer environment than DCL. Command name >>> completion, filename completion, guide words, interactive help... It's >>> just so much nicer than DCL. > > I didn't miss any of those features during the four years (1979-1983) that > I was doing systems programming on a four-vax cluster (with MA-780!), but > then I had been using TSS8.24 prior to that :-). It's one of those things where if you never used it, you don't understand how much it means, and how much you'll miss it if it goes away. It's very similar to how you'll feel today if someone throws /bin/sh at you, and you are used to tcsh or bash. No filename completion, no line editing, no interactive information, no nothing. It's like going back to the dark ages. And TOPS-20 EXEC is *better* than tcsh or bash... Johnny
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-03-07 17:07 +0000 |
| Message-ID | <3ZqVJ.66921$4JN7.30690@fx05.iad> |
| In reply to | #220263 |
Johnny Billquist <bqt@softjar.se> writes: >On 2022-03-07 16:07, Scott Lurndal wrote: >> Rich Alderson <news@alderson.users.panix.com> writes: >>> Johnny Billquist <bqt@softjar.se> writes: >>> > >It's very similar to how you'll feel today if someone throws /bin/sh at >you, and you are used to tcsh or bash. No filename completion, no line >editing, no interactive information, no nothing. It's like going back to >the dark ages. For what it's worth, I've been using ksh since 1989 and while it supports filename completion, I've never used it (since I use vi-style command line editing, it takes more than just the tab key to invoke completion).
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2022-03-07 11:47 -0700 |
| Message-ID | <1092765219.668371347.362378.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #220266 |
Scott Lurndal <scott@slp53.sl.home> wrote: > Johnny Billquist <bqt@softjar.se> writes: >> On 2022-03-07 16:07, Scott Lurndal wrote: >>> Rich Alderson <news@alderson.users.panix.com> writes: >>>> Johnny Billquist <bqt@softjar.se> writes: >>>> > >> >> It's very similar to how you'll feel today if someone throws /bin/sh at >> you, and you are used to tcsh or bash. No filename completion, no line >> editing, no interactive information, no nothing. It's like going back to >> the dark ages. > > For what it's worth, I've been using ksh since 1989 and while it supports > filename completion, I've never used it (since I use vi-style command > line editing, it takes more than just the tab key to invoke completion). > I’m always amazed when I try to use some piece of software I used to use years ago how primitive it seems now. Back then non-ISPF TSO or DOS EDLIN seemed like usable, if not much fun, pieces of software. Playing with old systems like TSS or Multics it seems like my biggest problem is lack of a decent editor. -- Pete
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-03-07 19:19 +0000 |
| Message-ID | <4VsVJ.65365$oF2.34230@fx10.iad> |
| In reply to | #220267 |
Peter Flass <peter_flass@yahoo.com> writes: >Scott Lurndal <scott@slp53.sl.home> wrote: >> Johnny Billquist <bqt@softjar.se> writes: >>> On 2022-03-07 16:07, Scott Lurndal wrote: >>>> Rich Alderson <news@alderson.users.panix.com> writes: >>>>> Johnny Billquist <bqt@softjar.se> writes: >>>>> >> >>> >>> It's very similar to how you'll feel today if someone throws /bin/sh at >>> you, and you are used to tcsh or bash. No filename completion, no line >>> editing, no interactive information, no nothing. It's like going back to >>> the dark ages. >> >> For what it's worth, I've been using ksh since 1989 and while it supports >> filename completion, I've never used it (since I use vi-style command >> line editing, it takes more than just the tab key to invoke completion). >> > >I’m always amazed when I try to use some piece of software I used to use >years ago how primitive it seems now. Back then non-ISPF TSO or DOS EDLIN >seemed like usable, if not much fun, pieces of software. Playing with old >systems like TSS or Multics it seems like my biggest problem is lack of a >decent editor. Yeah. I occasionally fire up tss8.24 on simh just to recall the old days; using PIP to copy files seems so 1974. I also fire up the HP-3000 MPE on simh as I used that after the PDP-8, but before the VAX. Interactively, it was better than tss8.24, but compared to DCL, the command language was limited (no scripting capability, for example) - however, the concept of PASS files was an interesting feature - during a compile-link-run job the output of a step could be written to $NEWPASS and the next step would read from $OLDPASS; a transient unnamed temporary disk file. $ BASICCOMP FILE.BAS $ PREP $OLDPASS, $NEWPASS $ RUN $OLDPASS
[toc] | [prev] | [next] | [standalone]
| From | Andreas Eder <a_eder_muc@web.de> |
|---|---|
| Date | 2022-03-08 10:08 +0100 |
| Message-ID | <87fsnske0l.fsf@eder.anydns.info> |
| In reply to | #220267 |
On Mo 07 Mär 2022 at 11:47, Peter Flass <peter_flass@yahoo.com> wrote: > Scott Lurndal <scott@slp53.sl.home> wrote: > I’m always amazed when I try to use some piece of software I used to use > years ago how primitive it seems now. Back then non-ISPF TSO or DOS EDLIN > seemed like usable, if not much fun, pieces of software. Playing with old > systems like TSS or Multics it seems like my biggest problem is lack of a > decent editor. Well, on Multics you have Emacs! That should be enough for everyone :-) 'Andreas
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2022-03-08 07:49 -0700 |
| Message-ID | <102799188.668443547.470178.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #220283 |
Andreas Eder <a_eder_muc@web.de> wrote: > On Mo 07 Mär 2022 at 11:47, Peter Flass <peter_flass@yahoo.com> wrote: > >> Scott Lurndal <scott@slp53.sl.home> wrote: >> I’m always amazed when I try to use some piece of software I used to use >> years ago how primitive it seems now. Back then non-ISPF TSO or DOS EDLIN >> seemed like usable, if not much fun, pieces of software. Playing with old >> systems like TSS or Multics it seems like my biggest problem is lack of a >> decent editor. > > Well, on Multics you have Emacs! > That should be enough for everyone :-) I’ve managed to get fifty years in without having to learn emacs. I don’t want to have to start now. -- Pete
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2022-03-08 19:47 +0000 |
| Message-ID | <ZoOVJ.50486$mF2.29500@fx11.iad> |
| In reply to | #220285 |
On 2022-03-08, Peter Flass <peter_flass@yahoo.com> wrote: > Andreas Eder <a_eder_muc@web.de> wrote: > >> On Mo 07 Mär 2022 at 11:47, Peter Flass <peter_flass@yahoo.com> wrote: >> >>> I’m always amazed when I try to use some piece of software I used to use >>> years ago how primitive it seems now. Back then non-ISPF TSO or DOS EDLIN >>> seemed like usable, if not much fun, pieces of software. Playing with old >>> systems like TSS or Multics it seems like my biggest problem is lack of a >>> decent editor. >> >> Well, on Multics you have Emacs! >> That should be enough for everyone :-) > > I’ve managed to get fifty years in without having to learn emacs. > I don’t want to have to start now. I took a look at emacs a couple of years ago. I found its mindset to be too foreign for me, e.g. in things like tab handling. My fingers speak vi. That's usually enough. -- /~\ Charlie Gibbs | Microsoft is a dictatorship. \ / <cgibbs@kltpzyxm.invalid> | Apple is a cult. X I'm really at ac.dekanfrus | Linux is anarchy. / \ if you read it the right way. | Pick your poison.
[toc] | [prev] | [next] | [standalone]
| From | Bob Eager <news0009@eager.cx> |
|---|---|
| Date | 2022-03-09 01:03 +0000 |
| Message-ID | <j8qcn1Fi99fU4@mid.individual.net> |
| In reply to | #220289 |
On Tue, 08 Mar 2022 19:47:05 +0000, Charlie Gibbs wrote: > I took a look at emacs a couple of years ago. > I found its mindset to be too foreign for me, > e.g. in things like tab handling. > > My fingers speak vi. That's usually enough. I have exactly the opposite. I started UNIX in 1975, although vi took a while to appear. I continued to use 'ed' because my terminal was a bit basic. Then I got a PC with a simplified emacs that was marketed as part of a 'word processor'. My fingers know that (but I also use 'ed' in extremis, usually in single user mode on a basic console). -- Using UNIX since v6 (1975)... Use the BIG mirror service in the UK: http://www.mirrorservice.org
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2022-03-07 20:18 +0100 |
| Message-ID | <t05lq4$u25$1@news.misty.com> |
| In reply to | #220266 |
On 2022-03-07 18:07, Scott Lurndal wrote: > Johnny Billquist <bqt@softjar.se> writes: >> On 2022-03-07 16:07, Scott Lurndal wrote: >>> Rich Alderson <news@alderson.users.panix.com> writes: >>>> Johnny Billquist <bqt@softjar.se> writes: >>>> > >> >> It's very similar to how you'll feel today if someone throws /bin/sh at >> you, and you are used to tcsh or bash. No filename completion, no line >> editing, no interactive information, no nothing. It's like going back to >> the dark ages. > > For what it's worth, I've been using ksh since 1989 and while it supports > filename completion, I've never used it (since I use vi-style command > line editing, it takes more than just the tab key to invoke completion). Never used ksh, but it still certainly sounds like miles from sh. I don't expect people will really get involved in TOPS-20 EXEC now, but if you were to use it for a while, I think you'd start see my point. :-) If you ever use Cisco gear, you might have gotten some taste of it as well... Johnny
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-03-07 19:37 +0000 |
| Message-ID | <5atVJ.65997$oF2.42054@fx10.iad> |
| In reply to | #220268 |
Johnny Billquist <bqt@softjar.se> writes: >On 2022-03-07 18:07, Scott Lurndal wrote: >> Johnny Billquist <bqt@softjar.se> writes: >>> On 2022-03-07 16:07, Scott Lurndal wrote: >>>> Rich Alderson <news@alderson.users.panix.com> writes: >>>>> Johnny Billquist <bqt@softjar.se> writes: >>>>> >> >>> >>> It's very similar to how you'll feel today if someone throws /bin/sh at >>> you, and you are used to tcsh or bash. No filename completion, no line >>> editing, no interactive information, no nothing. It's like going back to >>> the dark ages. >> >> For what it's worth, I've been using ksh since 1989 and while it supports >> filename completion, I've never used it (since I use vi-style command >> line editing, it takes more than just the tab key to invoke completion). > >Never used ksh, but it still certainly sounds like miles from sh. Indeed, ksh is quite powerful - you can even access arbitrary shared library functions linked in at runtime; has associative arrays and a host of other useful scripting features (ksh93). > >I don't expect people will really get involved in TOPS-20 EXEC now, but >if you were to use it for a while, I think you'd start see my point. :-) I find most of those old command interpreters limited and unusable after using the korn shell for so many years. I could give TOPS-20 EXEC a try on simh someday to see, but I don't expect to like it much; I suppose I could try to port the COBOL startrek game to COBOL on the PDP-10 someday when I have absolutely nothing else to do :-) > >If you ever use Cisco gear, you might have gotten some taste of it as >well... I got an offer to join the IOS team (and an offer from NetApp at the same time), but turned them down and went to SGI instead - both Cisco and Netapp would have been financially more lucrative in the long run, sadly.
[toc] | [prev] | [next] | [standalone]
| From | Dan Espen <dan1espen@gmail.com> |
|---|---|
| Date | 2022-03-07 14:53 -0500 |
| Message-ID | <t05nrt$8bs$1@dont-email.me> |
| In reply to | #220271 |
scott@slp53.sl.home (Scott Lurndal) writes: > Johnny Billquist <bqt@softjar.se> writes: >>On 2022-03-07 18:07, Scott Lurndal wrote: >>> Johnny Billquist <bqt@softjar.se> writes: >>>> On 2022-03-07 16:07, Scott Lurndal wrote: >>>>> Rich Alderson <news@alderson.users.panix.com> writes: >>>>>> Johnny Billquist <bqt@softjar.se> writes: >>>>>> >>> >>>> >>>> It's very similar to how you'll feel today if someone throws /bin/sh at >>>> you, and you are used to tcsh or bash. No filename completion, no line >>>> editing, no interactive information, no nothing. It's like going back to >>>> the dark ages. >>> >>> For what it's worth, I've been using ksh since 1989 and while it supports >>> filename completion, I've never used it (since I use vi-style command >>> line editing, it takes more than just the tab key to invoke completion). >> >>Never used ksh, but it still certainly sounds like miles from sh. > > Indeed, ksh is quite powerful - you can even access arbitrary shared > library functions linked in at runtime; has associative arrays and > a host of other useful scripting features (ksh93). ksh has lots of good stuff, but miles from sh doesn't seem right. It's very much like sh to a casual user. -- Dan Espen
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-03-07 20:43 +0000 |
| Message-ID | <J7uVJ.104809$Gojc.84268@fx99.iad> |
| In reply to | #220272 |
Dan Espen <dan1espen@gmail.com> writes: >scott@slp53.sl.home (Scott Lurndal) writes: > >> Johnny Billquist <bqt@softjar.se> writes: >>>On 2022-03-07 18:07, Scott Lurndal wrote: >>>> Johnny Billquist <bqt@softjar.se> writes: >>>>> On 2022-03-07 16:07, Scott Lurndal wrote: >>>>>> Rich Alderson <news@alderson.users.panix.com> writes: >>>>>>> Johnny Billquist <bqt@softjar.se> writes: >>>>>>> >>>> >>>>> >>>>> It's very similar to how you'll feel today if someone throws /bin/sh at >>>>> you, and you are used to tcsh or bash. No filename completion, no line >>>>> editing, no interactive information, no nothing. It's like going back to >>>>> the dark ages. >>>> >>>> For what it's worth, I've been using ksh since 1989 and while it supports >>>> filename completion, I've never used it (since I use vi-style command >>>> line editing, it takes more than just the tab key to invoke completion). >>> >>>Never used ksh, but it still certainly sounds like miles from sh. >> >> Indeed, ksh is quite powerful - you can even access arbitrary shared >> library functions linked in at runtime; has associative arrays and >> a host of other useful scripting features (ksh93). > >ksh has lots of good stuff, but miles from sh doesn't seem right. >It's very much like sh to a casual user. by design.
[toc] | [prev] | [next] | [standalone]
| From | Ahem A Rivet's Shot <steveo@eircom.net> |
|---|---|
| Date | 2022-03-07 19:52 +0000 |
| Message-ID | <20220307195246.548e2294e2b12c3a7ee2deae@eircom.net> |
| In reply to | #220268 |
On Mon, 7 Mar 2022 20:18:28 +0100 Johnny Billquist <bqt@softjar.se> wrote: > On 2022-03-07 18:07, Scott Lurndal wrote: > > Johnny Billquist <bqt@softjar.se> writes: > >> On 2022-03-07 16:07, Scott Lurndal wrote: > >>> Rich Alderson <news@alderson.users.panix.com> writes: > >>>> Johnny Billquist <bqt@softjar.se> writes: > >>>> > > > >> > >> It's very similar to how you'll feel today if someone throws /bin/sh at > >> you, and you are used to tcsh or bash. No filename completion, no line > >> editing, no interactive information, no nothing. It's like going back > >> to the dark ages. > > > > For what it's worth, I've been using ksh since 1989 and while it > > supports filename completion, I've never used it (since I use vi-style > > command line editing, it takes more than just the tab key to invoke > > completion). > > Never used ksh, but it still certainly sounds like miles from sh. It's surprisingly close - basically sh with history and filename completion added, much of bash history manipulation comes from ksh the rest from csh. -- Steve O'Hara-Smith Odds and Ends at http://www.sohara.org/
[toc] | [prev] | [next] | [standalone]
| From | Rich Alderson <news@alderson.users.panix.com> |
|---|---|
| Date | 2022-03-07 17:18 -0500 |
| Message-ID | <mddee3d4db3.fsf@panix5.panix.com> |
| In reply to | #220260 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Rich Alderson <news@alderson.users.panix.com> writes:
>> Johnny Billquist <bqt@softjar.se> writes:
>> I do not know VMS (or RSTS/E or RSX) internals. Is DCL a separate program,
>> like the TOPS-20 EXEC? Or an interaction with the monitor/kernel?
> VMS is an odd beast in that respect. The VAX had a four privilege
> rings (aside: interestingly enough, the relatively recent ARMv8
> architecture also has four privilege rings (with a fifth coming soon)).
> The kernel ran in the most privileged ring, Kernel Mode. RMS (mainly
> derived from RSX-11, IIRC, and authored by Andy Goldstein (IIRC again))
> ran in the next most privileged ring (Executive Mode). The Command
> Interpreter (DCL) ran in the next ring (Supervisor Mode), and user
> applications ran in the least privileged ring (User Mode).
Interestingly, the *2nd generation* PDP-10, the KI-10 processor, implemented a
4-level privilege model: Kernel, Executive, Public, and User. Tops-10 ran
mostly in Executive mode, with only some of the most sensitive routines done in
Kernel mode. Public mode was a user-level mode (i.e., no privileged
instructions such as I/O operations) which allowed for system services similar
to dynamic libraries in modern Unix-style operating systems, but serving a
different purpose. User mode was the bog standard mode for any program not
requiring elevated privileges.
(Public mode was used by the system services such as spoolers so that user
programs did not need to use system calls to interact with unit record
equipment.)
> As with most[*] ring-based privilege architectures, ring switches were
> expensive and I believe once they went to Alpha, that architecture was
> pretty much dead.
The KI model was not ring-based in the way that I understand rings (based on
early Multics writings, mostly); it was simply a matter of a couple of bits in
the process status.
--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-03-07 22:33 +0000 |
| Message-ID | <DKvVJ.164322$t2Bb.114365@fx98.iad> |
| In reply to | #220276 |
Rich Alderson <news@alderson.users.panix.com> writes: >scott@slp53.sl.home (Scott Lurndal) writes: > >> Rich Alderson <news@alderson.users.panix.com> writes: >>> Johnny Billquist <bqt@softjar.se> writes: > >>> I do not know VMS (or RSTS/E or RSX) internals. Is DCL a separate program, >>> like the TOPS-20 EXEC? Or an interaction with the monitor/kernel? > >> VMS is an odd beast in that respect. The VAX had a four privilege >> rings (aside: interestingly enough, the relatively recent ARMv8 >> architecture also has four privilege rings (with a fifth coming soon)). > >> The kernel ran in the most privileged ring, Kernel Mode. RMS (mainly >> derived from RSX-11, IIRC, and authored by Andy Goldstein (IIRC again)) >> ran in the next most privileged ring (Executive Mode). The Command >> Interpreter (DCL) ran in the next ring (Supervisor Mode), and user >> applications ran in the least privileged ring (User Mode). > >Interestingly, the *2nd generation* PDP-10, the KI-10 processor, implemented a >4-level privilege model: Kernel, Executive, Public, and User. Tops-10 ran >mostly in Executive mode, with only some of the most sensitive routines done in >Kernel mode. Public mode was a user-level mode (i.e., no privileged >instructions such as I/O operations) which allowed for system services similar >to dynamic libraries in modern Unix-style operating systems, but serving a >different purpose. User mode was the bog standard mode for any program not >requiring elevated privileges. > >(Public mode was used by the system services such as spoolers so that user > programs did not need to use system calls to interact with unit record > equipment.) > >> As with most[*] ring-based privilege architectures, ring switches were >> expensive and I believe once they went to Alpha, that architecture was >> pretty much dead. > >The KI model was not ring-based in the way that I understand rings (based on >early Multics writings, mostly); it was simply a matter of a couple of bits in >the process status. It's changing between rings that is the primary issue as that often includes a change in the memory context (e.g. x86 segment, active page table) resulting in a performance hit. E.g. UUO's/system calls.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-03-07 22:58 +0000 |
| Message-ID | <c6wVJ.106047$aT3.10944@fx09.iad> |
| In reply to | #220277 |
scott@slp53.sl.home (Scott Lurndal) writes: >Rich Alderson <news@alderson.users.panix.com> writes: >>scott@slp53.sl.home (Scott Lurndal) writes: >> >>> Rich Alderson <news@alderson.users.panix.com> writes: >>>> Johnny Billquist <bqt@softjar.se> writes: >> >>>> I do not know VMS (or RSTS/E or RSX) internals. Is DCL a separate program, >>>> like the TOPS-20 EXEC? Or an interaction with the monitor/kernel? >> >>> VMS is an odd beast in that respect. The VAX had a four privilege >>> rings (aside: interestingly enough, the relatively recent ARMv8 >>> architecture also has four privilege rings (with a fifth coming soon)). >> >>> The kernel ran in the most privileged ring, Kernel Mode. RMS (mainly >>> derived from RSX-11, IIRC, and authored by Andy Goldstein (IIRC again)) >>> ran in the next most privileged ring (Executive Mode). The Command >>> Interpreter (DCL) ran in the next ring (Supervisor Mode), and user >>> applications ran in the least privileged ring (User Mode). >> >>Interestingly, the *2nd generation* PDP-10, the KI-10 processor, implemented a >>4-level privilege model: Kernel, Executive, Public, and User. Tops-10 ran >>mostly in Executive mode, with only some of the most sensitive routines done in >>Kernel mode. Public mode was a user-level mode (i.e., no privileged >>instructions such as I/O operations) which allowed for system services similar >>to dynamic libraries in modern Unix-style operating systems, but serving a >>different purpose. User mode was the bog standard mode for any program not >>requiring elevated privileges. >> >>(Public mode was used by the system services such as spoolers so that user >> programs did not need to use system calls to interact with unit record >> equipment.) >> >>> As with most[*] ring-based privilege architectures, ring switches were >>> expensive and I believe once they went to Alpha, that architecture was >>> pretty much dead. >> >>The KI model was not ring-based in the way that I understand rings (based on >>early Multics writings, mostly); it was simply a matter of a couple of bits in >>the process status. > >It's changing between rings that is the primary issue as that often >includes a change in the memory context (e.g. x86 segment, active page >table) resulting in a performance hit. E.g. UUO's/system calls. What really killed it on the VAX was multiple ring changes for many operations (file operations executed in executive mode, and they called kernel mode facilities like $QIO/$QIOW). On the other hand, user mode could make requests to DCL with a change mode to supervisor call.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2022-03-08 00:06 +0100 |
| Message-ID | <t06367$ep9$1@news.misty.com> |
| In reply to | #220278 |
On 2022-03-07 23:58, Scott Lurndal wrote: > scott@slp53.sl.home (Scott Lurndal) writes: >> It's changing between rings that is the primary issue as that often >> includes a change in the memory context (e.g. x86 segment, active page >> table) resulting in a performance hit. E.g. UUO's/system calls. > > What really killed it on the VAX was multiple ring changes for many > operations (file operations executed in executive mode, and they > called kernel mode facilities like $QIO/$QIOW). On the other hand, > user mode could make requests to DCL with a change mode to supervisor > call. What do you mean "killed it on the VAX"? Changing mode means trapping to the OS. Doing a system call means trapping to the OS. Is a change mode any more costly than any system call? No. Are you claiming there is some extra performance penalty here? You could argue that the changing of modes carried a performance benefit, since it meant you did not need to switch context to another process, and you did not need to flush TLBs and so on, since the memory mapping is unchanged. Changing modes effectively just changed what parts of memory was accessible, apart from kernel mode which allowed some instructions not allowed otherwise. And that is also why implementing the whole thing on a processor with fewer modes isn't really a big deal. It's just a question of what your page table looks like. And that can obviously be changed whenever you trap into the OS anyway. Johnny
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2022-03-08 07:49 -0700 |
| Message-ID | <157167114.668443252.099266.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #220277 |
Scott Lurndal <scott@slp53.sl.home> wrote: > Rich Alderson <news@alderson.users.panix.com> writes: >> scott@slp53.sl.home (Scott Lurndal) writes: >> >>> Rich Alderson <news@alderson.users.panix.com> writes: >>>> Johnny Billquist <bqt@softjar.se> writes: >> >>>> I do not know VMS (or RSTS/E or RSX) internals. Is DCL a separate program, >>>> like the TOPS-20 EXEC? Or an interaction with the monitor/kernel? >> >>> VMS is an odd beast in that respect. The VAX had a four privilege >>> rings (aside: interestingly enough, the relatively recent ARMv8 >>> architecture also has four privilege rings (with a fifth coming soon)). >> >>> The kernel ran in the most privileged ring, Kernel Mode. RMS (mainly >>> derived from RSX-11, IIRC, and authored by Andy Goldstein (IIRC again)) >>> ran in the next most privileged ring (Executive Mode). The Command >>> Interpreter (DCL) ran in the next ring (Supervisor Mode), and user >>> applications ran in the least privileged ring (User Mode). >> >> Interestingly, the *2nd generation* PDP-10, the KI-10 processor, implemented a >> 4-level privilege model: Kernel, Executive, Public, and User. Tops-10 ran >> mostly in Executive mode, with only some of the most sensitive routines done in >> Kernel mode. Public mode was a user-level mode (i.e., no privileged >> instructions such as I/O operations) which allowed for system services similar >> to dynamic libraries in modern Unix-style operating systems, but serving a >> different purpose. User mode was the bog standard mode for any program not >> requiring elevated privileges. >> >> (Public mode was used by the system services such as spoolers so that user >> programs did not need to use system calls to interact with unit record >> equipment.) >> >>> As with most[*] ring-based privilege architectures, ring switches were >>> expensive and I believe once they went to Alpha, that architecture was >>> pretty much dead. >> >> The KI model was not ring-based in the way that I understand rings (based on >> early Multics writings, mostly); it was simply a matter of a couple of bits in >> the process status. > > It's changing between rings that is the primary issue as that often > includes a change in the memory context (e.g. x86 segment, active page > table) resulting in a performance hit. E.g. UUO's/system calls. > Some systems (Sigma) had different register sets for different processor modes. Memory is cheap these days, why not different caches? -- Pete
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-03-08 15:22 +0000 |
| Message-ID | <ZwKVJ.50238$mF2.40615@fx11.iad> |
| In reply to | #220284 |
Peter Flass <peter_flass@yahoo.com> writes: >Scott Lurndal <scott@slp53.sl.home> wrote: >> Rich Alderson <news@alderson.users.panix.com> writes: >>> scott@slp53.sl.home (Scott Lurndal) writes: >>> >>>> Rich Alderson <news@alderson.users.panix.com> writes: >>>>> Johnny Billquist <bqt@softjar.se> writes: >>> >>>>> I do not know VMS (or RSTS/E or RSX) internals. Is DCL a separate program, >>>>> like the TOPS-20 EXEC? Or an interaction with the monitor/kernel? >>> >>>> VMS is an odd beast in that respect. The VAX had a four privilege >>>> rings (aside: interestingly enough, the relatively recent ARMv8 >>>> architecture also has four privilege rings (with a fifth coming soon)). >>> >>>> The kernel ran in the most privileged ring, Kernel Mode. RMS (mainly >>>> derived from RSX-11, IIRC, and authored by Andy Goldstein (IIRC again)) >>>> ran in the next most privileged ring (Executive Mode). The Command >>>> Interpreter (DCL) ran in the next ring (Supervisor Mode), and user >>>> applications ran in the least privileged ring (User Mode). >>> >>> Interestingly, the *2nd generation* PDP-10, the KI-10 processor, implemented a >>> 4-level privilege model: Kernel, Executive, Public, and User. Tops-10 ran >>> mostly in Executive mode, with only some of the most sensitive routines done in >>> Kernel mode. Public mode was a user-level mode (i.e., no privileged >>> instructions such as I/O operations) which allowed for system services similar >>> to dynamic libraries in modern Unix-style operating systems, but serving a >>> different purpose. User mode was the bog standard mode for any program not >>> requiring elevated privileges. >>> >>> (Public mode was used by the system services such as spoolers so that user >>> programs did not need to use system calls to interact with unit record >>> equipment.) >>> >>>> As with most[*] ring-based privilege architectures, ring switches were >>>> expensive and I believe once they went to Alpha, that architecture was >>>> pretty much dead. >>> >>> The KI model was not ring-based in the way that I understand rings (based on >>> early Multics writings, mostly); it was simply a matter of a couple of bits in >>> the process status. >> >> It's changing between rings that is the primary issue as that often >> includes a change in the memory context (e.g. x86 segment, active page >> table) resulting in a performance hit. E.g. UUO's/system calls. >> > >Some systems (Sigma) had different register sets for different processor >modes. Memory is cheap these days, why not different caches? Indeed, it's difficult to compare systems designed 40 to 50 years ago with modern processors. But even today, nobody uses more than two of the four rings on Intel processors. (well, technically, one can consider VM-X/SVM a ring, and SMM mode can also be considered a ring, and in both cases, crossing the ring boundary isn't cheap - see VMEXIT).
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | alt.folklore.computers
csiph-web