7-Jan-2005 18:16:19 -0800,798;000000000000
Return-Path: <MRC@lingling.panda.com>
Received: via tmail-2002(14) for t20arc; Fri, 7 Jan 2005 18:16:18 -0800 (PST)
Return-Path: <MRC@lingling.panda.com>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id SAA16611; Fri, 7 Jan 2005 18:16:17 -0800 (PST)
Date: Fri, 7 Jan 2005 17:54:26 -0800 (PST)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: 2004, a busy year for the TOPS-20 list!
To: TOPS-20@lingling.panda.com
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <13992743263.13.MRC@lingling.panda.com>
The TOPS-20 list traffic in 2004 was the highest since 1986, after which
there was a rapid decline. I would like to wish everybody on the list a
happy, prosperous, and healthy New Year!
-------
7-Jan-2005 22:13:40 -0800,1510;000000000000
Return-Path: <smj@sdf.lonestar.org>
Received: via tmail-2002(14) for t20arc; Fri, 7 Jan 2005 22:13:40 -0800 (PST)
Return-Path: <smj@sdf.lonestar.org>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id WAA16695; Fri, 7 Jan 2005 22:13:39 -0800 (PST)
Received: from sdf.lonestar.org (mx.freeshell.org [192.94.73.21]) by lingling.panda.com with TCP/SMTP; Fri, 7 Jan 2005 21:52:52 -0800 (PST)
Received: from sdf.lonestar.org (ol.freeshell.org [192.94.73.20])
by sdf.lonestar.org (8.12.10/8.12.10) with ESMTP id j085qj5n015213;
Sat, 8 Jan 2005 05:52:45 GMT
Received: (from smj@localhost)
by sdf.lonestar.org (8.12.10/8.12.8/Submit) id j085qjJh012563;
Sat, 8 Jan 2005 05:52:45 GMT
From: Stephen Jones <smj@sdf.lonestar.org>
Message-Id: <200501080552.j085qjJh012563@sdf.lonestar.org>
Subject: Re: 2004, a busy year for the TOPS-20 list!
In-Reply-To: <13992743263.13.MRC@lingling.panda.com>
To: Mark Crispin <MRC@lingling.panda.com>
Date: Sat, 8 Jan 2005 05:52:45 +0000 (UTC)
CC: TOPS-20@lingling.panda.com
X-Mailer: ELM [version 2.4ME+ PL93 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
MRC wrote:
> The TOPS-20 list traffic in 2004 was the highest since 1986 ..
Deja vu .. didn't this happen last year too?
In related news, there were 2009 accounts created on twenex.org
during the entire year of 2004 .. however, that is down from the
6869 accounts that were created in 2003.
8-Jan-2005 11:29:51 -0800,2393;000000000000
Return-Path: <dlm@opost.com>
Received: via tmail-2002(14) for t20arc; Sat, 8 Jan 2005 11:29:51 -0800 (PST)
Return-Path: <dlm@opost.com>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id LAA17057; Sat, 8 Jan 2005 11:29:50 -0800 (PST)
Received: from mv.opost.com ([199.125.75.195]) by lingling.panda.com with TCP/SMTP; Sat, 8 Jan 2005 11:06:51 -0800 (PST)
Received: from road.fpl (cpe-24-181-237-7.ma.charter.com [24.181.237.7])
(authenticated bits=0)
by mv.opost.com (8.12.8/8.12.8) with ESMTP id j08J6ltL031986
for <TOPS-20@lingling.panda.com>; Sat, 8 Jan 2005 14:06:47 -0500
Received: from road.fpl (localhost [127.0.0.1])
by road.fpl (8.12.10/8.12.10) with ESMTP id j08J6gut005409
for <TOPS-20@lingling.panda.com>; Sat, 8 Jan 2005 14:06:42 -0500
Received: (from dlm@localhost)
by road.fpl (8.12.10/8.12.10/Submit) id j08J6gtI005407
for TOPS-20@lingling.panda.com; Sat, 8 Jan 2005 14:06:42 -0500
Date: Sat, 8 Jan 2005 14:06:42 -0500
Message-Id: <200501081906.j08J6gtI005407@road.fpl>
From: Dan Murphy <dlm@opost.com>
To: TOPS-20@lingling.panda.com
Subject: Re: 2004, a busy year for the TOPS-20 list!
Reply-To: Dan Murphy <dlm@opost.com>
X-OpostMailScanner: Not scanned
Well, it seems that today is a day of discovery for me. Until
this post, I was not aware of twenex.org. I just signed up for an
account to help the 2005 total.
Also, I was not until the very moment aware of the existence of
the song "Teco and DDT". Amazing!! The old lore is not dead.
Speaking of old songs, I put a bunch on a CD some years ago.
"Digital County Store" and "Woman at the Well (then and now)"
would be of particular interest to ex-Deccies and friends. More
description and all mp3s may be found at
http://www.opost.com/opcd/ . And yes, you can order a physical CD
if you really want.
dlm
=====================
Stephen Jones <smj@sdf.lonestar.org> on Sat, 8 Jan 2005 05:52:45 +0000 (UTC) writes:
> MRC wrote:
> > The TOPS-20 list traffic in 2004 was the highest since 1986 ..
> Deja vu .. didn't this happen last year too?
> In related news, there were 2009 accounts created on twenex.org
> during the entire year of 2004 .. however, that is down from the
> 6869 accounts that were created in 2003.
8-Jan-2005 16:45:30 -0800,4424;000000000000
Return-Path: <smj@sdf.lonestar.org>
Received: via tmail-2002(14) for t20arc; Sat, 8 Jan 2005 16:45:30 -0800 (PST)
Return-Path: <smj@sdf.lonestar.org>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id QAA17168; Sat, 8 Jan 2005 16:45:29 -0800 (PST)
Received: from sdf.lonestar.org (mx.freeshell.org [192.94.73.21]) by lingling.panda.com with TCP/SMTP; Sat, 8 Jan 2005 16:22:51 -0800 (PST)
Received: from sdf.lonestar.org (ol.freeshell.org [192.94.73.20])
by sdf.lonestar.org (8.12.10/8.12.10) with ESMTP id j090MiCj012016;
Sun, 9 Jan 2005 00:22:44 GMT
Received: (from smj@localhost)
by sdf.lonestar.org (8.12.10/8.12.8/Submit) id j090MiJd001119;
Sun, 9 Jan 2005 00:22:44 GMT
From: Stephen Jones <smj@sdf.lonestar.org>
Message-Id: <200501090022.j090MiJd001119@sdf.lonestar.org>
Subject: Re: 2004, a busy year for the TOPS-20 list!
In-Reply-To: <200501081906.j08J6gtI005407@road.fpl>
To: Dan Murphy <dlm@opost.com>
Date: Sun, 9 Jan 2005 00:22:44 +0000 (UTC)
CC: TOPS-20@lingling.panda.com
X-Mailer: ELM [version 2.4ME+ PL93 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
DLM wrote:
> Well, it seems that today is a day of discovery for me. Until
> this post, I was not aware of twenex.org. I just signed up for an
> account to help the 2005 total.
Great to hear! There are a number of visitors, but only a handful of
people persist. Both KLH and MRC need to be thanked for providing the
software means of making it possible. Prior to that the idea was to
use a KS10 from 1994 but the big hold up was finding reliable drives
(and not RP06 or RP07) that were affordable to run 24/7. Ken's KL10B
emulator runs the 'panda dist' that Mark has put together on a DEC Alpha
DS10L. I also need to thank MRC for the complete manual set (in shrink
wrap with updates) he gave me (and the RP06 I refused to haul away!)
See MRC, its been a few years now and I still didn't auction it all off
on ebay .. so you don't have to kill me with your rubber pellet tommy gun!
I still believe this manual set is the greatest thing anyone has ever
given me!
> Also, I was not until the very moment aware of the existence of
> the song "Teco and DDT". Amazing!! The old lore is not dead.
The band (under a different name) played that live from 1994. A year
later Clive made those 30 years, 36 bits patch which I proudly put on
my guitar strap. AHH, I should also note that we played a variety show
at Club DaDa in Dallas Texas on Sunday 10-DEC-95 at 10PM in which we played
TECO and DDT (to many people's enjoyment/annoyance) in between EVERY
song in our 10 song set. We didn't record the song until 1999 and its
basically the last few lines of Alice's PDP-10 set to an Elvis Costello
style rockabilly form w/ solo.
Whats interesting is that we've had kids tell us they like our 'hacking'
song .. though many of them do not understand what TECO or DDT is.
The album we released that on also contains a song called 'Technology
Gone Bad' which features enjoyable/annoying lines such as:
new microchip.
segmentation faults.
but you line your pockets and you fill your vaults.
cause you don't care, no you don't care.
just spread your virus everywhere.
forget advancements of other machines
KL-10 and LISP machine
The album is out of print, but we have a 7" record still available. However,
it doesn't have the two afore mentioned tracks! I know that the CD is
still available through one online store shop and if I did, I probably have
three or four copies left in my closet. I should note that our music is
probably too noisey for most people's taste .. and probably considered
idealistic or adolescent and unmarketable on the whole.
We've since released a few new recordings (two 7" and a three CDs) with the
2003 CD featuring a song about the DEC Alpha and the SDF public access
UNIX system which includes mostly annoying (and some enjoyable) lines:
IO I know
read & write
much too slow
ion polar mass store
read & write
friticion no more
I owe I know
first thirty six
then sixty four
DEC had RISC
before intel
MS job must feel like hell
SDF
NetBSD
call malloc()
then call a free()
cached my stack
for a rehash
x86 into the trash
DEC had RISC
before intel
PeeCees suck
linux as well
8-Jan-2005 17:44:02 -0800,2537;000000000000
Return-Path: <sra@hactrn.net>
Received: via tmail-2002(14) for t20arc; Sat, 8 Jan 2005 17:44:02 -0800 (PST)
Return-Path: <sra@hactrn.net>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id RAA17190; Sat, 8 Jan 2005 17:44:00 -0800 (PST)
Received: from cyteen.hactrn.net ([66.92.66.68]) by lingling.panda.com with TCP/SMTP; Sat, 8 Jan 2005 17:22:12 -0800 (PST)
Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK))
by cyteen.hactrn.net (Postfix) with ESMTP id 89205499
for <TOPS-20@lingling.panda.com>; Sat, 8 Jan 2005 20:22:11 -0500 (EST)
Received: from thrintun.hactrn.net (localhost [IPv6:::1])
by thrintun.hactrn.net (Postfix) with ESMTP id C25F241E7
for <TOPS-20@lingling.panda.com>; Sat, 8 Jan 2005 20:22:10 -0500 (EST)
Date: Sat, 08 Jan 2005 20:22:10 -0500
From: Rob Austein <sra@hactrn.net>
To: TOPS-20@lingling.panda.com
Subject: Re: 2004, a busy year for the TOPS-20 list!
In-Reply-To: <200501090022.j090MiJd001119@sdf.lonestar.org>
References: <200501081906.j08J6gtI005407@road.fpl>
<200501090022.j090MiJd001119@sdf.lonestar.org>
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20050109012210.C25F241E7@thrintun.hactrn.net>
> > Also, I was not until the very moment aware of the existence of
> > the song "Teco and DDT". Amazing!! The old lore is not dead.
>
> The band (under a different name) played that live from 1994. A year
> later Clive made those 30 years, 36 bits patch which I proudly put on
> my guitar strap. AHH, I should also note that we played a variety show
> at Club DaDa in Dallas Texas on Sunday 10-DEC-95 at 10PM in which we played
> TECO and DDT (to many people's enjoyment/annoyance) in between EVERY
> song in our 10 song set. We didn't record the song until 1999 and its
> basically the last few lines of Alice's PDP-10 set to an Elvis Costello
> style rockabilly form w/ solo.
Yow.
Oddly enough, the saga of Alice's PDP-10 sort of started out with a
band. One of the dorms I lived in back in college ran an ice cream
parlor with a floor show on weekends, and I originally memorized the
story of Alice's Restaurant as part of the act that my hall band put
together to earn ourselves a semester's worth of free ice cream....
9-Jan-2005 12:25:38 -0800,2382;000000000000
Return-Path: <bowman@sunshine.math.utah.edu>
Received: via tmail-2002(14) for t20arc; Sun, 9 Jan 2005 12:25:38 -0800 (PST)
Return-Path: <bowman@sunshine.math.utah.edu>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id MAA17671; Sun, 9 Jan 2005 12:25:37 -0800 (PST)
Received: from sunshine.math.utah.edu ([128.110.198.2]) by lingling.panda.com with TCP/SMTP; Sun, 9 Jan 2005 12:03:35 -0800 (PST)
Received: from tortola.math.utah.edu (IDENT:YSCtiOD2ziCfiQaxhkFuSMqmfEPZ2rzP@tortola.math.utah.edu [155.101.96.48])
by sunshine.math.utah.edu (8.12.11/8.12.10) with ESMTP id j09K3X8R025319;
Sun, 9 Jan 2005 13:03:33 -0700 (MST)
Received: from tortola.math.utah.edu (IDENT:37s6fREgGPiDXnxp1wPzZSYiUQcw9uLM@localhost [127.0.0.1])
by tortola.math.utah.edu (8.12.11/8.12.10) with ESMTP id j09K3XON028243;
Sun, 9 Jan 2005 13:03:33 -0700 (MST)
Received: (from bowman@localhost)
by tortola.math.utah.edu (8.12.11/8.12.10/Submit) id j09K3X9N028242;
Sun, 9 Jan 2005 13:03:33 -0700 (MST)
Date: Sun, 9 Jan 2005 13:03:33 -0700 (MST)
From: Pieter Bowman <bowman@math.utah.edu>
To: TOPS-20@lingling.panda.com
Cc: bowman@math.utah.edu
X-US-Mail: "University of Utah, Department of Mathematics, 155 S 1400 E RM
233, Salt Lake City, UT 84112-0090"
X-Telephone: 801-581-5252
X-Fax: 801-581-4148
Subject: Panda distribution
Message-ID: <CMM.0.92.0.1105301013.bowman@tortola.math.utah.edu>
Recently Nelson Beebe and I have been experimenting with klh10 and the
TOPS-20 distribution from trailing-edge.com, running on a Sun W2100z,
dual AMD Opteron system running Fedora Core 3. I've got the system so
it boots and can be logged in to via telnet, but it's been so long
since I did anything with TOPS-20 (we shut science.utah.edu down on
9-Nov-90). I've seen references to the availability of a Panda
distribution in the form of a disk image. I was wondering if someone
could provide me with this image?
Thanks,
Pieter
Pieter Bowman Voice: 1-801-581-5252
University of Utah FAX: 1-801-581-4148
Department of Mathematics Email: bowman@math.utah.edu
155 S 1400 E RM 233 URL: http://www.math.utah.edu/~bowman
Salt Lake City, Ut, 84112-0090 Office: 103 LCB
9-Jan-2005 23:27:53 -0800,1477;000000000000
Return-Path: <MRC@lingling.panda.com>
Received: via tmail-2002(14) for t20arc; Sun, 9 Jan 2005 23:27:53 -0800 (PST)
Return-Path: <MRC@lingling.panda.com>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id XAA17921; Sun, 9 Jan 2005 23:27:51 -0800 (PST)
Date: Sun, 9 Jan 2005 23:06:57 -0800 (PST)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: Re: Panda distribution
To: bowman@math.utah.edu
cc: TOPS-20@lingling.panda.com
In-Reply-To: <CMM.0.92.0.1105301013.bowman@tortola.math.utah.edu>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <13993324443.9.MRC@lingling.panda.com>
I distribute the Panda distribution, on individual request. It
is not possible to pull the distribution from panda.com (due to
security and other reasons), so typically the requestor gives me
scp access (I need about 200MB free disk space) and I will push
it from here.
I generally prefer that people not redistribute the Panda
distribution, but I do *NOT* prohibit it. The reason for the
preference is my desire that new installations get the newest
bits. But, if you insist, you can get it from a third-party or
redistribute your copy.
My newest laptop computer has a CD-ROM burner, so I will probably
be moving towards a CD-ROM based distribution in the future,
since the Internet transfer takes nearly two hours over a DSL
line. I will probably also start versioning.
-------
19-Jan-2005 09:31:13 -0800,5144;000000000000
Return-Path: <beebe@sunshine.math.utah.edu>
Received: via tmail-2002(14) for t20arc; Wed, 19 Jan 2005 09:31:13 -0800 (PST)
Return-Path: <beebe@sunshine.math.utah.edu>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id JAA26087; Wed, 19 Jan 2005 09:31:11 -0800 (PST)
Received: from sunshine.math.utah.edu ([128.110.198.2]) by lingling.panda.com with TCP/SMTP; Wed, 19 Jan 2005 09:14:18 -0800 (PST)
Received: from psi.math.utah.edu (IDENT:xy86+F66pBGGTyPa6us3icPg59EMuAZP@psi.math.utah.edu [155.101.96.19])
by sunshine.math.utah.edu (8.12.11/8.12.10) with ESMTP id j0JHEGAZ008459;
Wed, 19 Jan 2005 10:14:16 -0700 (MST)
Received: from psi.math.utah.edu (IDENT:y+GXNth5kqHNb8TeeMsQ5P+XDpCPAY+a@localhost [127.0.0.1])
by psi.math.utah.edu (8.12.11/8.12.10) with ESMTP id j0JHEGUp016307;
Wed, 19 Jan 2005 10:14:16 -0700 (MST)
Received: (from beebe@localhost)
by psi.math.utah.edu (8.12.11/8.12.10/Submit) id j0JHEFbV016306;
Wed, 19 Jan 2005 10:14:15 -0700 (MST)
Date: Wed, 19 Jan 2005 10:14:15 -0700 (MST)
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
To: TOPS-20@lingling.panda.com
Cc: beebe@math.utah.edu
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: Underflow handling on TOPS-20: memories, anyone?
Message-ID: <CMM.0.92.0.1106154855.beebe@psi.math.utah.edu>
On TOPS-20 on KLH10, a Fortran program to compute the floating-point
underflow limit behaves as expected:
@type sglufl.for
real x
integer k
k = 0
x = 1.0
10 if (x / 2.0 .gt. 0.0) then
x = x / 2.0
k = k + 1
go to 10
end if
write (6,*) 'Single precision underflow after x = ',x,' = 2**-',k
write (6,'('' x = '', O12)') x
call exit
end
@execute sglufl.for
FORTRAN: SGLUFL
MAIN.
LINK: Loading
[LNKXCT SGLUFL execution]
%Floating underflow at 10P+1 in MAIN. (PC 200)
Single precision underflow after x = 1.4693679E-39 = 2**-129
x = 000400000000
CPU time 0.01 Elapsed time 0.01
[1 Floating underflow]
Pascal also behaves (mostly) properly:
@type sglufl.pas
program sglufl(output);
var x : real;
xold : real;
k : integer;
begin
k := 0;
x := 1.0;
xold := 2.0;
while ((x / 2.0) > 0.0) AND (x < xold) do
begin
xold := x;
x := x / 2.0;
k := k + 1;
end;
writeln('Real underflow after x = ', x:17, ' = 2**-', k);
if x > xold then
begin
writeln('ERROR: underflow wrapped from ', xold:17, ' to ', x:17)
end
end.
@execute sglufl.pas
PASCAL: SGLUFL
LINK: Loading
[LNKXCT SGLUFL execution]
OUTPUT : tty:
? Floating underflow at user PC 400027
[Type CONTINUE to proceed if possible.]
@continue
Real underflow after x = 1.469368E-39 = 2**- 129
The corresponding program in C with kcc-20 goes into an infinite loop,
because the underflow wraps around to a large number, instead of being
set to zero by a software trap handler. I therefore added some code
to check for the wrap, with these results:
@type sglufl.c
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
int
main(void)
{
int k;
float x, xold;
k = 0;
x = 1.0F;
while ((x / 2.0F) > 0.0F)
{
xold = x;
x /= 2.0F;
++k;
if (x > xold) break;
}
printf("Single precision underflow after x = %.10e = 2**(-%d)\n", x, k);
if (x > xold)
printf("ERROR: underflow wrapped from %.10e to %.10e\n", xold, x);
return (EXIT_SUCCESS);
}
@execute sglufl.c
LINK: Loading
[LNKXCT SGLUFL execution]
Single precision underflow after x = 8.5070591730e+37 = 2**(-130)
ERROR: underflow wrapped from 1.4693679385e-39 to 8.5070591730e+37
Does anyone on this list recall how one gets floating-point arithmetic
in C to be handled properly, so that overflow caps at the maximum
representable floating-point number, instead of wrapping to underflow,
and underflow goes to zero instead of wrapping to a large number?
I have a 14-year-old vague memory that there might have been a system
.rel file that could be loaded with the program to fix the problem.
This morning, I got a 35K-line numerical program in C to build in the
36-bit PDP-10 world, but it isn't practical to use it until I can
solve the underflow and overflow problems.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
- 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
20-Jan-2005 07:45:09 -0800,5953;000000000000
Return-Path: <beebe@sunshine.math.utah.edu>
Received: via tmail-2002(14) for t20arc; Thu, 20 Jan 2005 07:45:09 -0800 (PST)
Return-Path: <beebe@sunshine.math.utah.edu>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id HAA26622; Thu, 20 Jan 2005 07:45:08 -0800 (PST)
Received: from sunshine.math.utah.edu ([128.110.198.2]) by lingling.panda.com with TCP/SMTP; Thu, 20 Jan 2005 07:27:15 -0800 (PST)
Received: from psi.math.utah.edu (IDENT:hTQhMRpLzx08lxIYe7hAuPYNKjZ86Wlk@psi.math.utah.edu [155.101.96.19])
by sunshine.math.utah.edu (8.12.11/8.12.10) with ESMTP id j0KFRERw010318;
Thu, 20 Jan 2005 08:27:14 -0700 (MST)
Received: from psi.math.utah.edu (IDENT:wkrhGWk7x9+X3QbYzXv/IoEvralmv1JY@localhost [127.0.0.1])
by psi.math.utah.edu (8.12.11/8.12.10) with ESMTP id j0KDjScp029381;
Thu, 20 Jan 2005 06:45:28 -0700 (MST)
Received: (from beebe@localhost)
by psi.math.utah.edu (8.12.11/8.12.10/Submit) id j0KDjSNg029380;
Thu, 20 Jan 2005 06:45:28 -0700 (MST)
Date: Thu, 20 Jan 2005 06:45:28 -0700 (MST)
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
To: TOPS-20@lingling.panda.com
Cc: beebe@math.utah.edu
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: [TOPS-20] Powers of 2: Fortran vs. C
Message-ID: <CMM.0.92.0.1106228728.beebe@psi.math.utah.edu>
In further work with my numerical program in C on TOPS-20, I found
another problem: severe accuracy loss of about 12 bits (out of 62) in
the C pow() function.
This is illustrated by two short programs, an accurate one in Fortran,
and an unacceptably inaccurate one in C, forcing me to write my own
replacement.
@type tpower.for
double precision x
double precision two
two = 2.0d0
do 10 k = -40, 40, 4
write (6,'(1x,a,i3,a,1pe27.20,a,''0x'',z18.18)')
x '2**', k, ' = ', two**k, ' = ', two**k
10 continue
end
@execute tpower.for
FORTRAN: TPOWER
MAIN.
LINK: Loading
[LNKXCT TPOWER execution]
2**-40 = 9.09494701772928237920E-13 = 0x2CC000000000000000
2**-36 = 1.45519152283668518070E-11 = 0x2EC000000000000000
2**-32 = 2.32830643653869628910E-10 = 0x30C000000000000000
2**-28 = 3.72529029846191406250E-09 = 0x32C000000000000000
2**-24 = 5.96046447753906250000E-08 = 0x34C000000000000000
2**-20 = 9.53674316406250000000E-07 = 0x36C000000000000000
2**-16 = 1.52587890625000000000E-05 = 0x38C000000000000000
2**-12 = 2.44140625000000000000E-04 = 0x3AC000000000000000
2** -8 = 3.90625000000000000000E-03 = 0x3CC000000000000000
2** -4 = 6.25000000000000000000E-02 = 0x3EC000000000000000
2** 0 = 1.00000000000000000000E+00 = 0x40C000000000000000
2** 4 = 1.60000000000000000000E+01 = 0x42C000000000000000
2** 8 = 2.56000000000000000000E+02 = 0x44C000000000000000
2** 12 = 4.09600000000000000000E+03 = 0x46C000000000000000
2** 16 = 6.55360000000000000000E+04 = 0x48C000000000000000
2** 20 = 1.04857600000000000000E+06 = 0x4AC000000000000000
2** 24 = 1.67772160000000000000E+07 = 0x4CC000000000000000
2** 28 = 2.68435456000000000000E+08 = 0x4EC000000000000000
2** 32 = 4.29496729600000000000E+09 = 0x50C000000000000000
2** 36 = 6.87194767360000000000E+10 = 0x52C000000000000000
2** 40 = 1.09951162777600000000E+12 = 0x54C000000000000000
CPU time 0.02 Elapsed time 0.10
@delete tpower.rel
TPOWER.REL.1 [OK]
@type tpower.c
#include <stdio.h>
#include <math.h>
#include <stdlib.h>
int
main(void)
{
int k;
union {double d; int i[2];} u;
for (k = -40; k <= 40; k += 4)
{
u.d = pow(2.0, (double)k);
printf("2**%3d = %.20le = 0x%09x_%09x\n", k, u.d, u.i[0], u.i[1]);
}
return (EXIT_SUCCESS);
}
@execute tpower.c
KCC: TPOWER
<BEEBE>TPOWER.PRE.1
<BEEBE>TPOWER.FAI.1
FAIL: TPOWER
LINK: Loading
[LNKXCT TPOWER execution]
2**-40 = 9.09494701772971442937e-13 = 0x2cc000000_00001abe0
2**-36 = 1.45519152283674739357e-11 = 0x2ec000000_000018113
2**-32 = 2.32830643653878475388e-10 = 0x30c000000_00001563b
2**-28 = 3.72529029846203788706e-09 = 0x32c000000_000012b62
2**-24 = 5.96046447753923226524e-08 = 0x34c000000_00001008a
2**-20 = 9.53674316406272630508e-07 = 0x36c000000_00000d5bd
2**-16 = 1.52587890625002895305e-05 = 0x38c000000_00000aae9
2**-12 = 2.44140625000003471441e-04 = 0x3ac000000_000008012
2** -8 = 3.90625000000003697216e-03 = 0x3cc000000_000005541
2** -4 = 6.25000000000002944346e-02 = 0x3ec000000_000002a6e
2** 0 = 1.00000000000000000000e+00 = 0x40c000000_000000000
2** 4 = 1.59999999999999246349e+01 = 0x427ffffff_7ffffab25
2** 8 = 2.55999999999997576976e+02 = 0x447ffffff_7ffff557e
2** 12 = 4.09599999999994176039e+03 = 0x467ffffff_7fffeffdd
2** 16 = 6.55359999999987564468e+04 = 0x487ffffff_7fffeaa2e
2** 20 = 1.04857599999997511824e+06 = 0x4a7ffffff_7fffe5487
2** 24 = 1.67772159999995221658e+07 = 0x4c7ffffff_7fffdfeed
2** 28 = 2.68435455999991077948e+08 = 0x4e7ffffff_7fffda93c
2** 32 = 4.29496729599983681144e+09 = 0x507ffffff_7fffd538b
2** 36 = 6.87194767359970621299e+10 = 0x527ffffff_7fffcfddb
2** 40 = 1.09951162777594776923e+12 = 0x547ffffff_7fffca841
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
- 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
20-Jan-2005 09:53:51 -0800,1576;000000000000
Return-Path: <billw@cisco.com>
Received: via tmail-2002(14) for t20arc; Thu, 20 Jan 2005 09:53:50 -0800 (PST)
Return-Path: <billw@cisco.com>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id JAA26684; Thu, 20 Jan 2005 09:53:49 -0800 (PST)
Received: from sj-iport-1.cisco.com ([171.71.176.70]) by lingling.panda.com with TCP/SMTP; Thu, 20 Jan 2005 09:35:52 -0800 (PST)
Received: from sj-core-2.cisco.com (171.71.177.254)
by sj-iport-1.cisco.com with ESMTP; 20 Jan 2005 09:42:47 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from cisco.com (cypher.cisco.com [171.69.11.142])
by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0KHZgl2026166;
Thu, 20 Jan 2005 09:35:42 -0800 (PST)
Received: (from billw@localhost)
by cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA06371;
Thu, 20 Jan 2005 09:35:50 -0800 (PST)
Sender: Bill Westfield <billw@cisco.com>
Date: Thu, 20 Jan 2005 9:35:49 PST
From: William "Chops" Westfield <billw@cisco.com>
To: "Nelson H. F. Beebe" <beebe@math.utah.edu>
Cc: TOPS-20@lingling.panda.com, beebe@math.utah.edu
Subject: Re: [TOPS-20] Powers of 2: Fortran vs. C
In-Reply-To: Your message of Thu, 20 Jan 2005 06:45:28 -0700 (MST)
Message-ID: <CMM.0.90.4.1106242549.billw@cypher>
Why don't you re-write the C compiler to (be able to) use the fortran
math libraries? Seems to me that having a single set of math libararies
is a good thing, if only because you only have to fix bugs once after
that! Does this option already exist?
BillW
20-Jan-2005 11:21:12 -0800,2338;000000000000
Return-Path: <sra@hactrn.net>
Received: via tmail-2002(14) for t20arc; Thu, 20 Jan 2005 11:21:12 -0800 (PST)
Return-Path: <sra@hactrn.net>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id LAA26745; Thu, 20 Jan 2005 11:21:11 -0800 (PST)
Received: from cyteen.hactrn.net ([66.92.66.68]) by lingling.panda.com with TCP/SMTP; Thu, 20 Jan 2005 11:03:30 -0800 (PST)
Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK))
by cyteen.hactrn.net (Postfix) with ESMTP id 928C676
for <TOPS-20@lingling.panda.com>; Thu, 20 Jan 2005 14:03:28 -0500 (EST)
Received: from thrintun.hactrn.net (localhost [IPv6:::1])
by thrintun.hactrn.net (Postfix) with ESMTP id 8AA7241E3
for <TOPS-20@lingling.panda.com>; Thu, 20 Jan 2005 14:03:27 -0500 (EST)
Date: Thu, 20 Jan 2005 14:03:27 -0500
From: Rob Austein <sra@hactrn.net>
To: TOPS-20@lingling.panda.com
Subject: Re: [TOPS-20] Powers of 2: Fortran vs. C
In-Reply-To: <CMM.0.90.4.1106242549.billw@cypher>
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20050120190327.8AA7241E3@thrintun.hactrn.net>
At Thu, 20 Jan 2005 9:35:49 PST, William Chops Westfield wrote:
>
> Why don't you re-write the C compiler to (be able to) use the fortran
> math libraries? Seems to me that having a single set of math libararies
> is a good thing, if only because you only have to fix bugs once after
> that! Does this option already exist?
I have a vague recollection that the FORTRAN calling sequence is
incompatable with KCC, Pascal, or any other language that allows
recursion. So, while this would no doubt be doable, it would indeed
either require hacking the compiler or hacking assembly code to wrap
the calling sequence. Be warned that, at least at one point, FOROTS
reserved the right to relocate the stack. The manual included
warnings about storing data on the stack due to this quirk: pointers
to automatic variables would obviously be a problem, but I seem to
recall something close to blanket prohibition on storing anything
other than return addresses.
20-Jan-2005 11:32:13 -0800,881;000000000000
Return-Path: <MRC@lingling.panda.com>
Received: via tmail-2002(14) for t20arc; Thu, 20 Jan 2005 11:32:13 -0800 (PST)
Return-Path: <MRC@lingling.panda.com>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id LAA26751; Thu, 20 Jan 2005 11:32:13 -0800 (PST)
Date: Thu, 20 Jan 2005 11:05:25 -0800 (PST)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: Re: [TOPS-20] Powers of 2: Fortran vs. C
To: beebe@math.utah.edu
cc: TOPS-20@lingling.panda.com
In-Reply-To: <CMM.0.92.0.1106228728.beebe@psi.math.utah.edu>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <13996076676.9.MRC@lingling.panda.com>
For what it's worth, I just tried that C program on a XKL processor and got
identical (bad) results. So it's definitely a problem in the C library and
not in the KLH10 processor.
-------
20-Jan-2005 12:06:38 -0800,966;000000000000
Return-Path: <MRC@lingling.panda.com>
Received: via tmail-2002(14) for t20arc; Thu, 20 Jan 2005 12:06:38 -0800 (PST)
Return-Path: <MRC@lingling.panda.com>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id MAA26789; Thu, 20 Jan 2005 12:06:37 -0800 (PST)
Date: Thu, 20 Jan 2005 11:52:20 -0800 (PST)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: Re: [TOPS-20] Powers of 2: Fortran vs. C
To: beebe@math.utah.edu
cc: TOPS-20@lingling.panda.com
In-Reply-To: <CMM.0.92.0.1106228728.beebe@psi.math.utah.edu>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <13996085219.9.MRC@lingling.panda.com>
I took at look at <KCC-6.LIB.MATH>POW.C and I can't see how the numerical
errors can be avoided given that implementation. In short, it does power
via exp(y*log(x)).
It looks to me that the UNIX C library handles pow() specially when the
exponent is integral.
-------
24-Jan-2005 15:06:27 -0800,4171;000000000000
Return-Path: <beebe@sunshine.math.utah.edu>
Received: via tmail-2002(14) for t20arc; Mon, 24 Jan 2005 15:06:27 -0800 (PST)
Return-Path: <beebe@sunshine.math.utah.edu>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id PAA00738; Mon, 24 Jan 2005 15:06:25 -0800 (PST)
Received: from sunshine.math.utah.edu ([128.110.198.2]) by lingling.panda.com with TCP/SMTP; Mon, 24 Jan 2005 14:47:42 -0800 (PST)
Received: from psi.math.utah.edu (IDENT:kpDS0JA8OYKJJD0HKlf346ylaVuF7lPO@psi.math.utah.edu [155.101.96.19])
by sunshine.math.utah.edu (8.12.11/8.12.10) with ESMTP id j0OMldSd011932;
Mon, 24 Jan 2005 15:47:39 -0700 (MST)
Received: from psi.math.utah.edu (IDENT:BkIc/EllqfP9lylcf0J9ZlqnYVBSHjen@localhost [127.0.0.1])
by psi.math.utah.edu (8.12.11/8.12.10) with ESMTP id j0OMldK3028618;
Mon, 24 Jan 2005 15:47:39 -0700 (MST)
Received: (from beebe@localhost)
by psi.math.utah.edu (8.12.11/8.12.10/Submit) id j0OMldKx028616;
Mon, 24 Jan 2005 15:47:39 -0700 (MST)
Date: Mon, 24 Jan 2005 15:47:39 -0700 (MST)
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
To: TOPS-20@lingling.panda.com
Cc: beebe@math.utah.edu
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: [TOPS-20] A linker surprise, and a workaround
Message-ID: <CMM.0.92.0.1106606859.beebe@psi.math.utah.edu>
After getting the numerical program that I'm working on running under
TOPS-20, after years of development on Unix, I found that the old
PDP-10 single-segment 2**18-word address space was too small for the
data that I want to process.
I looked at the documentation of kcc in "help cc", and found that
extended addressing is available with the -i option:
>> ...
>> <2 KCC Internals - Extended addressing>
>>
>> A C program can be run in an extended section by specifying
>> this in either of two ways at load time, depending on whether you are
>> using KCC or the EXEC to do the loading.
>>
>> (a) KCC: Use the "-i" switch.
>> e.g. @cc -i prog.c
>> or: @cc -i=extend prog.c
>> (b) LOAD (or LINK): The first module should be C:LIBCKX.
>> e.g. @load c:libckx,prog
>>
>> No special switches need be given to KCC for the generated code to be
>> suitable for extended addressing - the same code will always run
>> either extended or non-extended.
>> ...
I then tried
@cc -o foo *.rel
@cc -i -o xfoo *.rel
to build two versions of my program. To my surprise, the
single-segment version worked fine, but the extended-addressing
version behaved differently.
I put this issue aside until early Sunday morning, when a two-window
debugging session with ddt let me tediously step the two programs in
parallel until they diverged. That happened like this:
good foo:
452614/ PUSH 17,3 $x
17/ TLCN 13,247550(10) 3/ SUBXXX
452615/ PUSHJ 17,CODE $x
17/ TLCN 13,247551(11)
<JUMP>
CODE/ PUSH 17,PROGP
bad xfoo:
1,,452605/ PUSH 17,3 $x
17/ 2,,1217 1,,3/ SUBXXX
1,,452606/ PUSHJ 17,$$$CPU $x
17/ 2,,1220
<JUMP>
$$$CPU/ POPJ 17,0
Hmm.... two different target addresses.
foo:
code=420004 $$$cpu=523433
xfoo:
$$$cpu=1,,400000 code=1,,400000
On a hunch that my function name "code" was colliding with a linker
symbol, I recompiled my program with the equivalent of -Dcode=code__,
and relinked with -i: it now works.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
- 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
24-Jan-2005 16:52:54 -0800,13113;000000000000
Return-Path: <beebe@sunshine.math.utah.edu>
Received: via tmail-2002(14) for t20arc; Mon, 24 Jan 2005 16:52:54 -0800 (PST)
Return-Path: <beebe@sunshine.math.utah.edu>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id QAA00776; Mon, 24 Jan 2005 16:52:52 -0800 (PST)
Received: from sunshine.math.utah.edu ([128.110.198.2]) by lingling.panda.com with TCP/SMTP; Mon, 24 Jan 2005 16:35:26 -0800 (PST)
Received: from psi.math.utah.edu (IDENT:LeDJXi0esLLz+0uSlRj8mXFkqamef/wv@psi.math.utah.edu [155.101.96.19])
by sunshine.math.utah.edu (8.12.11/8.12.10) with ESMTP id j0P0ZNhr016383;
Mon, 24 Jan 2005 17:35:23 -0700 (MST)
Received: from psi.math.utah.edu (IDENT:SHFP35TJXbJHq1dhwliDVqxb2npIxcJg@localhost [127.0.0.1])
by psi.math.utah.edu (8.12.11/8.12.10) with ESMTP id j0P0ZN59029039;
Mon, 24 Jan 2005 17:35:23 -0700 (MST)
Received: (from beebe@localhost)
by psi.math.utah.edu (8.12.11/8.12.10/Submit) id j0P0ZNpI029037;
Mon, 24 Jan 2005 17:35:23 -0700 (MST)
Date: Mon, 24 Jan 2005 17:35:23 -0700 (MST)
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
To: TOPS-20@lingling.panda.com
Cc: beebe@math.utah.edu
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: [TOPS-20] News: ELEFUNT elementary function test results for Fortran
and C
Message-ID: <CMM.0.92.0.1106613323.beebe@psi.math.utah.edu>
Many years ago, I began using the ELEFUNT test package for evaluating
the quality of the elementary functions (cos, cosh, exp, log, power,
sin, sinh, sqrt, tan, and tanh) defined in Fortran. The ELEFUNT
package is described in this landmark, but now out-of-print, book:
@String{pub-PH = "Pren{\-}tice-Hall"}
@String{pub-PH:adr = "Upper Saddle River, NJ 07458, USA"}
@Book{Cody:SME80,
author = "William J. {Cody, Jr.} and William Waite",
title = "Software Manual for the Elementary Functions",
publisher = pub-PH,
address = pub-PH:adr,
pages = "x + 269",
year = "1980",
ISBN = "0-13-822064-6",
LCCN = "QA331 .C635 1980",
bibdate = "Tue Dec 14 23:28:38 1993",
}
In the summer of 1987, with a student assistant, we translated the
entire package from Fortran to C. More recently, in late spring 2002,
I translated the package to Java, and also added Fortran and C
versions for testing quadruple-precision versions of the elementary
functions. The Java translation includes a useful standalone Java
class for formatted output, something that is sorely lacking in that
language.
All of the ELEFUNT code, including our extensions, is freely available
at
ftp://ftp.math.utah.edu/pub/elefunt
http://www.math.utah.edu/pub/elefunt/
The ELEFUNT output listings are interesting but lengthy, so several
years ago I wrote a small awk filter to summarize the worst-case
reports from each test, one per line, omitting results that are
`sufficiently accurate' (default: errors of 2 bits or less). This
makes it much easier to scan the cumulative output from many different
systems for the trouble spots.
In my archives, I have some 15-Oct-1981 reports that I wrote about the
ELEFUNT results in Fortran versions 5A and 6 on our DEC-20/60,
although it doesn't record the versions of the Exec or the Monitor.
At the time, the results with Fortran 5A were poor (in some cases, 2/3
of the computed bits were wrong), but they improved a lot with Fortran
version 6. In my 1981 report, I wrote this about the results from the
latter:
>> ...
>> When the accuracy loss figures for V6 are compared with those given by
>> Cody and Waite for the single precision functions tested in at least
>> four environments (usually 2 IBM and 2 CDC), the V6 performance is
>> found to be no worse, and often better than all of the others. The
>> only exception to this is the DTANH function, which loses about 0.6
>> bits more than the worst case reported by Cody and Waite. One other
>> discrepancy was noted in the power operator test; (-2.0)**(2.0)
>> returns 4.0 without an error message. This is a clear violation of
>> the FORTRAN 77 Standard (Section 6.1.4, p. 6-6, line 38).
>> ...
The troublesome results were these, reformatted to show worst-case
relative errors (WRE) and root mean square relative errors (RMS) in
bits in the 62-bit significand of the PDP-10 D-floating format 72-bit
hardware DOUBLE PRECISION arithmetic:
---------------------------------------------------------------------------------------
WRE RMS WRE RMS
--BITS OKAY-- --BITS LOST--
---------------------------------------------------------------------------------------
TEST OF DATAN(X) VS TRUNCATED TAYLOR SERIES -61.08 -999.00 0.92 -937.00
TEST OF DLOG10(X) VS DLOG10(11X/10)-DLOG10(11/10) -59.25 -61.21 2.75 0.79
TEST OF X**1.0 VS X -999.00 -999.00 -937.00 -937.00
TEST OF DSQRT(X*X) - X -999.00 -999.00 -937.00 -937.00
TEST OF DTAN(X) VS 2*DTAN(X/2)/(1-DTAN(X/2)**2) -59.61 -61.31 2.39 0.69
TEST OF DTAN(X) VS 2*DTAN(X/2)/(1-DTAN(X/2)**2) -59.71 -61.30 2.29 0.70
---------------------------------------------------------------------------------------
The -999 results indicate test failures where unexpected overflow
caused problems.
Well, 23 years have gone by, and now we have a much newer TOPS-20
Fortran:
@get sys:fortra
@information (about) version
Panda Distribution, PANDA TOPS-20 Monitor 7.1(21733)-4
PANDA TOPS-20 Command processor 7.1(4453)-4
Program is FORTRA, version is 11(4561)
Here are the worst case results for it, computed two days ago:
-------------------------------------------------------------------------------------------------
BITS OKAY BITS LOST
WRE RMS WRE RMS
-------------------------------------------------------------------------------------------------
TEST OF DLOG10(X) VS DLOG10(11X/10)-DLOG10(11/10) 59.25 61.21 2.75 0.79
TEST OF DCOSH(X) VS C*(DCOSH(X+1)+DCOSH(X-1)) 59.99 61.77 2.01 0.23
TEST OF DTAN(X) VS 2*DTAN(X/2)/(1-DTAN(X/2)**2) 59.53 61.37 2.47 0.63
TEST OF DTAN(X) VS 2*DTAN(X/2)/(1-DTAN(X/2)**2) 59.99 61.84 2.01 0.16
TEST OF DTAN(X) VS 2*DTAN(X/2)/(1-DTAN(X/2)**2) 59.65 61.34 2.35 0.66
TEST OF DCOT(X) VS (DCOT(X/2)**2-1)/(2*DCOT(X/2)) 59.84 61.73 2.16 0.27
TEST OF DCOT(X) VS (DCOT(X/2)**2-1)/(2*DCOT(X/2)) 59.84 62.00 2.16 0.00
-------------------------------------------------------------------------------------------------
These results are really very good: it is very hard to do better
without resorting to higher-precision computation. That would have
been relatively costly on 1980s hardware running at under 1 Mflop/s,
since it would have needed a complete quadruple-precision software
package. In 50+ years of electronic computers, the only systems to
provide hardware quadruple-precision floating-point arithmetic have
been IBM mainframes in the System/360 family.
With the KCC-6 C math library in 2005, however, the picture is
decidedly not as rosy:
-------------------------------------------------------------------------------------------------
BITS OKAY BITS LOST
WRE RMS WRE RMS
-------------------------------------------------------------------------------------------------
TEST OF ALOG(X) VS T.S. EXPANSION OF ALOG(1+Y) 58.53 59.05 3.47 2.95
TEST OF ALOG(X) VS ALOG(17X/16)-ALOG(17/16) 48.75 50.15 13.25 11.85
TEST OF ALOG10(X) VS ALOG10(11X/10)-ALOG10(11/10) 48.38 49.82 13.62 12.18
TEST OF ALOG(X*X) VS 2 * LOG(X) 52.06 53.94 9.94 8.06
TEST OF ASIN(X) VS TAYLOR SERIES 17.78 21.46 44.22 40.54
TEST OF ACOS(X) VS TAYLOR SERIES 26.42 30.34 35.58 31.66
TEST OF ASIN(X) VS TAYLOR SERIES 25.96 30.11 36.04 31.89
TEST OF ACOS(X) VS TAYLOR SERIES 24.86 28.96 37.14 33.04
TEST OF ACOS(X) VS TAYLOR SERIES 27.24 31.48 34.76 30.52
TEST OF ATAN(X) VS TRUNCATED TAYLOR SERIES 17.71 20.92 44.29 41.08
TEST OF ATAN(X) VS ATAN(1/16) + ATAN((X-1/16)/(1+X/16)) 21.88 26.06 40.12 35.94
TEST OF 2*ATAN(X) VS ATAN(2X/(1-X*X)) 24.90 29.20 37.10 32.80
TEST OF 2*ATAN(X) VS ATAN(2X/(1-X*X)) 24.84 28.92 37.16 33.08
TEST OF EXP(X- 0.0625) VS EXP(X)/EXP( 0.0625) 53.31 54.08 8.69 7.92
TEST OF EXP(X- 2.8125) VS EXP(X)/EXP( 2.8125) 53.34 55.14 8.66 6.86
TEST OF EXP(X- 2.8125) VS EXP(X)/EXP( 2.8125) 53.33 55.19 8.67 6.81
TEST OF X**1.0 VS X 49.54 51.42 12.46 10.58
TEST OF XSQ**1.5 VS XSQ*X 48.98 50.75 13.02 11.25
TEST OF XSQ**1.5 VS XSQ*X 5.05 9.15 56.95 52.85
TEST OF X**Y VS XSQ**(Y/2) 46.37 48.22 15.63 13.78
TEST OF SIN(X) VS 3*SIN(X/3)-4*SIN(X/3)**3 53.72 54.76 8.28 7.24
TEST OF SIN(X) VS 3*SIN(X/3)-4*SIN(X/3)**3 47.36 52.70 14.64 9.30
TEST OF COS(X) VS 4*COS(X/3)**3-3*COS(X/3) 47.63 52.71 14.37 9.29
TEST OF SINH(X) VS T.S. EXPANSION OF SINH(X) 46.92 49.83 15.08 12.17
TEST OF COSH(X) VS T.S. EXPANSION OF COSH(X) 55.44 56.70 6.56 5.30
TEST OF SINH(X) VS C*(SINH(X+1)+SINH(X-1)) 53.39 55.30 8.61 6.70
TEST OF COSH(X) VS C*(COSH(X+1)+COSH(X-1)) 0.16 5.65 61.84 56.35
TEST OF TAN(X) VS 2*TAN(X/2)/(1-TAN(X/2)**2) 52.60 53.69 9.40 8.31
TEST OF TAN(X) VS 2*TAN(X/2)/(1-TAN(X/2)**2) 47.69 52.55 14.31 9.45
TEST OF TAN(X) VS 2*TAN(X/2)/(1-TAN(X/2)**2) 43.51 48.99 18.49 13.01
TEST OF COT(X) VS (COT(X/2)**2-1)/(2*COT(X/2)) 46.33 51.65 15.67 10.35
TEST OF COT(X) VS (COT(X/2)**2-1)/(2*COT(X/2)) 46.33 54.87 15.67 7.13
TEST OF TANH(X) VS (TANH(X-1/8)+TANH(1/8))/(1+TANH(X-1/8)TANH(1/8)) 50.87 52.98 11.13 9.02
TEST OF TANH(X) VS (TANH(X-1/8)+TANH(1/8))/(1+TANH(X-1/8)TANH(1/8)) 45.19 49.10 16.81 12.90
-------------------------------------------------------------------------------------------------
These results do not show additional test failures that arise because
of the wraparound from overflow to underflow that I reported on this
list a few days ago.
It has already been observed on this list that interlanguage calling
was in general not possible on TOPS-20, because of different
argument-passing conventions, because the Fortran run-time library can
unpredictably move the stack, invalidating absolute pointers into it,
and because run-time error messages do not use the same I/O library
and file conventions. Thus, it is unlikely to be feasible to replace
the deficient C math library with wrappers that call the Fortran
library instead.
I might return to the problem of providing a better math library for
kcc-20, but for now, the ELEFUNT tests identify the math library
weaknesses for C programmers.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
- 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
24-Jan-2005 17:03:07 -0800,2773;000000000000
Return-Path: <beebe@sunshine.math.utah.edu>
Received: via tmail-2002(14) for t20arc; Mon, 24 Jan 2005 17:03:07 -0800 (PST)
Return-Path: <beebe@sunshine.math.utah.edu>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id RAA00793; Mon, 24 Jan 2005 17:03:06 -0800 (PST)
Received: from sunshine.math.utah.edu ([128.110.198.2]) by lingling.panda.com with TCP/SMTP; Mon, 24 Jan 2005 16:44:36 -0800 (PST)
Received: from psi.math.utah.edu (IDENT:KgvMCBRdCPjq+Dpkx80TnPLfJPjX9kSE@psi.math.utah.edu [155.101.96.19])
by sunshine.math.utah.edu (8.12.11/8.12.10) with ESMTP id j0P0iYf8016681;
Mon, 24 Jan 2005 17:44:35 -0700 (MST)
Received: from psi.math.utah.edu (IDENT:4lIfdXg4ogFAdKLMACiGvui0wBNCyhmi@localhost [127.0.0.1])
by psi.math.utah.edu (8.12.11/8.12.10) with ESMTP id j0P0iYB3029139;
Mon, 24 Jan 2005 17:44:34 -0700 (MST)
Received: (from beebe@localhost)
by psi.math.utah.edu (8.12.11/8.12.10/Submit) id j0P0iYcd029137;
Mon, 24 Jan 2005 17:44:34 -0700 (MST)
Date: Mon, 24 Jan 2005 17:44:34 -0700 (MST)
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
To: TOPS-20@lingling.panda.com
Cc: beebe@math.utah.edu
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: [TOPS-20] Does "set address-break" work on TOPS-20 with KLH10?
Message-ID: <CMM.0.92.0.1106613874.beebe@psi.math.utah.edu>
One of the great debugging features of TOPS-20 that I used to employ a
lot was the EXEC set address-break instruction:
@get prog
@set addRESS-BREAK (AT) main ,
@@? confirm with carriage return
or one of the following:
AFTER ALL EXECUTE NONE READ WRITE
@@...
My experiments this past week suggest that, while I can set the break
at the EXEC level, the break is never taken: I've tried read, write,
and execute.
I can understand that this might have required some sort of special
microcoded hardware assist on our DEC-20/40 and 20/60 systems. Is it
known not to work with the KLH10 machine?
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
- 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
24-Jan-2005 17:13:16 -0800,3500;000000000000
Return-Path: <beebe@sunshine.math.utah.edu>
Received: via tmail-2002(14) for t20arc; Mon, 24 Jan 2005 17:13:16 -0800 (PST)
Return-Path: <beebe@sunshine.math.utah.edu>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id RAA00801; Mon, 24 Jan 2005 17:13:14 -0800 (PST)
Received: from sunshine.math.utah.edu ([128.110.198.2]) by lingling.panda.com with TCP/SMTP; Mon, 24 Jan 2005 16:51:47 -0800 (PST)
Received: from psi.math.utah.edu (IDENT:lPck0Bmq3jPVv2Nkx+z/ZGBK2uf4w7n7@psi.math.utah.edu [155.101.96.19])
by sunshine.math.utah.edu (8.12.11/8.12.10) with ESMTP id j0P0pcoV017033;
Mon, 24 Jan 2005 17:51:38 -0700 (MST)
Received: from psi.math.utah.edu (IDENT:CWcW17qUnztpWZmm12Mm4W6LJ8HOZYWC@localhost [127.0.0.1])
by psi.math.utah.edu (8.12.11/8.12.10) with ESMTP id j0P0pcXi029172;
Mon, 24 Jan 2005 17:51:38 -0700 (MST)
Received: (from beebe@localhost)
by psi.math.utah.edu (8.12.11/8.12.10/Submit) id j0P0pbEY029171;
Mon, 24 Jan 2005 17:51:37 -0700 (MST)
Date: Mon, 24 Jan 2005 17:51:37 -0700 (MST)
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
To: TOPS-20@lingling.panda.com
Cc: beebe@math.utah.edu
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: [TOPS-20] Command-line history and editing?
Message-ID: <CMM.0.92.0.1106614297.beebe@psi.math.utah.edu>
After 20+ years of using Unix shells with command history and command
editing, I'm finding it painful not to have it on TOPS-20. Some
experiments suggest that it might/should be there:
@dir hlp:exec*
TOPS20:<HELP>
EXEC-ALTER-KEYS.HLP.1
EXEC-COMMAND-EDITOR.HLP.1
EXEC-EMACS-KEYS.HLP.1
EXEC-SED-KEYS.HLP.1
EXEC-VMS-KEYS.HLP.1
Total of 5 pages in 5 files
@set history 25
@set edit hiSTORY 25
@set edit modE (TO) emaCS-STYLE-COMMANDS
...
@i history
History: 25
[1] set edit modE (TO) emaCS-STYLE-COMMANDS
[2] type hlp:EXEC-EMACS-KEYS.HLP
[3] i term
The help file says:
@type hlp:EXEC-EMACS-KEYS.HLP
This is the Emacs mode command editor.
<cr> Execute edited command ^N Edit the next command line
^P Edit previous command line ^F Move forward one character
^B Move back one character ^L Redisplay the command line
^E Move to end of the line ^A Move to beginning of the line
^D Delete character at cursor ^K Delete to end of line
^Y Yank text from kill buffer ^V Quote the next character for insert
^T Swap the character at the cursor with the one before it
...
However, Ctl-P doesn't recall the last command in my vt100-mode
terminal windows.
Am I doing something wrong, or is command-line editing a TOPS-20
feature that was never completed?
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
- 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
24-Jan-2005 20:31:55 -0800,2232;000000000000
Return-Path: <MRC@CAC.Washington.EDU>
Received: via tmail-2002(14) for t20arc; Mon, 24 Jan 2005 20:31:54 -0800 (PST)
Return-Path: <MRC@CAC.Washington.EDU>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id UAA00892; Mon, 24 Jan 2005 20:31:53 -0800 (PST)
Received: from mxout2.cac.washington.edu ([140.142.33.4]) by lingling.panda.com with TCP/SMTP; Mon, 24 Jan 2005 20:17:08 -0800 (PST)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
by mxout2.cac.washington.edu (8.13.1+UW04.08/8.13.3+UW05.01) with ESMTP id j0P4H7Zi005114;
Mon, 24 Jan 2005 20:17:07 -0800
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
(authenticated bits=0)
by smtp.washington.edu (8.13.1+UW04.08/8.13.3+UW05.01) with ESMTP id j0P4H77M023609
(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
Mon, 24 Jan 2005 20:17:07 -0800
Date: Mon, 24 Jan 2005 20:17:09 -0800 (Pacific Standard Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: "Nelson H. F. Beebe" <beebe@math.utah.edu>
cc: TOPS-20@lingling.panda.com
Subject: Re: [TOPS-20] News: ELEFUNT elementary function test results for
Fortran and C
In-Reply-To: <CMM.0.92.0.1106613323.beebe@psi.math.utah.edu>
Message-ID: <Pine.WNT.4.62.0501242006430.4012@Tomobiki-Cho.CAC.Washington.EDU>
References: <CMM.0.92.0.1106613323.beebe@psi.math.utah.edu>
Organization: Networks & Distributed Computing
Sender: mrc@lingling.panda.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Mon, 24 Jan 2005, Nelson H. F. Beebe wrote:
> I might return to the problem of providing a better math library for
> kcc-20, but for now, the ELEFUNT tests identify the math library
> weaknesses for C programmers.
Looking briefly at the math library sources for the C library, it seems to
me that they were written to get them done, and not to be particularly
accurate or high-performing. So I suspect that you can get quite a bit of
results with relatively modest work.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
24-Jan-2005 20:43:43 -0800,2093;000000000000
Return-Path: <MRC@CAC.Washington.EDU>
Received: via tmail-2002(14) for t20arc; Mon, 24 Jan 2005 20:43:43 -0800 (PST)
Return-Path: <MRC@CAC.Washington.EDU>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id UAA00911; Mon, 24 Jan 2005 20:43:40 -0800 (PST)
Received: from mxout3.cac.washington.edu ([140.142.32.166]) by lingling.panda.com with TCP/SMTP; Mon, 24 Jan 2005 20:20:40 -0800 (PST)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
by mxout3.cac.washington.edu (8.13.1+UW04.08/8.13.3+UW05.01) with ESMTP id j0P4KdvG011715;
Mon, 24 Jan 2005 20:20:40 -0800
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
(authenticated bits=0)
by smtp.washington.edu (8.13.1+UW04.08/8.13.3+UW05.01) with ESMTP id j0P4KdpC023750
(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
Mon, 24 Jan 2005 20:20:39 -0800
Date: Mon, 24 Jan 2005 20:20:41 -0800 (Pacific Standard Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: "Nelson H. F. Beebe" <beebe@math.utah.edu>
cc: TOPS-20@lingling.panda.com
Subject: Re: [TOPS-20] Does "set address-break" work on TOPS-20 with KLH10?
In-Reply-To: <CMM.0.92.0.1106613874.beebe@psi.math.utah.edu>
Message-ID: <Pine.WNT.4.62.0501242017170.4012@Tomobiki-Cho.CAC.Washington.EDU>
References: <CMM.0.92.0.1106613874.beebe@psi.math.utah.edu>
Organization: Networks & Distributed Computing
Sender: mrc@lingling.panda.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Mon, 24 Jan 2005, Nelson H. F. Beebe wrote:
> One of the great debugging features of TOPS-20 that I used to employ a
> lot was the EXEC set address-break instruction
Address break is not implemented on the KLH10 processor. Ken believes
that it would be very slow if implemented.
Read klh10-2.0g/docs/backgrnd.txt for more information.
I miss it too.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
24-Jan-2005 20:54:29 -0800,2052;000000000000
Return-Path: <MRC@CAC.Washington.EDU>
Received: via tmail-2002(14) for t20arc; Mon, 24 Jan 2005 20:54:29 -0800 (PST)
Return-Path: <MRC@CAC.Washington.EDU>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id UAA00917; Mon, 24 Jan 2005 20:54:29 -0800 (PST)
Received: from mxout6.cac.washington.edu ([140.142.33.20]) by lingling.panda.com with TCP/SMTP; Mon, 24 Jan 2005 20:22:10 -0800 (PST)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
by mxout6.cac.washington.edu (8.13.1+UW04.08/8.13.3+UW05.01) with ESMTP id j0P4M99X027392;
Mon, 24 Jan 2005 20:22:10 -0800
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
(authenticated bits=0)
by smtp.washington.edu (8.13.1+UW04.08/8.13.3+UW05.01) with ESMTP id j0P4M9le023822
(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
Mon, 24 Jan 2005 20:22:09 -0800
Date: Mon, 24 Jan 2005 20:22:11 -0800 (Pacific Standard Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: "Nelson H. F. Beebe" <beebe@math.utah.edu>
cc: TOPS-20@lingling.panda.com
Subject: Re: [TOPS-20] Command-line history and editing?
In-Reply-To: <CMM.0.92.0.1106614297.beebe@psi.math.utah.edu>
Message-ID: <Pine.WNT.4.62.0501242020500.4012@Tomobiki-Cho.CAC.Washington.EDU>
References: <CMM.0.92.0.1106614297.beebe@psi.math.utah.edu>
Organization: Networks & Distributed Computing
Sender: mrc@lingling.panda.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Mon, 24 Jan 2005, Nelson H. F. Beebe wrote:
> However, Ctl-P doesn't recall the last command in my vt100-mode
> terminal windows.
You have to set the edit interrupt-character to enable the command editor,
and type that character to get into it.
I use:
SET EDIT INTERRUPT-CHARACTER ^X
SET EDIT MODE EMACS
SET EDIT HISTORY 20
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
25-Jan-2005 12:17:14 -0800,7473;000000000000
Return-Path: <slogin@optonline.net>
Received: via tmail-2002(14) for t20arc; Tue, 25 Jan 2005 12:17:13 -0800 (PST)
Return-Path: <slogin@optonline.net>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id MAA01329; Tue, 25 Jan 2005 12:17:12 -0800 (PST)
From: slogin@optonline.net
Received: from mta6.srv.hcvlny.cv.net ([167.206.5.72]) by lingling.panda.com with TCP/SMTP; Tue, 25 Jan 2005 12:00:12 -0800 (PST)
Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta6.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004))
with ESMTP id <0IAW00KCR25D7T@mta6.srv.hcvlny.cv.net> for
TOPS-20@lingling.panda.com; Tue, 25 Jan 2005 14:58:26 -0500 (EST)
Received: from [167.206.5.45] (Forwarded-For: [66.114.69.214])
by mstr3.srv.hcvlny.cv.net (mshttpd); Tue, 25 Jan 2005 14:58:25 -0500
Date: Tue, 25 Jan 2005 14:58:25 -0500
Subject: Re: [TOPS-20] Powers of 2: Fortran vs. C
To: sra@hactrn.net
Cc: TOPS-20@lingling.panda.com, beebe@math.utah.edu, billw@cisco.com
Message-id: <e91920e91215.e91215e91920@optonline.net>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
Funny, you should mention this, I was actually looking at the source
code to the Algol Run Time System (ALGOTS) a few months ago. I had
re-discovered a short analysis that one of my WPI computer science
instructors (Stephan R. Alpert) had done around 1976 (?), entitled:
"Everything you ever wanted to know about ALGOTS but was afraid to
ask". At the time, I was an undergraduate and WAS afraid to ask,
particularly about the analysis paper itself as I hadn't understood
that, either. After some review, I believe that I might know
something more about ALGOTS now; I suppose that's some sort of
progress in 25 years ...
Algol can call Fortran subroutines and (of course) assembler. I
believe that one area of concern would be what the Fortran subroutines
are doing. If they tried to invoke an intrinsic routine that wanted
FOROTS around, then perhaps you might get an address space conflict as
both ALGOTS and FOROTS want to inhabit the same 'high segment'. This
could also be a problem with C as it appears to want stuff up in the
'high segment' (i.e., page 400). I think you would want to avoid this
problem by linking the FORTRAN support routines directly in via
FORLIB.
Further research on FOROTS shows that it can call COBOL and Macro
subroutines. It is specifically set up to allow itself to be used as
an independent I/O subsystem for Macro programs. The calling
sequences are all documented. So, you'd need to write (what appears
to be) a small amount of C-to-Fortran assembler linkage or perhaps see
if the COBOL interfaces were more servicable. One area that would
need to be handled would be routines with variable number of
arguments.
Some of this stuff might get hairy. If FOROTS wants to mangle the
stack, then you'd have to set up a seperate stack for it to play with.
However, I would be surprised if you could call FOROTS recursively.
In fact, I'm not sure that this could happen. I believe that in order
for a recursive call to FOROTS to happen, FOROTS itself must call
itself. I don't believe it does this. In other words, once FOROTS is
activatived by a library call, it completes and then returns to the
caller.
The only way recursion could happen would be indirectly by the use of
co-routines where FOROTS then invoked an external routine in the
course of its actions. If that external routine then went recursive
or invoked FOROTS, then the results could be 'interesting'. But, I
don't believe that FOROTS does this. I don't remember that it
supports this, either.
Off the top of my head, I believe that there may be only two ways to
get FOROTS to be re-entered while it is doing its thing. The first
would be to break out of the library call with the PSI. If you then
did something that (in)directly invoked FOROTS during the interrupt
processing, then you could get into trouble. In other words, if you
are inside of FOROTS, take an interrupt, have the interrupt routine
written in C which then invokes FOROTS, you could wind up having
problems.
Another issue would be unwinding the stack and clearing any created
frames. If you changed the return address out of FOROTS before you
did the DEBRK%, then it's likely that you'd have some work to do to
put the stack back together and clean up any temporary FOROTS areas.
That sounds hard. I guess you'd probably want to DEBRK% back into
FOROTS and then check for an interrupt when you returned.
The second way to have some sort of a concurrent reentrant call would
be to have a multi-forking C program which was trying to share a
single copy of FOROTS. Either you'd have to have each fork have it's
own seperate 'hiseg' and have the 'loseg' data areas be private, or
you'd need to enforce serial usage of FOROTS (possibly with ENQ/DEQ).
Or, you could link in FORLIB (which I don't know a lot about).
In summary, in order to call Fortran mathematical routines from C, I
think you'd need at least some of the following:
1) Properly convert calling sequences and preserve the register file.
At least for ALGOL, COBOL and FORTRAN, these sequences are well
documented. I couldn't say about C.
2) Verify that the FOROTS mathematical routines are either fully
reentrant or can NOT go recursive (i.e., don't call themselves)
3) Make sure that you aren't doing anything with co-routines, PSI or
forks that could involve concurrent library usage, or code to
force serial usage.
4) Verify that either FOROTS is not needed or that you can directly
link in the routines that you need. I think what you'd would be
to link in FORLIB.
5) Verify that you do have subroutine name conflict. If that were
the case, then you'd need to do some creative stuff with #define
and then maybe play around with some symbol editing in LINK.
Well, *I* think it sounds like fun ...
> ----- Original Message -----
> From: Rob Austein <sra@hactrn.net>
> Date: Thursday, January 20, 2005 2:03 pm
> Subject: Re: [TOPS-20] Powers of 2: Fortran vs. C
>
> I have a vague recollection that the FORTRAN calling sequence is
> incompatable with KCC, Pascal, or any other language that allows
> recursion. So, while this would no doubt be doable, it would indeed
> either require hacking the compiler or hacking assembly code to wrap
> the calling sequence.
>
> Be warned that, at least at one point, FOROTS reserved the right to
> relocate the stack. The manual included warnings about storing data
> on the stack due to this quirk: pointers to automatic variables
> would obviously be a problem, but I seem to recall something close
> to blanket prohibition on storing anything other than return
> addresses.
>
> > At Thu, 20 Jan 2005 9:35:49 PST, William Chops Westfield wrote:
> >
> > Why don't you re-write the C compiler to (be able to) use the
> > Fortran math libraries? Seems to me that having a single set of
> > math libararies is a good thing, if only because you only have to
> > fix bugs once after that! Does this option already exist?
26-Jan-2005 06:53:03 -0800,5521;000000000000
Return-Path: <beebe@sunshine.math.utah.edu>
Received: via tmail-2002(14) for t20arc; Wed, 26 Jan 2005 06:53:02 -0800 (PST)
Return-Path: <beebe@sunshine.math.utah.edu>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id GAA01820; Wed, 26 Jan 2005 06:53:01 -0800 (PST)
Received: from sunshine.math.utah.edu ([128.110.198.2]) by lingling.panda.com with TCP/SMTP; Wed, 26 Jan 2005 06:20:28 -0800 (PST)
Received: from psi.math.utah.edu (IDENT:+w7kMBcbh8FJw1rxYUxTt+l3IAM3RXuL@psi.math.utah.edu [155.101.96.19])
by sunshine.math.utah.edu (8.12.11/8.12.10) with ESMTP id j0QEKQCL011715;
Wed, 26 Jan 2005 07:20:26 -0700 (MST)
Received: from psi.math.utah.edu (IDENT:HmiU5lMbPmG8XqJan6ymsaI+j0V/prIu@localhost [127.0.0.1])
by psi.math.utah.edu (8.12.11/8.12.10) with ESMTP id j0QEKP2v027230;
Wed, 26 Jan 2005 07:20:25 -0700 (MST)
Received: (from beebe@localhost)
by psi.math.utah.edu (8.12.11/8.12.10/Submit) id j0QEKPmG027228;
Wed, 26 Jan 2005 07:20:25 -0700 (MST)
Date: Wed, 26 Jan 2005 07:20:25 -0700 (MST)
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
To: TOPS-20@lingling.panda.com
Cc: beebe@math.utah.edu
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: [TOPS-20] kcc-20 code generation error
Message-ID: <CMM.0.92.0.1106749225.beebe@psi.math.utah.edu>
Two versions of my numerical program in C, one in float and the other
in double, gave different results in a critical function.
I've now been able to determine that the cause is missing instructions
to initialize a variable, and have been able to reproduce it with a
simple test file shown below: its assembly code for the critical two
statements is identical to that in my numerical program.
The IEEE 754 function Nextafter(x,y) should return the next
floating-point number closest to x, but different from it, in the
direction of y. For example, in single precision, Nextafter(1.0F,
2.0F) should return 1.000000015 (hexadecimal 40c000001, octal
201400000001) on the PDP-10, and does so.
In double precision, however, Nextafter(1.0, 2.0) erroneously returned
instead 1.7014118346046923175e+38 (hexadecimal 7ffffffff_7ffffffff,
octal 377777777777_377777777777), the largest representable
floating-point number.
I reduced the code in Nextafter() to just the fragment for which the
compiler-generated code is wrong. The test program should return -1,
but instead produces:
@ex bug001.c
KCC: BUG001
<BEEBE.HOC72>BUG001.PRE.13
<BEEBE.HOC72>BUG001.FAI.1
FAIL: BUG001
LINK: Loading
[LNKXCT BUG001 execution]
Nextafter(1,2) = 1.7014118346046923175e+38
Here is the test program:
@type bug001.c
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <float.h>
double
Infinity(void)
{
return (DBL_MAX);
}
double
MaxNormal(void)
{
return (DBL_MAX);
}
double
Nextafter(double x, double y)
{ /* NB: fragmentary implementation to illustrate kcc-20 code generation error */
if ((x == MaxNormal()) && (x < y))
return (Infinity());
else
return (-1.0);
}
int
main(void)
{
double x, y;
x = 1.0;
y = 2.0;
asm("dmove 4,.dblma\n");
printf("Nextafter(%g,%g) = %.20g\n", x, y, Nextafter(x,y));
return (EXIT_SUCCESS);
}
Here is the generated code, with C-like annotations:
NEXTAF:
PUSH 17,-2(17) # push hi(x)
PUSH 17,-2(17) # push lo(x)
PUSHJ 17,MAXNOR # call MaxNormal(): result returned in registers 1 and 2
POP 17,3 # get lo(x) from stack
CAMN 3,2 # lo(x) != lo(MaxNormal()) ? skip : don't skip
DMOVE 4,0(17) # ???
ADJSP 17,-1 # readjust stack
# Bug at the next instruction: register 4 was never initialized, and does not
# contain the expected hi(x). It happens to contain fortuitous garbage.
CAME 4,1 # hi(x) == hi(MaxNormal()) ? skip : don't skip
JRST $2 # continue to next branch of if statement
DMOVE 6,-2(17) # load x into (R6,R7)
DMOVE 10,-4(17) # load y into (R10,R11)
CAMG 6,10 # hi(x) > hi(y) ? skip : don't skip
CAML 7,11 # lo(x) > lo(y) ? skip : don't skip
CAMGE 6,10 # hi(x) >= hi(y) ? skip : don't skip
JRST INFINI # call Infinity() and return from there
$2==.
DMOVE 1,[-201400000000
0] ; -1
POPJ 17,
I now have to figure out a way to program around the code-generation
error.
The question is, has anyone on this list been inside the kcc code
generator and might know how to fix the bug? Does anyone maintain
kcc? The <KCC-6.KCC> directory file dates are from 1986 to 1996, and
files are owned by HELLIWELL. Ken Harrenstien's KLH10 code dates end
in 2002.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
- 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
27-Jan-2005 13:33:12 -0800,4970;000000000000
Return-Path: <beebe@sunshine.math.utah.edu>
Received: via tmail-2002(14) for t20arc; Thu, 27 Jan 2005 13:33:12 -0800 (PST)
Return-Path: <beebe@sunshine.math.utah.edu>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id NAA02551; Thu, 27 Jan 2005 13:33:11 -0800 (PST)
Received: from sunshine.math.utah.edu ([128.110.198.2]) by lingling.panda.com with TCP/SMTP; Thu, 27 Jan 2005 13:15:41 -0800 (PST)
Received: from psi.math.utah.edu (IDENT:K3RbHJMa6cMn77DeiTF9ePG+FYp82Gd3@psi.math.utah.edu [155.101.96.19])
by sunshine.math.utah.edu (8.12.11/8.12.10) with ESMTP id j0RLFdwr002204;
Thu, 27 Jan 2005 14:15:39 -0700 (MST)
Received: from psi.math.utah.edu (IDENT:liUj5BE45RXwjz0mLQ4c/UgoK5DMdapM@localhost [127.0.0.1])
by psi.math.utah.edu (8.12.11/8.12.10) with ESMTP id j0RLFdeN013675;
Thu, 27 Jan 2005 14:15:39 -0700 (MST)
Received: (from beebe@localhost)
by psi.math.utah.edu (8.12.11/8.12.10/Submit) id j0RLFbHO013673;
Thu, 27 Jan 2005 14:15:37 -0700 (MST)
Date: Thu, 27 Jan 2005 14:15:37 -0700 (MST)
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
To: TOPS-20@lingling.panda.com
Cc: beebe@math.utah.edu
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: [TOPS-20] kcc-20 constant conversion error
Message-ID: <CMM.0.92.0.1106860537.beebe@psi.math.utah.edu>
I have started on a modest-sized project to implement the Cody/Waite
algorithms for the elementary functions in a portable implementation
that can be used not only on TOPS-20 to fix the kcc-20 math library
deficiencies that I recently reported on this list, but also on any
other system where I run into similar problems.
There are just too many system dependencies in trying to solve the
problem on TOPS-20 by calling Fortran from C, and that wouldn't help
on other platforms anyway.
The first routines that I have implemented are exp() and expf(), and
they pass the ELEFUNT tests on several different Unix architectures.
When I ran them on TOPS-20, I got results that were accurate for
small arguments, and then progressively worsened for larger-magnitude
arguments. A printf() at a suitable place in the code exposed the
error: nonsensical conversion of precise floating-point constants.
The bug can be reproduced in this simple program:
@type ctest.c
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
void
dump(double x)
{
printf("%.20g\n", x);
}
int
main(int argc, char* argv[])
{
dump(1.4426950408889634073599246810018921374266459541530);
dump(1.442695040888963407359924681001892137426645954153);
dump(1.44269504088896340735992468100189213742664595415);
dump(1.4426950408889634073599246810018921374266459541);
dump(1.442695040888963407359924681001892137426645954);
dump(1.44269504088896340735992468100189213742664595);
dump(1.4426950408889634073599246810018921374266459);
dump(1.442695040888963407359924681001892137426645);
dump(1.44269504088896340735992468100189213742664);
dump(1.4426950408889634073599246810018921374266);
dump(1.442695040888963407359924681001892137426);
dump(1.44269504088896340735992468100);
dump(1.4426950408889634073);
dump(1.442695040);
return (EXIT_SUCCESS);
}
@execute ctest.c
KCC: CTEST
"CTEST.C", line 34: [Note] Parameter "argc" not used
(main+22, p.1 l.33): dump(1.442695040); return (EXIT_SUCCESS); }
"CTEST.C", line 34: [Note] Parameter "argv" not used
(main+22, p.1 l.33): dump(1.442695040); return (EXIT_SUCCESS); }
<BEEBE.HOC72.MATH>CTEST.PRE.3
<BEEBE.HOC72.MATH>CTEST.FAI.3
FAIL: CTEST
LINK: Loading
[LNKXCT CTEST execution]
7.47963809273909991e+37
7.47963809273909991e+37
7.4796380580014731383e+37
7.4796374790410269425e+37
7.4796363211201345733e+37
7.4795900042844396388e+37
7.479011043838253072e+37
7.4685897558068946068e+37
7.4106937111882365092e+37
6.947525354238971728e+37
1.4426950408889634074
1.4426950408889634074
1.4426950408889634074
1.4426950399999999997
Wow...this is a real zinger of a bug!
I can work around it for now, but it is a huge daemon lurking to break
numerical software.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
- 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
13-Feb-2005 23:35:27 -0800,1705;000000000000
Return-Path: <MRC@Lingling.Panda.COM>
Received: via tmail-2002(14) for t20arc; Sun, 13 Feb 2005 23:35:27 -0800 (PST)
Return-Path: <MRC@Lingling.Panda.COM>
Received: from Lingling.Panda.COM (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id XAA14326; Sun, 13 Feb 2005 23:35:25 -0800 (PST)
Date: Sun, 13 Feb 2005 23:15:35 -0800 (PST)
From: Mark Crispin <MRC@Lingling.Panda.COM>
Subject: at last, a PDP-10 with proper lights!
To: TOPS-20@Lingling.Panda.COM
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14002501055.9.MRC@Lingling.Panda.COM>
I am pleased to announced that Lingling.Panda.COM now has proper
lights, as evidenced by the following web page:
http://panda.com/tops-20
A larger version of the picture is:
http://panda.com/Lingling.jpg
The 3-bit "Aux" register shows real-time system load ranging form
0 (system mostly idle) to 7 (system mostly busy). The 36-bit
Program Data register is the familiar lights displayed via the
LITES% JSYS on TOPS-20 and the LIGHTS UUO on TOPS-10. The four
larger lights are a CPU heartbeat and I/O activity lights.
The Panda Display was made by Spare Time Gizmos:
http://www.sparetimegizmos.com
I recommend these folks highly (I also have one of their SBC6120
PDP-8 clones). Please contact them for information on getting a
Panda Display board for your own KLH10 based system.
I am preparing an updated version of the Panda Distribution which
supports the Panda Display.
The artwork for the Panda Display is available on:
http://panda.com/TOPS-20/PandaPanel.jpg
At long last, after 30 years of waiting, we once again have a
PDP-10 with lights!
-- Mark --
-------
13-Feb-2005 23:46:49 -0800,795;000000000000
Return-Path: <MRC@Lingling.Panda.COM>
Received: via tmail-2002(14) for t20arc; Sun, 13 Feb 2005 23:46:48 -0800 (PST)
Return-Path: <MRC@Lingling.Panda.COM>
Received: from Lingling.Panda.COM (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id XAA14332; Sun, 13 Feb 2005 23:46:48 -0800 (PST)
Date: Sun, 13 Feb 2005 23:18:03 -0800 (PST)
From: Mark Crispin <MRC@Lingling.Panda.COM>
Subject: seeking fun lights hacks
To: TOPS-20@Lingling.Panda.COM
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14002501506.9.MRC@Lingling.Panda.COM>
Does anyone still have any of their fun programs that used the LIGHTS UUO
to draw pretty patterns in the LIGHTS? Yes, I know that it's been 30 years...
After a while, just AOJA gets boring... :-)
-------
14-Feb-2005 00:31:50 -0800,2195;000000000000
Return-Path: <smj@sdf.lonestar.org>
Received: via tmail-2002(14) for t20arc; Mon, 14 Feb 2005 00:31:50 -0800 (PST)
Return-Path: <smj@sdf.lonestar.org>
Received: from Lingling.Panda.COM (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id AAA14356; Mon, 14 Feb 2005 00:31:48 -0800 (PST)
Received: from sdf.lonestar.org (mx.freeshell.org [192.94.73.21]) by Lingling.Panda.COM with TCP/SMTP; Mon, 14 Feb 2005 00:12:21 -0800 (PST)
Received: from sdf.lonestar.org (ol.freeshell.org [192.94.73.20])
by sdf.lonestar.org (8.13.1/8.12.10) with ESMTP id j1E8BBsN027369;
Mon, 14 Feb 2005 08:11:12 GMT
Received: (from smj@localhost)
by sdf.lonestar.org (8.13.1/8.12.8/Submit) id j1E8BBiV004845;
Mon, 14 Feb 2005 08:11:11 GMT
From: Stephen Jones <smj@sdf.lonestar.org>
Message-Id: <200502140811.j1E8BBiV004845@sdf.lonestar.org>
Subject: Re: at last, a PDP-10 with proper lights!
In-Reply-To: <14002501055.9.MRC@Lingling.Panda.COM>
To: Mark Crispin <MRC@Lingling.Panda.COM>
Date: Mon, 14 Feb 2005 08:11:11 +0000 (UTC)
CC: TOPS-20@Lingling.Panda.COM
X-Mailer: ELM [version 2.4ME+ PL93 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
MRC wrote:
> I recommend these folks highly (I also have one of their SBC6120
> PDP-8 clones). Please contact them for information on getting a
> Panda Display board for your own KLH10 based system.
I will definately vouche for them as well. Their 'PDP-8 in a picture frame'
is quite cool and can even used memory cards for storage. Pavl Zachary
who lugs around a large PDP-11 for fun also built a very nice walnut and
maple (I believe) wooden box for the SBC6120 kit. They both usually show
up to the annual VCF.
> The artwork for the Panda Display is available on:
> http://panda.com/tops-20/PandaPanel.jpg
I'll humbly add that my wife Migiwa created that Panda for Panda.com
specifically. She's not a -10 hacker, but she really likes the modern
styling of the KL10's front panel and other hardware.
> At long last, after 30 years of waiting, we once again have a
> PDP-10 with lights!
Indeed .. this is really cool! Now I want a PeeCee... ;-)
14-Feb-2005 01:36:22 -0800,2631;000000000000
Return-Path: <MRC@Lingling.Panda.COM>
Received: via tmail-2002(14) for t20arc; Mon, 14 Feb 2005 01:36:22 -0800 (PST)
Return-Path: <MRC@Lingling.Panda.COM>
Received: from Lingling.Panda.COM (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id BAA14391; Mon, 14 Feb 2005 01:36:20 -0800 (PST)
Date: Mon, 14 Feb 2005 01:19:55 -0800 (PST)
From: Mark Crispin <MRC@Lingling.Panda.COM>
Subject: Re: at last, a PDP-10 with proper lights!
To: smj@sdf.lonestar.org
cc: TOPS-20@Lingling.Panda.COM
In-Reply-To: <200502140811.j1E8BBiV004845@sdf.lonestar.org>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14002523691.10.MRC@Lingling.Panda.COM>
> > The artwork for the Panda Display is available on:
> > http://panda.com/tops-20/PandaPanel.jpg
> I'll humbly add that my wife Migiwa created that Panda for Panda.com
> specifically. She's not a -10 hacker, but she really likes the modern
> styling of the KL10's front panel and other hardware.
And please tell her thank you! I had forgotten who had given me
that icon, but I figured that I'd find out soon enough after the
announcement! :-)
> > At long last, after 30 years of waiting, we once again have a
> > PDP-10 with lights!
> Indeed .. this is really cool! Now I want a PeeCee... ;-)
Indeed it is.
Most of the driving of the lights is done by TOPS-20 and not by
the KLH10 microcode. As far as the microcode is concerned, there
are simply three sets of lights which can be displayed:
. a 36-bit set of lights
. a 3-bit set of lights
. a 4-bit register which collects a state, and displays on lights
and clears state
The hardware is even simpler. There's 5 registers of 8 lights
each, and a single register of 4 lights. It connects to the PC
via the parallel port (usually LPT1 on 0x378).
The 36-bit set of lights is output on demand. The operating
system can use either the new HSLITE or the traditional DATAO PI,
instruction. [Note that the traditional DATAI APR, instruction
can not be used to read the console switches since it's used to
read the address break on KLs and later.]
The other bits are set or ORd in by the new HSWRIT instruction,
and is updated every 250ms. TOPS-20 actually does the display at
the so-called "100ms clock", which actually is invoked quite a
bit more frequently than 100ms.
I got the idea for the system load value from SYSDPY. Empirical
testing showed that the load average changed too slowly for the
real-time load-display that I wanted. However, using the user
time as a percentage of real time was what I wanted.
-------
14-Feb-2005 12:08:58 -0800,1183;000000000000
Return-Path: <MRC@Lingling.Panda.COM>
Received: via tmail-2002(14) for t20arc; Mon, 14 Feb 2005 12:08:58 -0800 (PST)
Return-Path: <MRC@Lingling.Panda.COM>
Received: from Lingling.Panda.COM (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id MAA14706; Mon, 14 Feb 2005 12:08:56 -0800 (PST)
Date: Mon, 14 Feb 2005 11:07:12 -0800 (PST)
From: Mark Crispin <MRC@Lingling.Panda.COM>
Subject: program lights hack #1
To: TOPS-20@Lingling.Panda.COM
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14002630600.10.MRC@Lingling.Panda.COM>
Here's an early effort. Originally, the IOR 1,3 was an HRL 1,3
but the results are much more interesting with the IOR!
Can you figure out the pattern that it makes? It's not what you
may think at first glance!
For those of you who are unfamiliar with it, CIRC (op code 247)
is a ROTC with AC+1 going the other way. It's a very useful
instruction to reverse bit order!
TITLE HACK
SEARCH MONSYM
HACK: SETZ 1,
HACK1: TLNE 1,777777
JRST HACK
MOVE 2,1
CIRC 2,-^D18
IOR 1,3
LITES%
HALT
HRRZ 2,1
MOVEI 1,1
DISMS%
MOVE 1,2
AOJA 1,HACK1
END HACK
-------
23-Feb-2005 17:46:28 -0800,1889;000000000000
Return-Path: <MRC@lingling.panda.com>
Received: via tmail-2002(14) for t20arc; Wed, 23 Feb 2005 17:46:27 -0800 (PST)
Return-Path: <MRC@lingling.panda.com>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id RAA21140; Wed, 23 Feb 2005 17:46:26 -0800 (PST)
Date: Wed, 23 Feb 2005 17:27:55 -0800 (PST)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: interest in lights panel for your KLH10-based TOPS-20 system?
To: TOPS-20@lingling.panda.com
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14005059206.10.MRC@lingling.panda.com>
I would like to get a straw poll of how many people would be
interested in having a lights panel, such as displayed on:
http://panda.com/tops-20
for their own TOPS-20 system?
The panel is a parallel port device and is mounted on a PC tower
disk port bezel. The existing software to drive it is for Linux
on Intel hardware, but it may also work on FreeBSD, etc. if it
has outb().
Pricing would depend upon the number of people interested, but
maximum price for a fully-assembled display, ready to install on
your PC, would be about $250. For do-it-yourselfers, bare PC
boards (no parts) could be as little as $25 if there's enough
interest.
A system can have up to 4 lights panels. The current software
only drives panel 0, but can be expanded in the future.
If you're interested, please let me know with your level of
interest:
bare boards
kit (boards + parts)
fully-assembled unit
and how much you're willing to spend. I'm not asking for a
commitment, but just want to gauge if it's worth putting together
an order to Spare Time Gizmos for boards and/or assembled units.
I'm not planning on making any money out of this; I'm basically
just passing along what Spare Time Gizmos has told me would be
the pricing.
-------
25-Feb-2005 16:18:51 -0800,1828;000000000000
Return-Path: <mike@zanker.org>
Received: via tmail-2002(14) for t20arc; Fri, 25 Feb 2005 16:18:50 -0800 (PST)
Return-Path: <mike@zanker.org>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id QAA22544; Fri, 25 Feb 2005 16:18:49 -0800 (PST)
Received: from mallard.zanker.org ([81.187.169.2]) by lingling.panda.com with TCP/SMTP; Fri, 25 Feb 2005 15:58:21 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=thekey; d=zanker.org;
b=QCAWYtZgktjLEMQaY9y+bVPDOJEgaoRpJmDNaIqt3E022LlWqLX79dSONGZ/8uVs4uT53VnU8HJipKgbzAD5AdDtx+JMo4+47gz2F7qM92wvQP6cdkjiXy9PcjgANgxp;
Received: from jemima.zanker.org ([2001:8b0:f:1:260:8ff:fe49:e6a4] helo=[IPv6:2001:8b0:f:1:260:8ff:fe49:e6a4])
by mallard.zanker.org with esmtpsa (TLSv1:AES256-SHA:256)
(Exim 4.47)
id 1D4pLc-000488-6j
for TOPS-20@lingling.panda.com; Fri, 25 Feb 2005 23:58:16 +0000
Message-ID: <421FBB97.7000605@zanker.org>
Date: Fri, 25 Feb 2005 23:58:15 +0000
From: Mike Zanker <mike@zanker.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: TOPS-20@lingling.panda.com
Subject: TOPS-20 SMTP server
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Mallard-MailScanner: Found to be clean (of known viruses)
X-Mallard-MailScanner-From: mike@zanker.org
Hi,
just trying to understand how the TOPS-20 SMTP server behaves out of the
box. Am I correct in saying that my TOPS-20 system, tops-20.zanker.org,
will relay mail from any server whose IP address resolves to *.zanker.org?
Does any configuration need to be done to harden it against crackers and
spammers or is it safe out of the box?
Finally, does it keep a log of activity anywhere?
Thanks for your time,
Mike.
26-Feb-2005 15:00:37 -0800,2301;000000000000
Return-Path: <mike@zanker.org>
Received: via tmail-2002(14) for t20arc; Sat, 26 Feb 2005 15:00:37 -0800 (PST)
Return-Path: <mike@zanker.org>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id PAA23122; Sat, 26 Feb 2005 15:00:35 -0800 (PST)
Received: from mallard.zanker.org ([81.187.169.2]) by lingling.panda.com with TCP/SMTP; Sat, 26 Feb 2005 14:42:06 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=thekey; d=zanker.org;
b=L/Myx/zQbCPOkqCrVzjFb+8E+eIDTOyIPazg+0UEhcirzekj01iAkVrIlofGExYz2/SmxDKzbWhhq3ah7+Hcq6TOKvSOTX+gYBV9hurjaYjuBAX3J7ePhfe+74DD5ikj;
Received: from jemima.zanker.org ([2001:8b0:f:1:260:8ff:fe49:e6a4] helo=[IPv6:2001:8b0:f:1:260:8ff:fe49:e6a4])
by mallard.zanker.org with esmtpsa (TLSv1:AES256-SHA:256)
(Exim 4.47)
id 1D5AdB-0008OY-LW
for TOPS-20@lingling.panda.com; Sat, 26 Feb 2005 22:41:49 +0000
Message-ID: <4220FB2D.90506@zanker.org>
Date: Sat, 26 Feb 2005 22:41:49 +0000
From: Mike Zanker <mike@zanker.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: TOPS-20@lingling.panda.com
Subject: Networking dies after a couple of hours
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Mallard-MailScanner: Found to be clean (of known viruses)
X-Mallard-MailScanner-From: mike@zanker.org
Hi,
I'm running the latest Panda distribution on a Dell Poweredge 750
(3.4GHz P4, 1GB RAM, 2 Intel E1000 NICs) under Red Hat Enterprise Linux
3. The machine is very lightly loaded, just acting as a DNS server and
backup mail server.
The system runs fine for around a couple of hours then IP networking
seems to die - "no route to host" trying to reach it externally and
"Trying... Host is not up, destination unreachable" trying to telnet
out. Shutting down, exiting the emulator then starting up again brings
it back (for another couple of hours).
Any ideas where to start debugging this? Is there anything I can check
under TOPS-20 that might give an indication? There is nothing of
relevance in the underlying Linux logs and, having captured all network
traffic to both server and TOPS-20 system, I can see nothing out of the
ordinary.
Thanks,
Mike.
26-Feb-2005 16:43:22 -0800,2024;000000000000
Return-Path: <mike@zanker.org>
Received: via tmail-2002(14) for t20arc; Sat, 26 Feb 2005 16:43:22 -0800 (PST)
Return-Path: <mike@zanker.org>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id QAA23150; Sat, 26 Feb 2005 16:43:21 -0800 (PST)
Received: from mallard.zanker.org ([81.187.169.2]) by lingling.panda.com with TCP/SMTP; Sat, 26 Feb 2005 16:25:25 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=thekey; d=zanker.org;
b=Pbo1vSwN1YLn7j4pKGkCE1PbPcEjES+UHD65MIjhe9NdW2PJz4Ttb1l++sG0EmvL8rI6mh43F/Javi0TjMP80rUa+Afev/YxDlzksWcZ9PkARKd/DD5RP7tlEbn8LCKL;
Received: from jemima.zanker.org ([2001:8b0:f:1:260:8ff:fe49:e6a4] helo=[IPv6:2001:8b0:f:1:260:8ff:fe49:e6a4])
by mallard.zanker.org with esmtpsa (TLSv1:AES256-SHA:256)
(Exim 4.47)
id 1D5CFC-0000XZ-5T
for TOPS-20@lingling.panda.com; Sun, 27 Feb 2005 00:25:10 +0000
Message-ID: <42211365.3040005@zanker.org>
Date: Sun, 27 Feb 2005 00:25:09 +0000
From: Mike Zanker <mike@zanker.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: TOPS-20@lingling.panda.com
Subject: Re: Networking dies after a couple of hours
References: <4220FB2D.90506@zanker.org>
In-Reply-To: <4220FB2D.90506@zanker.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Mallard-MailScanner: Found to be clean (of known viruses)
X-Mallard-MailScanner-From: mike@zanker.org
On 26/02/2005 22:41, Mike Zanker wrote:
> The system runs fine for around a couple of hours then IP networking
> seems to die - "no route to host" trying to reach it externally and
> "Trying... Host is not up, destination unreachable" trying to telnet
> out. Shutting down, exiting the emulator then starting up again brings
> it back (for another couple of hours).
Just to clarify, it is the TOPS-20 system that suffers the loss of
networking - the underlying Linux OS continues to work just fine.
Mike.
27-Feb-2005 06:35:38 -0800,4175;000000000000
Return-Path: <slogin@optonline.net>
Received: via tmail-2002(14) for t20arc; Sun, 27 Feb 2005 06:35:38 -0800 (PST)
Return-Path: <slogin@optonline.net>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id GAA23528; Sun, 27 Feb 2005 06:35:36 -0800 (PST)
From: slogin@optonline.net
Received: from mta3.srv.hcvlny.cv.net ([167.206.5.69]) by lingling.panda.com with TCP/SMTP; Sun, 27 Feb 2005 06:20:05 -0800 (PST)
Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta3.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004))
with ESMTP id <0ICK003PAQHCE0@mta3.srv.hcvlny.cv.net> for
TOPS-20@lingling.panda.com; Sun, 27 Feb 2005 09:20:00 -0500 (EST)
Received: from [10.240.3.38] (Forwarded-For: [24.47.48.231])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sun, 27 Feb 2005 09:20:00 -0500
Date: Sun, 27 Feb 2005 09:20:00 -0500
Subject: 127.0.0.1 Loopback (non-)usage
To: TOPS-20@lingling.panda.com
Message-id: <2979396298026e.298026e2979396@optonline.net>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
I was recently hacking some code to cache some local host information
in HSTNAM.MAC (more on that in another posting to follow) and I did
the following:
DMOVE A,[ EXP .GTHNS,<POINT 7,$MYHST>] ; Get host name and status
MOVE C,[MHOSTN(127,0,0,1)] ;Want the local host
GTHST% ; Loopback IP address must exist
ERJMPR R ; Ditto: config error or serious illness
DMOVEM C,$MYHSS ; Save the host number and status
RETSKP ; cached information
I had expected to get the name of the local host and had hoped for the
loopback address to get resolved to the primary host interface. I got
neither but rather, "600704,Unknown host number", instead. This isn't
the end of the world as the following does work:
MOVX A,.GTHSZ ; Return local host number in D
GTHST% ; (32-bit Internet format)
ERJMPR R ; ?? TCP not well or not configured?
JUMPLE D,R ; Sanity result: Must be non-zero positive
DMOVEM B,$MYHCN ; Cache table dimensions
MOVEM D,$MYHSN ; Also store my host number
DMOVE A,[ EXP .GTHNS,<POINT 7,$MYHST>] ; Get host name and status
MOVE C,D ; Pass in my host number
GTHST% ; Why doesn't 127.0.0.1 work?
ERJMPR R ; Ditto: config error or serious illness
MOVEM D,$MYHSS ; Save the host status
RETSKP ; cached information
So, how come? Is this because Tops-20 doesn't have a loopback device
to bind 127.0.0.1 to? Does it really need one? Is this a Unixism?
The following definitions were used in both examples:
$MYHSN: 0 ; local host number
$MYHSS: 0 ; My host status
$MYHCN: 0 ; -number host names,,0
0 ; -length of HSTSTS table,,0
$MYHST: REPEAT HSTNMW,<0> ; Some place to put the local host text
; Macro to construct an Internet host number from
; a set of tuples, which are laid out as follows:
;
; N1 N2 N3 N4
; 0000 00000011 11111111 22222222 22333333
; 0123 45678901 23456789 01234567 89012345
DEFINE MHOSTN (N1<0>,N2<0>,N3<0>,N4<0>) < ;;Make a foreign host number
IFE <<^D<'N1>>!<^D<'N2>>!<^D<'N3>>!<^D<'N4>>>,.FATAL Zero IP address
IFN <<^D<'N1>>&<-1B27>>,.FATAL First Tuple exceeds 8 bits
IFN <<^D<'N2>>&<-1B27>>,.FATAL Second Tuple exceeds 8 bits
IFN <<^D<'N3>>&<-1B27>>,.FATAL Third Tuple exceeds 8 bits
IFN <<^D<'N4>>&<-1B27>>,.FATAL Fourth Tuple exceeds 8 bits
<<<^D<'N1>>B11>!<<^D<'N2>>B19>!<<^D<'N3>>B27>!<<^D<'N4>>B35>>
>;;End of MHOSTN
27-Feb-2005 09:26:07 -0800,3235;000000000000
Return-Path: <slogin@optonline.net>
Received: via tmail-2002(14) for t20arc; Sun, 27 Feb 2005 09:26:06 -0800 (PST)
Return-Path: <slogin@optonline.net>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id JAA23607; Sun, 27 Feb 2005 09:26:05 -0800 (PST)
From: slogin@optonline.net
Received: from mta9.srv.hcvlny.cv.net ([167.206.5.42]) by lingling.panda.com with TCP/SMTP; Sun, 27 Feb 2005 09:08:17 -0800 (PST)
Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta9.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004))
with ESMTP id <0ICK00GSOY9J0G@mta9.srv.hcvlny.cv.net> for
TOPS-20@lingling.panda.com; Sun, 27 Feb 2005 12:08:07 -0500 (EST)
Received: from [10.240.3.39] (Forwarded-For: [24.47.48.231])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sun, 27 Feb 2005 12:08:07 -0500
Date: Sun, 27 Feb 2005 12:08:07 -0500
Subject: Definition of local host in DOMAIN reverse zone
To: TOPS-20@lingling.panda.com
Message-id: <2d7d1bd2d7f26b.2d7f26b2d7d1bd@optonline.net>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
I've been using my 20 to send a pile of mail, nearly all to local
addresses. Everything works fine until I reply to a message that was
sent to me from a local user. When I do this, MM hangs (it seems like
does this for over a minute). When it comes back, the local name has
now been translated to an address in the DECnet realm.
Some analysis shows that MM is sitting in $GTDOM, waiting for a
response from the resolver (CHIVES), which doesn't seem to know about
the local host (TOMMYT)! The call is from $GTHST, which is looking to
validate the hostname, doing a host match. The resolver never finds
TOMMYT even though I know I put it both in the local host table and in
a zone.
SRA has very graciously spent some time helping me set up a zone, which
I believe that I've done correctly. Note the following line from
DOMAIN:RESOLV.CONFIG:
ZLOAD 168.192.IN-ADDR.ARPA. DOMAIN:REVERSE.ZONE
And then the following relevant lines in DOMAIN:REVERSE.ZONE
;Hosts on primary cable (NOTE NAT!)
5.1 3600 IN PTR ZY6HT.
7.1 3600 IN PTR Phoenix.
20.1 3600 IN PTR TOMMYT.
8.3 3600 IN PTR B25.David.
I believe that I've got this at least partially right as evidenced by
the following output from FINGER:
User Personal name Job Subsys Idle TTY Console location
OINKY Guinea Pig 8 FINGER 50 TOMMYT: Cellar
10 EXEC . 51 B25.David: Cellar
SLOGIN Thomas DeBellis 9 EMACS 3 44 Phoenix: Kitchen, #1
11 EXEC 11:57. 46 ZY6HT: Bedroom
12 SYSDPY 11 45 Phoenix: Kitchen, #2
13 TELNET 47 Phoenix: Kitchen, #3
No hanging, no waiting. But why does MM hang? What did I do wrong?
27-Feb-2005 09:59:00 -0800,9380;000000000000
Return-Path: <slogin@optonline.net>
Received: via tmail-2002(14) for t20arc; Sun, 27 Feb 2005 09:59:00 -0800 (PST)
Return-Path: <slogin@optonline.net>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id JAA23618; Sun, 27 Feb 2005 09:58:58 -0800 (PST)
From: slogin@optonline.net
Received: from mta10.srv.hcvlny.cv.net ([167.206.5.85]) by lingling.panda.com with TCP/SMTP; Sun, 27 Feb 2005 09:40:56 -0800 (PST)
Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta10.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004))
with ESMTP id <0ICK00HY0ZS7BB@mta10.srv.hcvlny.cv.net> for
TOPS-20@lingling.panda.com; Sun, 27 Feb 2005 12:40:55 -0500 (EST)
Received: from [10.240.3.39] (Forwarded-For: [24.47.48.231])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sun, 27 Feb 2005 12:40:55 -0500
Date: Sun, 27 Feb 2005 12:40:55 -0500
Subject: HSTNAM Hack to handle (my) CHIVES reverse zone issue
To: TOPS-20@lingling.panda.com
Message-id: <2d83ee32d84ec8.2d84ec82d83ee3@optonline.net>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
I grew impatient looking at the source code to CHIVES. My MACRO
was always better than my C (which isn't to imply that either were
stellar), and I put together a hack for HSTNAM for anybody who might
be wrestling with the same problem. But! If anybody does anything
different, please tell me! Also, do not assume that MRC will take
these changes.
Basically, I've inserted some caching code in $GTHST. If a request
comes in for stuff it knows about, it simply returns the information
without bothering to ask CHIVES. I could say that a benefit of this
is to improve efficiency as you'd probably run the scheduler less, but
I doubt that this makes much of a difference when sending mail to a
single address. Maybe to a list with a bunch of local recipients?
Also, part of this code is probably not a good idea for a number of
reasons. Since the dimensions of the host table can change during the
run of the operating system, it's probably a bad idea to cache it.
Caching the host status might conceivably be bad, also.
However, the question is whether the whole philosophy is wrong, when
the host name table is only queried if the resolver doesn't have the
requested information. This is backwards from what Unix and Windows
do. The problem is that you can't quickly overide what is in the DNS.
One needs to do this for errors in the global DNS and for NAT'ed host.
Isn't it a lot easier to set up a local host table change then to set
up a whole DNS? What if you only have one machine and don't have
another for the DNS server? I've been wondering about this and would
like some opinions. Anyway, here at the changes in HSTNAM. You'll
need to increase the CODE .PSECT size in MM a little, also.
Change:
=======
$GTHST::CALL $DOGTD ; try the domain system first
To:
===
$GTHST::SKIPN $MYTRY ; Do we want to do this anymore?
SKIPN $GTHOK ; OK to do GTHST%?
JRST $GTHS1 ; No, hope somebody else knows what to do
SKIPE $MYHSN ; Did we ever find out who we are?
IFSKP.
CALL $GTCHI ; Nope, cache (local) host information
RET ; Pass an error up
ENDIF.
; Now see if we can answer some questions
$GTHS0: CAXN A,.GTHVN ; Validate host name?
CAXE C,.GTHVH ; and doing a host match (not a zone?)
IFSKP. ; Yes to both means we might already know
SAVEAC <E,E+1> ; Save the request number
DMOVE E,A ; and host name pointer
HRROI A,$MYHST ; See if it is ours
STCMP%
ERJMPR .+1 ; Set AC1 if there is a problem
IFN. A ; Any sort of difference?
DMOVE A,E ; Restore orginal argument
JRST $GTHS1 ; Hand off to regular processing
ENDIF.
MOVE E,B ; Save the updated source
MOVE A,D ; Load the canonical host pointer
HRROI B,$MYHST ; Our host name is canonical (right?)
SETZB C,D ; Stop on a null
SOUT% ; Should really have a local routine ...
ERJMPR R ; That really shouldn't fail
MOVE D,A ; Return updated canonical host pointer
MOVE B,E ; Return updated source
MOVX A,.GTHVS ; Return total success
MOVX C,<.GTHCI,,.GTHTA>;Return internet class
RETSKP ; and host address (type A RR)
ENDIF. ; End case .GTHVN
CAXN A,.GTHNS ; Return host name?
CAME C,$MYHSN ; Requested host number same as local?
IFSKP. ; What about 127.0.0.1?
MOVE A,B ; Position destination
HRROI B,$MYHST ; Source is cached name
SETZB C,D ; Stopping on a null
SOUT% ; Should really have a local routine ...
ERJMPR R ; That really shouldn't fail
MOVE B,A ; Returned updated position
MOVX A,.GTHVS ; Return total success
DMOVE C,$MYHSN ; Local host number and status
RETSKP
ENDIF. ; End case .GTHNS
CAXE A,.GTHSN ; Return host number?
IFSKP.
DMOVE C,A ; Save the host name pointer
HRROI A,$MYHST ; See if it is ours
STCMP%
ERJMPR .+1 ; Set AC1 if there is a problem
IFN. A ; Any sort of difference?
DMOVE A,C ; Restore orginal argument
JRST $GTHS1 ; Hand off to regular processing
ENDIF.
MOVX A,.GTHVS ; Otherwise return total success
DMOVE C,$MYHSN ; Local host number and status
RETSKP
ENDIF. ; End case .GTHSN
CAXE A,.GTHSZ ; Wants local host name and table information?
IFSKP.
MOVX A,.GTHVS ; Return total success
DMOVE B,$MYHCN ; Host table dimensions
MOVE D,$MYHSN ; Local host number
RETSKP
ENDIF. ; End case .GTHSZ
; Here if we couldn't do it somehow
$GTHS1: CALL $DOGTD ; try the domain system first
; The following code is used to support the above it is inserted
; directly before the END statement at the end of HSTNAM
;N.B., If we were really winning, we'd have a local STCMP% and SOUT%
; routine to check and copy data. In other words, there is
; still some JSYS overhead that could be pruned out that would
; result in less scheduler overhead.
;; Used to cache host information
$GTCHI: SAVEAC <A,B,C,D> ; preserve calling AC's
SETOM $MYTRY ; Assume that this hasn't worked
MOVX A,.GTHSZ ; Return local host number in D
GTHST% ; (32-bit Internet format)
ERJMPR R ; ?? TCP not well or not configured?
JUMPLE D,R ; Sanity result: Must be non-zero positive
DMOVEM B,$MYHCN ; Cache table dimensions
MOVEM D,$MYHSN ; Also store my host number
DMOVE A,[ EXP .GTHNS,<POINT 7,$MYHST>] ; Get host name and status
MOVE C,D ; Pass in my host number
GTHST% ; Why doesn't 127.0.0.1 work?
ERJMPR R ; Ditto: config error or serious illness
MOVEM D,$MYHSS ; Save the host status
SETZM $MYTRY ; Flag that we are okay to retrieve
RETSKP ; cached information
;N.B., Since we are using a CODE psect, it's probably reasonable to
; assume that there is a DATA psect defined someplace. However,
; if there ISN'T, then we'll have to tell LINK where to put this.
.ENDPS ; End of pure code
.PSECT DATA ; Space for cached host information
REMARK ** DON'T ** change the order of these variables! DMOVED!
$MYTRY: 0 ; non-zero if we shouldn't bother anymore
$MYHSN: 0 ; local host number
$MYHSS: 0 ; My host status
$MYHCN: 0 ; -number host names,,0
0 ; -length of HSTSTS table,,0
$MYHST: REPEAT HSTNMW,<0> ; Some place to put the local host text
;N.B., Shouldn't the control flags ($GTDOK, $GTHOK, $GTMOK and
; $GTFOK) be moved here?
.ENDPS ; End of data
27-Feb-2005 10:11:32 -0800,1826;000000000000
Return-Path: <MRC@lingling.panda.com>
Received: via tmail-2002(14) for t20arc; Sun, 27 Feb 2005 10:11:32 -0800 (PST)
Return-Path: <MRC@lingling.panda.com>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id KAA23635; Sun, 27 Feb 2005 10:11:30 -0800 (PST)
Date: Sun, 27 Feb 2005 09:41:18 -0800 (PST)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: Re: 127.0.0.1 Loopback (non-)usage
To: slogin@optonline.net
cc: TOPS-20@lingling.panda.com
In-Reply-To: <2979396298026e.298026e2979396@optonline.net>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14006022837.9.MRC@lingling.panda.com>
> DMOVE A,[ EXP .GTHNS,<POINT 7,$MYHST>] ; Get host name and status
> MOVE C,[MHOSTN(127,0,0,1)] ;Want the local host
> GTHST% ; Loopback IP address must exist
> ERJMPR R ; Ditto: config error or serious illness
GTHST% only returns host table information from SYSTEM:HOSTS.TXT.
The Panda distribution does not enable the DEC DNS resolver
because they got the interface wrong and it does not work with
MMailr (I tried to fix the DEC resolver and gave up).
More importantly, 127.0.0.1 is a UNIXism (or more accurately,
it's a socketsism). There is no loopback interface in TOPS-20.
The way that you look up your local host name is with an address
of -1.
However, I *strongly* recommend that you use the routines in my
HSTNAM.MAC module instead of calling GTHST%, GTDOM%, etc.
directly. HSTNAM.REL should be on SYS: as a standard library.
The routines in HSTNAM provide a standard interface and also
provide extremely useful run-time tuning. When the DNS is not
working, a single word change to a program that uses HSTNAM stops
it from doing so.
-------
27-Feb-2005 10:23:00 -0800,1288;000000000000
Return-Path: <MRC@lingling.panda.com>
Received: via tmail-2002(14) for t20arc; Sun, 27 Feb 2005 10:23:00 -0800 (PST)
Return-Path: <MRC@lingling.panda.com>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id KAA23641; Sun, 27 Feb 2005 10:22:59 -0800 (PST)
Date: Sun, 27 Feb 2005 09:48:42 -0800 (PST)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: Re: Definition of local host in DOMAIN reverse zone
To: slogin@optonline.net
cc: TOPS-20@lingling.panda.com
In-Reply-To: <2d7d1bd2d7f26b.2d7f26b2d7d1bd@optonline.net>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14006024183.9.MRC@lingling.panda.com>
Do you have a forward reference (A record) zone for all these
names? You need both the forward and reverse references. Note
that these A records have to be in the root zone since these are
all root names.
You're asking for all sorts of fun and laughter doing things the
way you are doing. Get yourself a proper domain name, put your
machines in that domain in both your forward and reverse zones,
and stop playing with root names.
You'll be much happier and pull much less hair. What's more, you
have the prospect of those machines actually doing Internet mail.
-------
27-Feb-2005 11:49:41 -0800,1293;000000000000
Return-Path: <MRC@lingling.panda.com>
Received: via tmail-2002(14) for t20arc; Sun, 27 Feb 2005 11:49:41 -0800 (PST)
Return-Path: <MRC@lingling.panda.com>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id LAA23670; Sun, 27 Feb 2005 11:49:39 -0800 (PST)
Date: Sun, 27 Feb 2005 11:31:54 -0800 (PST)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: Re: HSTNAM Hack to handle (my) CHIVES reverse zone issue
To: slogin@optonline.net
cc: TOPS-20@lingling.panda.com
In-Reply-To: <2d83ee32d84ec8.2d84ec82d83ee3@optonline.net>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14006042971.13.MRC@lingling.panda.com>
MM and MMailr already do their own caching. I doubt that you'll
get much benefit from caching in HSTNAM, and there are some
possible harmful effects.
The resolver is supposed to be the general caching mechanism; and
I think that you'll be better off trying to determine why you are
having name resolution problems.
As I said in a previous message, I think that it's due to your
use of root level names. If you're not on the Internet, there's
no reason to have a resolver; and if you are on the Internet, you
should have your local network namespace set up right.
-------
27-Feb-2005 12:12:36 -0800,2179;000000000000
Return-Path: <sra@hactrn.net>
Received: via tmail-2002(14) for t20arc; Sun, 27 Feb 2005 12:12:36 -0800 (PST)
Return-Path: <sra@hactrn.net>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id MAA23687; Sun, 27 Feb 2005 12:12:35 -0800 (PST)
Received: from cyteen.hactrn.net ([66.92.66.68]) by lingling.panda.com with TCP/SMTP; Sun, 27 Feb 2005 11:54:52 -0800 (PST)
Received: from orodruin.hactrn.net (pcp0010099834pcs.levtwn01.pa.comcast.net [69.242.36.56])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client CN "orodruin.hactrn.net", Issuer "Grunchweather Associates" (verified OK))
by cyteen.hactrn.net (Postfix) with ESMTP id 4E35C759
for <TOPS-20@lingling.panda.com>; Sun, 27 Feb 2005 14:54:51 -0500 (EST)
Received: from orodruin.hactrn.net (localhost [IPv6:::1])
by orodruin.hactrn.net (Postfix) with ESMTP id D52113B9
for <TOPS-20@lingling.panda.com>; Sun, 27 Feb 2005 19:54:48 +0000 (GMT)
Date: Sun, 27 Feb 2005 14:54:48 -0500
From: Rob Austein <sra@hactrn.net>
To: TOPS-20@lingling.panda.com
Subject: Re: HSTNAM Hack to handle (my) CHIVES reverse zone issue
In-Reply-To: <2d83ee32d84ec8.2d84ec82d83ee3@optonline.net>
References: <2d83ee32d84ec8.2d84ec82d83ee3@optonline.net>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20050227195448.D52113B9@orodruin.hactrn.net>
Well...
I agree with Mark that you'd be better off using a real DNS name than
making up fake TLDs. While I no longer recall precisely what the
library code does, Mark's undoubtedly also correct about the forward
and reverse mappings needing to match in order for this to work right.
At the time CHIVES was written, HOSTS.TXT was still being maintained,
but poorly (not SRI-NIC's fault, people weren't reporting changes
properly anymore). So it made sense to check the DNS before checking
the hosts table. In those days, BSD unix also checked the DNS first.
Times have changed. These days it would make more sense to check the
host table first.
27-Feb-2005 17:42:35 -0800,5471;000000000000
Return-Path: <slogin@optonline.net>
Received: via tmail-2002(14) for t20arc; Sun, 27 Feb 2005 17:42:34 -0800 (PST)
Return-Path: <slogin@optonline.net>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id RAA23838; Sun, 27 Feb 2005 17:42:33 -0800 (PST)
From: slogin@optonline.net
Received: from mta2.srv.hcvlny.cv.net ([167.206.5.68]) by lingling.panda.com with TCP/SMTP; Sun, 27 Feb 2005 17:23:47 -0800 (PST)
Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta2.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004))
with ESMTP id <0ICL00AMYL7M8H@mta2.srv.hcvlny.cv.net>; Sun,
27 Feb 2005 20:23:46 -0500 (EST)
Received: from [10.240.3.35] (Forwarded-For: [24.47.48.231])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sun, 27 Feb 2005 20:23:46 -0500
Date: Sun, 27 Feb 2005 20:23:46 -0500
Subject: Re: Definition of local host in DOMAIN reverse zone
To: Mark Crispin <MRC@lingling.panda.com>
Cc: TOPS-20@lingling.panda.com
Message-id: <1af7edb1afc54e.1afc54e1af7edb@optonline.net>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
Mark,
Thanks for responding to this. I heartily detest and generally resist
bugging people for answers unless I feel that I have something
(however hackish) to contribute. Or I'm completely lost ...
> Do you have a forward reference (A record) zone for all these
> names? You need both the forward and reverse references. Note
> that these A records have to be in the root zone since these are
> all root names.
I think that the basic problem here is that my skill set and level of
expertise is quite disjointed in this area. It seems clear that I
don't have enough background in DNS to fully understand what the
issues are. So, I don't know what a forward reference is and I
haven't found any simple documentation to explain this to me. What
are root zones? Why are root zones?
Do you have a URL or other documentation pointer that explains how to
set this stuff up for CHIVES? General theory?
> You're asking for all sorts of fun and laughter doing things the
> way you are doing. Get yourself a proper domain name, put your
> machines in that domain in both your forward and reverse zones,
> and stop playing with root names.
Well, hacking HSTNAM *was* fun! Er, my idea of fun! And laughs!
More, below. There are three general issues that I have with getting
a proper domain name. For other reasons, however, I agree that I
should do this at some point and will do so.
1) Don't I have to 'buy' a domain from somebody and then keep paying
for it? It's kind of like paying rent. Being a prospective
rentee, how do I tell when I have a good rentor?
Also, as I take machines in and out of service (which I do as I
rebuild stuff), don't I have to update the DNS? (I.E., pay to do
so?)
2) Secondly, to respond to SRA's points: the question is what is the
source of definitive information about a host or what I've heard
called the Source Of Record (SOR). For the public Internet
proper, the DNS is the SOR--you have to count on it being correct.
For an Internal LAN (possibly experimental), the public DNS may
not be the SOR. Further, the hosts on the LAN may have no
Internet connectivity at all and for them, setting up a DNS may be
overkill. In this case, updating a HOSTS.TXT file with a few
entries that I want to overide seems to be more appropriate.
3) Third, I didn't have to be trained or bug people to pop a line
into HOSTS.TXT and run IPHOST.
This suggests rethinking about what the source of record is for host
name resolution. Historically, the reasons for choosing CHIVES (or
the DEC resolver) over HOSTS.TXT are clear: it turned out to be the
SOR. However, things may be different now as evidenced by the policy
for the SOR policy of Windows and Linspire (nee' Lindows, the host for
TOMMYT). Here, the HOSTS.TXT file is searched first before asking the
DNS.
That has a number advantages; perhaps one might manage the
experimental LAN situation easier? You don't have to knock a DNS
together, you just edit the HOSTS.TXT file. Isn't that easier? Also,
you now have a mechanism to keep traffic away from 'bad' hosts.
What do you think of the following? Define another monitor SMON/TMON
bit (or entry) for HSTNAM source of record. If the bit is on, then
GTHST% is asked first over the resolver. If it's off, then the
resolver is asked (as is the current default behavior).
A number of programs use HSTNAMs. These are, at least, the mail
system (not just MM), TELNET, FTP, FINGER and the new FTP server.
It seems counter-intuitive to deposit values into all the executables
depending on where they are run.
> You'll be much happier and pull much less hair. What's more, you
> have the prospect of those machines actually doing Internet mail.
One way or another, I will have a public Tops-20 machine doing
Internet mail. My goal is to have one 20 behind a firewall on a VPN
connected to another machine on the Internet via a CI-20. I intend to
take a crack at the CI after I am more or less 'done' with FTPSRV.
27-Feb-2005 19:14:04 -0800,3722;000000000000
Return-Path: <MRC@lingling.panda.com>
Received: via tmail-2002(14) for t20arc; Sun, 27 Feb 2005 19:14:04 -0800 (PST)
Return-Path: <MRC@lingling.panda.com>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id TAA23880; Sun, 27 Feb 2005 19:14:03 -0800 (PST)
Date: Sun, 27 Feb 2005 18:21:37 -0800 (PST)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: Re: Definition of local host in DOMAIN reverse zone
To: slogin@optonline.net
cc: TOPS-20@lingling.panda.com
In-Reply-To: <1af7edb1afc54e.1afc54e1af7edb@optonline.net>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14006117558.13.MRC@lingling.panda.com>
> So, I don't know what a forward reference is and I
> haven't found any simple documentation to explain this to me.
A forward reference is a reference from a name to address (A
record) or mail relay list (MX record). A reverse reference is a
reference from address to name (PTR record).
> What
> are root zones? Why are root zones?
Root zones are something that you normally should never touch.
These are the zones that hold COM, NET, ORG, etc.
The names you have are effectively root names, and thus are in
the root zone. But they're not. Hence the problem.
> Do you have a URL or other documentation pointer that explains how to
> set this stuff up for CHIVES? General theory?
Ha ha ha!
Your only hope is to find an O'Reilly book that explains how to
set up DNS zones, and then once you have those zones worry about
how to do so in Chives.
> 1) Don't I have to 'buy' a domain from somebody and then keep paying
> > for it? It's kind of like paying rent. Being a prospective
> > rentee, how do I tell when I have a good rentor?
You own the domain, but you have to pay property tax on it to a
registrar and if you don't then you forfeit it.
There are lots of domain registrars out there. Pick one.
> > Also, as I take machines in and out of service (which I do as I
> > rebuild stuff), don't I have to update the DNS? (I.E., pay to do
> > so?)
Only if you change the names/IP addresses of the sites in
question. And this isn't to the registrar, this is to whomever
runs your DNS server. You could run it yourself. My ISP runs my
DNS server as part of my basic service, and just takes updated
zone files from me as I provide them.
> > For an Internal LAN (possibly experimental), the public DNS may
> > not be the SOR. Further, the hosts on the LAN may have no
> > Internet connectivity at all and for them, setting up a DNS may be
> > overkill. In this case, updating a HOSTS.TXT file with a few
> > entries that I want to overide seems to be more appropriate.
If you aren't on the Internet, then don't run Chives. No
resolver, no DNS.
> This suggests rethinking about what the source of record is for host
> name resolution. Historically, the reasons for choosing CHIVES (or
> the DEC resolver) over HOSTS.TXT are clear: it turned out to be the
> SOR. However, things may be different now
I respectfully disagree. A fair deal of support problems that I
encounter has to do with UNIX's unfortunate belief of host table
over DNS. Host tables have a tendency to be set up wrong with
respect to primary host names.
I am not going to change my software. You can change your copy
if you wish -- you have sources. But I recommend that you do not
do so; and if you do anyway then you're on your own.
I think that you'll be much happier if you just configure your
system properly. It does not require much effort to do things
right, and is certainly less work than creating a new unsupported
configuration.
-------
27-Feb-2005 20:03:51 -0800,2203;000000000000
Return-Path: <jtw@lcs.mit.edu>
Received: via tmail-2002(14) for t20arc; Sun, 27 Feb 2005 20:03:51 -0800 (PST)
Return-Path: <jtw@lcs.mit.edu>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id UAA23903; Sun, 27 Feb 2005 20:03:50 -0800 (PST)
Received: from mercury.lcs.mit.edu ([18.26.0.122]) by lingling.panda.com with TCP/SMTP; Sun, 27 Feb 2005 19:48:08 -0800 (PST)
Received: from [192.168.2.4] (c-24-15-69-242.client.comcast.net [24.15.69.242])
(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
(No client certificate requested)
by mercury.lcs.mit.edu (Postfix) with ESMTP id CF833872E9;
Sun, 27 Feb 2005 22:48:06 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p06210204be4841b2c666@[192.168.2.4]>
In-Reply-To: <14006022837.9.MRC@lingling.panda.com>
References: <14006022837.9.MRC@lingling.panda.com>
Date: Sun, 27 Feb 2005 21:48:03 -0600
To: Mark Crispin <MRC@lingling.panda.com>, slogin@optonline.net
From: John Wroclawski <jtw@lcs.mit.edu>
Subject: Re: 127.0.0.1 Loopback (non-)usage
Cc: TOPS-20@lingling.panda.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
At 9:41 AM -0800 2/27/05, Mark Crispin wrote:
>
>More importantly, 127.0.0.1 is a UNIXism (or more accurately,
>it's a socketsism).
welll, sort of.
It certainly started that way, but 127.0.0.1 (more precisely, 127/8)
is now documented as a loopback address in RFC 3330 and in the IANA
assigned numbers database, and reserved for this purpose in the IPv4
Address Registry
(http://www.iana.org/assignments/ipv4-address-space). Pedants among
us will reply that RFC3330 is informational, not standards-track, but
even so we see phrases like "Each computer on the Internet uses
127.0.0.0/8 to identify itself, to itself" in the IANA description of
special-use addresses.
This raises an interesting question that I could answer if I had code
handy, which is whether TOPS-20 correctly prevents 127/8 addresses
from actually appearing on the net if someone tries to send to them.
This requirement is widely documented, although on reflection I'm not
sure it's formally spec'd in a standard either..
john
28-Feb-2005 01:48:48 -0800,1212;000000000000
Return-Path: <MRC@lingling.panda.com>
Received: via tmail-2002(14) for t20arc; Mon, 28 Feb 2005 01:48:47 -0800 (PST)
Return-Path: <MRC@lingling.panda.com>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id BAA24028; Mon, 28 Feb 2005 01:48:45 -0800 (PST)
Date: Mon, 28 Feb 2005 01:30:50 -0800 (PST)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: Re: 127.0.0.1 Loopback (non-)usage
To: jtw@lcs.mit.edu
cc: slogin@optonline.net, TOPS-20@lingling.panda.com
In-Reply-To: <p06210204be4841b2c666@[192.168.2.4]>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14006195692.9.MRC@lingling.panda.com>
> This raises an interesting question that I could answer if I had code
> handy, which is whether TOPS-20 correctly prevents 127/8 addresses
> from actually appearing on the net if someone tries to send to them.
> This requirement is widely documented, although on reflection I'm not
> sure it's formally spec'd in a standard either..
I don't recall any such code in TOPS-20. Don't forget that the
IP code was last changed in 1990.
It probably would work to put in an appropriate routing entry.
-------
1-Mar-2005 01:44:39 -0800,4971;000000000000
Return-Path: <MRC@Lingling.Panda.COM>
Received: via tmail-2002(14) for t20arc; Tue, 1 Mar 2005 01:44:38 -0800 (PST)
Return-Path: <MRC@Lingling.Panda.COM>
Received: from Lingling.Panda.COM (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id BAA24730; Tue, 1 Mar 2005 01:44:37 -0800 (PST)
Date: Tue, 1 Mar 2005 01:05:54 -0800 (PST)
From: Mark Crispin <MRC@Lingling.Panda.COM>
Subject: new machine instructions added at Panda
To: TOPS-20@Lingling.Panda.COM
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14006453298.9.MRC@Lingling.Panda.COM>
For those of you who may be curious about the new Panda machine instructions,
I've produced the following document.
The KN10 processor used with the Panda monitor is largely
compatible with the DEC KL10 processor. Please refer to the
KLDIFF help file for additional information.
The following machine instructions are added in the KN10
processor for Panda system. Only CIRC is valid in user mode:
247 CIRC Circulate
Circulate AC,AC+1 the number of places specified by E. If E is
positive, circulate AC left; bit 0 is circulated into bit 36 (bit
0 of AC+1) and bit 71 (bit 35 of AC+1) into bit 35. If E is
negative, circulate AC right; bit 35 is circulated into bit 71
and bit 36 into bit 0.
CIRC is colloquially called "a ROTC with AC+1 going the other way."
Example: CIRC AC,^D36 will reverse the order of the bits in AC
and AC+1, leaving the results in AC+1 and AC respectively.
-----------------------------------------------------------------
77004 HSRSW Host Read Switches
Read the contents of the console data switches (set by the "set
sw" console command) into location E.
This instruction requires that the processor be in executive mode
or user IO mode.
Note: the historical instruction DATAI APR, (and
the MACRO RSW mnemonic) DO NOT work because the
KL10 architecture uses that instruction for other
purposes.
-----------------------------------------------------------------
77014 HSLITE Host Display Lights
70054 DATAO PI, Data Out, Console
Display the contents of location E in the console Program Data
indicator lights.
This instruction requires that the processor be in executive mode
or user IO mode.
Note: the historical instruction DATAO PI, works as
an alternative to HSLITE. However, new programs should
use HSLITE because the XKL-1 processor uses that
instruction for other purposes.
-----------------------------------------------------------------
77020 HSWRIT Write to Host
Perform the functions specified by bits 18-35 as follows:
B18 set CPU state register bit
B19 set disk state register bit
B20 set tape state register bit
B21 set network state register bit
B22 display CPU/disk/tape/network state register bits on
light panel and clear state register bits
B23 set auxillary lights from B24-B26
B24-B26 value to be set in auxillary lights if B23 set, otherwise
ignored
B35 idle microcode; processor hangs until next interrupt
Note: the state register bits and the auxillary lights
work differently. The state register bits are set by
ORing with the associated HSWRIT bit and are cleared
by HSWRIT with B22 set. It is possible to set a state
register bit without setting B22. The auxillary lights
are set only if B23 is set; and the three auxillary
lights are set or cleared based upon the value of B24-B26.
This instruction requires that the processor be in executive mode
or user IO mode.
-----------------------------------------------------------------
77024 HSREAD Read from Host
Read the status of the host processor into E as shown:
B0-B17 Host processor signature word, currently always
SIXBIT/KLH/
B18 current CPU state register bit
B19 current disk state register bit
B20 current tape state register bit
B21 current network state register bit
B22 processor supports state register bits
B23 processor supports auxillary lights
B24-B26 current value of auxillary lights
B35 processor supports idling microcode
This instruction requires that the processor be in executive mode
or user IO mode.
-----------------------------------------------------------------
77030 HSRSZ Host Read and Skip if Zero
Test the status of the host processor against the effective mask
E. If all status bits selected by 1s in E are 0s, skip the next
instruction in sequence. Only the right 18 bits are tested.
This instruction requires that the processor be in executive mode
or user IO mode.
-----------------------------------------------------------------
77034 HSRSO Host Read and Skip if One
Test the status of the host processor against the effective mask
E. If any status bit selected by 1s in E is 1, skip the next
instruction in sequence. Only the right 18 bits are tested.
This instruction requires that the processor be in executive mode
or user IO mode.
-------
2-Mar-2005 06:18:13 -0800,6316;000000000000
Return-Path: <slogin@optonline.net>
Received: via tmail-2002(14) for t20arc; Wed, 2 Mar 2005 06:18:12 -0800 (PST)
Return-Path: <slogin@optonline.net>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id GAA25522; Wed, 2 Mar 2005 06:18:11 -0800 (PST)
From: slogin@optonline.net
Received: from mta3.srv.hcvlny.cv.net ([167.206.5.69]) by lingling.panda.com with TCP/SMTP; Wed, 2 Mar 2005 06:00:42 -0800 (PST)
Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta3.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004))
with ESMTP id <0ICQ001TS9L4ZH@mta3.srv.hcvlny.cv.net> for
TOPS-20@lingling.panda.com; Wed, 02 Mar 2005 09:00:40 -0500 (EST)
Received: from [10.240.3.40] (Forwarded-For: [66.114.69.214])
by mstr3.srv.hcvlny.cv.net (mshttpd); Wed, 02 Mar 2005 09:00:40 -0500
Date: Wed, 02 Mar 2005 09:00:40 -0500
Subject: CFOBF% on Internet Extended Mode FTP server startup
To: TOPS-20@lingling.panda.com
Message-id: <2c72a6c2c75e76.2c75e762c72a6c@optonline.net>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004)
Content-type: text/plain; charset=iso-8859-1
Content-language: en
Content-transfer-encoding: quoted-printable
Content-disposition: inline
X-Accept-Language: en
Priority: normal
When the new extended mode FTP server comes up=2C it naturally wants to
type a system banner=2C as per RFC959=2E One of the appropriate things t=
o
do before this is the conditioning the line=2E In addition to seeing
what the Exec does=2C I also looked at Kermit and the BBN FTP server=2E =
I
break links=2C refuse system messages=2C set the terminal type to ideal
(NVT)=2C condition the TTY mode and parameter words (see below) and then
I clear the input and output line buffers=2E
Clearing the terminal output buffer does something unexpected which
breaks certain FTP clients=2E In particular=2C if I do a CFOBF=25 on
=2EPRIOU=2C then a 0x8ff 0x8F2 shows up in the output stream=2E Under
EFTP3=2C this shows up as a =22=FF=F2=22 as the first two characters of t=
he
output stream=2E Under the Windows 2000=2C these are displayed as =22=A0=
=3D=22
(actually greater than or equal to)=2E
Anyway=2C the two character sequence is unexpected for clearing an
output buffer (the program has already done a RESET=25) and it hangs
certain clients that are looking for a 220 or other numeric data as
the first things from the server=2E They gronk on control data=2E
Anybody have any ideas of what is going on=3F I can obviously comment
out the CFOBF=25=2C but I=27m curious as to why this would be happening=2E=
The routine and definitions are below=2E
=5EL SUBTTL SETERM - Conditions NVT line for use
=3B Expects that somebody else has determined whether we should be invoke=
d!
=3B
=3B Note well=2C the order of the calls is specifically to prevent a link=
or
=3B a system message from gumming up the rest of the works=2E We prevent=
these=2C
=3B then set the modes and THEN clear the buffers!
SETERM=3A INTERN SETERM =3B Actually used EFTPSR=2EMAC
DMOVE T1=2C=5BEXP =3CTL=25CRO!TL=25COR!TL=25SAB!TL=25STA!=2ERHALF=
=3E=2C =2ECTTRM=5D
TLINK=25 =3B break and refuse links and advice
ERJMP =2E+1 =3B Ignore ACJ=27s opinion on this =2E=
=2E=2E
MOVX T1=2C=2ECTTRM =3B Following functions on controllin=
g terminal
DMOVE T2=2C=5BEXP =2EMOSNT=2C=2EMOSMN=5D
MTOPR=25 =3B refuse system messages
ERCAL FATAL
MOVX T2=2C=2ETTIDL =3B set controlling terminal type to =
ideal
STTYP=25
ERCAL FATAL
MOVX T2=2CTTYMOD =3B Load JFN mode word
SFMOD=25 =3B Set program related mode
ERCAL FATAL
MOVX T2=2CTTYPAR =3B Load JFN parameter word
STPAR=25 =3B Set device related parameters
ERCAL FATAL
DMOVE T2=2C=5BBYTE (2) 2=2C2=2C2=2C0=2C2=2C2=2C2=2C2=2C2=2C2=2C2=2C=
2=2C2=2C2=2C2=2C2=2C2=2C2
BYTE (2) 2=2C2=2C2=2C2=2C2=2C2=2C2=2C2=2C2=2C2=2C2=2C2=2C=
2=2C2=2C2=2C2=2C2=2C2=5D
SFCOC=25 =3B disable all echoing on controls
ERCAL FATAL
MOVX T1=2C=2EPRIIN
CFIBF=25 =3B clear possible crud in our input bu=
ffer
ERCAL FATAL =3B from an earlier connection
MOVX T1=2C=2EPRIOU
CFOBF=25 =3B plus any junk that might have accum=
ulated
ERCAL FATAL =3B in our output buffer
MOVE T1=2C=5BSIXBIT/EFTPSR/=5D =3B set our name
SETNM=25
ERCAL FATAL =3B Why would that fail=3F=3F
TQO F=25LIN =3B Flag that we did this
RET
=0C
The terminal mode and parameter words are defined in the extended FTP
server universal file and are included=2C below=2E
=3B Standard definitions for NVT server terminal
=3B
=3B Terminal mode word (program local settings)
=3B
=3B TT=25OSP output suppress control (0=3Dallow output)
=3B TT=25WKF Wakeup on formating control chars
=3B TT=25WKN Wakeup on non-formatting controls
=3B TT=25WKP Wakeup on punctuation
=3B TT=25WKA Wakeup on alphanumerics
=3B TT=25ECO Echoes on (0=3Doff)
=3B TT=25DAM Terminal data mode
=3B =2ETTASC ASCII
TTYMOD=3D=3DTT=25WKF!TT=25WKN!TT=25WKP!TT=25WKA!=3CFLD =2ETTASC=2CTT=25DA=
M=3E
=3B Terminal parameter word (device global settings)
=3B
=3B TT=25MFF Mechanical formfeed present
=3B TT=25TAB Mechanical tab present
=3B TT=25LCA Lower case capabilities present
=3B TT=25LEN Page length field (0)
=3B TT=25WID Page width field (0)
=3B TT=25ECM Echo Mode (0=3Doff)
=3B TT=25UOC Upper case output control (0=3Ddo NOT indicate)
=3B TT=25LIC Lower case input control (0=3Dno conversion)
=3B TT=25DUM Duplex mode
=3B =2ETTLDX Line half duplex
=3B TT=25PGM pause-on-command mode (0=3Ddisable)
TTYPAR=3D=3DTT=25MFF!TT=25TAB!TT=25LCA!=3CFLD =2ETTLDX=2CTT=25DUM=3E
2-Mar-2005 13:29:44 -0800,3971;000000000000
Return-Path: <MRC@Lingling.Panda.COM>
Received: via tmail-2002(14) for t20arc; Wed, 2 Mar 2005 13:29:44 -0800 (PST)
Return-Path: <MRC@Lingling.Panda.COM>
Received: from Lingling.Panda.COM (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id NAA25693; Wed, 2 Mar 2005 13:29:42 -0800 (PST)
Received: from mxout5.cac.washington.edu ([140.142.32.135]) by Lingling.Panda.COM with TCP/SMTP; Wed, 2 Mar 2005 13:11:31 -0800 (PST)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
by mxout5.cac.washington.edu (8.13.3+UW05.01/8.13.3+UW05.01) with ESMTP id j22KWkf0022772;
Wed, 2 Mar 2005 12:32:46 -0800
Received: from Shimo-Tomobiki.panda.com (panda.com [206.124.149.114])
(authenticated bits=0)
by smtp.washington.edu (8.13.3+UW05.01/8.13.3+UW05.01) with ESMTP id j22KWQNo015773
(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
Wed, 2 Mar 2005 12:32:40 -0800
Date: Wed, 2 Mar 2005 12:32:19 -0800
From: Mark Crispin <MRC@Lingling.Panda.COM>
To: slogin@optonline.net
cc: TOPS-20@Lingling.Panda.COM
Subject: Re: CFOBF% on Internet Extended Mode FTP server startup
In-Reply-To: <2c72a6c2c75e76.2c75e762c72a6c@optonline.net>
Message-ID: <Pine.WNT.4.63.0503021202310.2964@Shimo-Tomobiki.panda.com>
References: <2c72a6c2c75e76.2c75e762c72a6c@optonline.net>
Organization: Networks & Distributed Computing
Sender: mrc@ndcms.cac.washington.edu
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=ISO-2022-JP; FORMAT=flowed
Content-ID: <Pine.WNT.4.63.0503021210361.2964@Shimo-Tomobiki.panda.com>
On Wed, 2 Mar 2005 slogin@optonline.net wrote:
> Clearing the terminal output buffer does something unexpected which
> breaks certain FTP clients. In particular, if I do a CFOBF% on
> .PRIOU, then a 0x8ff 0x8F2 shows up in the output stream. Under
> EFTP3, this shows up as a "$B[U(B" as the first two characters of the
> output stream. Under the Windows 2000, these are displayed as "$B^!(B"
> (actually greater than or equal to).
0x8ff 0x8f2 are not octets.
Did you mean to say 0xff 0xf2? If so, that is IAC DM, which is perfectly
reasonable to send over FTP. Unlike most other protocols, FTP has TELNET
control commands.
What's more, a CFOBF% on a TVT definitely sends an IAC DM.
> Anyway, the two character sequence is unexpected for clearing an
> output buffer (the program has already done a RESET%) and it hangs
> certain clients that are looking for a 220 or other numeric data as
> the first things from the server. They gronk on control data.
Then that's a bug in those clients.
> Anybody have any ideas of what is going on? I can obviously comment
> out the CFOBF%, but I'm curious as to why this would be happening.
The IMAP server and the SMTP server (back in the days when it ran on TVTs)
do CFIBF% to remove any crud that was still in the TVT input buffer from a
previous session, but they do not do CFOBF%.
As a programming note for the archives:
It is generally a bad idea to run on TVTs. You can not prevent TELNET
protocol from happening on TVTs, and TVTs are much much slower than
redirected JFNs.
This is not a problem for FTP; FTP uses TELNET protocol and doesn't do
substantial I/O on its primary I/O. What's more, it needs to log in so it
needs to be in its own job.
However, it's a problem for SMTP and IMAP, both of which need to do
substantial I/O on primary I/O and neither of which do TELNET protocol.
That is why, these days, SMTP runs as a subfork of SMTJFN and its primary
I/O are redirected JFNs.
The current Panda distribution still runs the IMAP server on a TVT, but I
just looked at the code and discovered to my surprised that I actually did
the work to make it run as a subfork of IMAPSV. That'll be fixed in the
next Panda distribution.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
3-Mar-2005 13:41:41 -0800,1207;000000000000
Return-Path: <MRC@lingling.panda.com>
Received: via tmail-2002(14) for t20arc; Thu, 3 Mar 2005 13:41:41 -0800 (PST)
Return-Path: <MRC@lingling.panda.com>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id NAA26539; Thu, 3 Mar 2005 13:41:39 -0800 (PST)
Date: Thu, 3 Mar 2005 13:24:04 -0800 (PST)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: memory leak (possibly more?) bugfix to IPIPIP.MAC
To: TOPS-20@lingling.panda.com
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14007111966.11.MRC@lingling.panda.com>
At SNDFR5-7, there is the following code sequence:
SKIPLE PKT,T1 ; did we get the space?
POP P,(P) ; Drop T1
MOVE PKT,(P) ; Original PKT
There is a missing instruction here; there should be a JRST
SNDFR5 after the SKIPLE, e.g.:
SKIPLE PKT,T1 ; did we get the space?
JRST SNDFR5 ; yes
POP P,(P) ; Drop T1
MOVE PKT,(P) ; Original PKT
This code comes into play when there are three or more fragments.
At the very least, this causes a memory leak; when GETBLK finally
fails it looks like the stack gets screwed up too.
Thanks to Fred Wright for this bugfix.
-------
3-Mar-2005 15:01:50 -0800,1920;000000000000
Return-Path: <mike@zanker.org>
Received: via tmail-2002(14) for t20arc; Thu, 3 Mar 2005 15:01:50 -0800 (PST)
Return-Path: <mike@zanker.org>
Received: from lingling.panda.com (Lingling.Panda.COM [206.124.149.115]) by Ikkoku-Kan.Panda.COM id PAA26584; Thu, 3 Mar 2005 15:01:48 -0800 (PST)
Received: from mallard.zanker.org ([81.187.169.2]) by lingling.panda.com with TCP/SMTP; Thu, 3 Mar 2005 14:45:59 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=thekey; d=zanker.org;
b=ccUfKjs57QZB9FlXTcAjltDsOQrFSFvM3rYemogvjq6GaSwjAPfjwjaLqq0fCuz5QwWQLuLlh02FRLPC2yRROvWwVOQL6Z7a/tNLmoOEqz6licrYsSQ0fmC12cihlol5;
Received: from jemima.zanker.org ([2001:8b0:f:1:260:8ff:fe49:e6a4] helo=[IPv6:2001:8b0:f:1:260:8ff:fe49:e6a4])
by mallard.zanker.org with esmtpsa (TLSv1:AES256-SHA:256)
(Exim 4.47)
id 1D6z4p-00027y-K7
for TOPS-20@lingling.panda.com; Thu, 03 Mar 2005 22:45:51 +0000
Message-ID: <4227939E.4090004@zanker.org>
Date: Thu, 03 Mar 2005 22:45:50 +0000
From: Mike Zanker <mike@zanker.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: TOPS-20@lingling.panda.com
Subject: Re: memory leak (possibly more?) bugfix to IPIPIP.MAC
References: <14007111966.11.MRC@lingling.panda.com>
In-Reply-To: <14007111966.11.MRC@lingling.panda.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Mallard-MailScanner: Found to be clean (of known viruses)
X-Mallard-MailScanner-From: mike@zanker.org
On 03/03/2005 21:24, Mark Crispin wrote:
> This code comes into play when there are three or more fragments.
> At the very least, this causes a memory leak; when GETBLK finally
> fails it looks like the stack gets screwed up too.
Could this have anything to do with my dying network connection? I've
eliminated everything except network traffic as the cause, I think...
Mike.
13-Mar-2005 23:47:14-PST,539;000000000001
Mail-From: MRC created at 13-Mar-2005 23:40:23
Date: Sun, 13 Mar 2005 23:40:23 -0800 (PST)
From: Mark Crispin <MRC@Lingling.Panda.COM>
Subject: lights panel available from Spare Time Gizmos
To: TOPS-20@Lingling.Panda.COM
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14009845603.10.MRC@Lingling.Panda.COM>
If you are interested in getting a lights panel for your own KLH10-based
TOPS-20 system, Spare Time Gizmos is now offering it:
http://www.sparetimegizmos.com/Hardware/Panda.htm
-------
17-Mar-2005 21:06:26-PST,1141;000000000000
Mail-From: MRC created at 17-Mar-2005 21:00:33
Date: Thu, 17 Mar 2005 21:00:33 -0800 (PST)
From: Mark Crispin <MRC@Lingling.Panda.COM>
Subject: bug in JRA instruction in KLH10
To: TOPS-20@Lingling.Panda.COM
cc: KLH@panix.com
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14010865080.10.MRC@Lingling.Panda.COM>
Problem:
JRA instruction jumps to the wrong place when running in a
non-zero section.
Diagnosis:
KLH10 is jumping to the effective address, which in a non-zero
section will have the AC restore address as a section number.
JRA jumps must always be intra-section
Solution:
In the KLH10 source module injrst.c, in routine i_jra(), change:
PC_JUMP(e); /* Jump to E */
to:
va_lmake(va, PC_SECT, va_insect(e));
PC_JUMP(va); / Jump to PC section,,RH(E) */
Thanks to Fred Wright for telling me about this problem.
[And you thought that nobody ever used JSA/JRA any more! :-)]
-- Mark --
http://panda.com/tops-20
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
-------
17-Mar-2005 22:34:52-PST,2476;000000000000
Return-Path: <klh@panix.com>
Received: from mail1.panix.com ([166.84.1.72]) by Lingling.Panda.COM with TCP/SMTP; Thu, 17 Mar 2005 22:28:30 -0800 (PST)
Received: from panix1.panix.com (panix1.panix.com [166.84.1.1])
by mail1.panix.com (Postfix) with ESMTP id 1317458AD3;
Fri, 18 Mar 2005 01:28:30 -0500 (EST)
Received: (from klh@localhost)
by panix1.panix.com (8.11.6p3/8.8.8/PanixN1.1) id j2I6SU806207;
Fri, 18 Mar 2005 01:28:30 -0500 (EST)
Date: Fri, 18 Mar 2005 1:28:30 EST
From: Ken Harrenstien <klh@panix.com>
To: Mark Crispin <MRC@Lingling.Panda.COM>
Cc: TOPS-20@Lingling.Panda.COM, KLH@panix.com
Subject: Re: bug in JRA instruction in KLH10
In-Reply-To: Your message of Thu, 17 Mar 2005 21:00:33 -0800 (PST)
Message-ID: <CMM.0.91.0.1111127310.klh@panix1.panix.com>
> Problem:
> JRA instruction jumps to the wrong place when running in a
> non-zero section.
>
> Diagnosis:
> KLH10 is jumping to the effective address, which in a non-zero
> section will have the AC restore address as a section number.
> JRA jumps must always be intra-section
I had to look at the code, the PRM, and the microcode to figure out
what was going on here. The only thing I couldn't do was run a test
on a real KL.
I would disagree with the diagnosis. The AC restore address has
nothing whatsoever to do with the effective address, which is computed
(just like every other EA) before i_jra() is called. The KLH10 code
is treating the jump just like any other jump, per the PRM
description.
What's really going on is that the KL microcode implementing JRA
appears to be buggy to begin with, and its actual behavior was never
documented in the PRM. From KLX.MCR:
JRA: AR12-17_PC SEC ;[235] put section in jump address.
My interpretation is that this forces the EA to always be clobbered
with the current PC section. No other jump instruction appears to be
similarly crippled (although where the ucode is concerned, one can
never be completely sure of anything).
> Solution:
> In the KLH10 source module injrst.c, in routine i_jra(), change:
> PC_JUMP(e); /* Jump to E */
> to:
> va_lmake(va, PC_SECT, va_insect(e));
> PC_JUMP(va); / Jump to PC section,,RH(E) */
This should work. (Don't forget to make that a "/* Jump" instead of
"/ Jump" :-)
> Thanks to Fred Wright for telling me about this problem.
>
> [And you thought that nobody ever used JSA/JRA any more! :-)]
Indeed!
--Ken
17-Mar-2005 23:53:22-PST,476;000000000000
Mail-From: MRC created at 17-Mar-2005 23:48:08
Date: Thu, 17 Mar 2005 23:48:08 -0800 (PST)
From: Mark Crispin <MRC@Lingling.Panda.COM>
Subject: JRA and extended addressing
To: TOPS-20@Lingling.Panda.COM
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14010895590.11.MRC@Lingling.Panda.COM>
I gave Ken a pointer to EXTENDED_ADDRESSING.MEM which is the real
documentation of how extended addressing works (unlike the PRM...).
-------
18-Mar-2005 15:17:34-PST,1375;000000000000
Return-Path: <GORIN@toed.xkl.com>
Received: from toed.xkl.com ([192.94.202.46]) by Lingling.Panda.COM with TCP/SMTP; Fri, 18 Mar 2005 15:12:09 -0800 (PST)
Date: Fri, 18 Mar 2005 15:09:24 -0800
From: Ralph Gorin <Gorin@toed.xkl.com>
Subject: Re: bug in JRA instruction in KLH10
To: klh@panix.com
cc: MRC@lingling.panda.com, TOPS-20@lingling.panda.com
In-Reply-To: <CMM.0.91.0.1111127310.klh@panix1.panix.com>
Reply-to: gorin@xkl.com
Message-ID: <14011063301.9.GORIN@toed.xkl.com>
Gents,
Although the behavior of JSA/JRA is incompletely described in DEC's
processor reference manual, it is discussed in some detail in
the "Extended Addressing" memorandum, revision 5, dating from July 1983.
The grammar leaves a lot to be desired, but the meaning is clear enough:
The normal usage of JRA is of the form JRA AC,(AC) and the
operation of the instruction is defined to take this into account.
After the normal effective address calculation is performed, PC
section is appended to the in-section addresses in AC to form the
address of where the old contents of AC were stored and the new PC
address. This forces all references to be in PC section.
The KL10 microcode that Ken quotes forces E to be in the PC section.
The AC restore address must be forced into a section also.
Ralph
-------
19-Mar-2005 22:22:41-PST,7308;000000000000
Return-Path: <fw@well.com>
Received: from a.mail.sonic.net ([64.142.16.245]) by lingling.panda.com with TCP/SMTP; Sat, 19 Mar 2005 22:17:58 -0800 (PST)
Received: from Amiga.local (64-142-29-113.dsl.static.sonic.net [64.142.29.113])
by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j2K6Hw5S028348
for <TOPS-20@Lingling.Panda.COM>; Sat, 19 Mar 2005 22:17:58 -0800
Date: Sat, 19 Mar 2005 22:17:58 -0800 (PST)
From: Fred Wright <fw@well.com>
X-Sender: fw@Amiga.local
Reply-To: Fred Wright <fw@well.com>
To: TOPS-20@Lingling.Panda.COM
Subject: Re: bug in JRA instruction in KLH10
In-Reply-To: <14011063301.9.GORIN@toed.xkl.com>
Message-ID: <Pine.AMI.4.21.0503192136160.173494936-200000@Amiga.local>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-469368732-1111299478=:173494936"
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
---559023410-469368732-1111299478=:173494936
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 18 Mar 2005, Ken Harrenstien wrote:
> > Problem:
> > JRA instruction jumps to the wrong place when running in a
> > non-zero section.
> >
> > Diagnosis:
> > KLH10 is jumping to the effective address, which in a non-zero
> > section will have the AC restore address as a section number.
> > JRA jumps must always be intra-section
>
> I had to look at the code, the PRM, and the microcode to figure out
> what was going on here. The only thing I couldn't do was run a test
> on a real KL.
Whassamatta, you not willing to take the word of someone who's written
PDP-10 extended addressing microcode that runs TOPS-10 and TOPS-20
and passes all the diagnostics? :-)
> I would disagree with the diagnosis. The AC restore address has
> nothing whatsoever to do with the effective address, which is computed
It has nothing *directly* to do with it, but in normal usage one has:
JRA AC,x(AC) ;x being the desired number of skips
where AC contains FOO,,BAR with FOO being the location of the saved AC and
BAR the saved PC.
> (just like every other EA) before i_jra() is called. The KLH10 code
Exactly. And unless FOO >= 400000 (or FOO&7777 == 0), in a nonzero
section this takes the low 12 bits of FOO as the section number for the
jump, which is almost always the wrong thing.
> is treating the jump just like any other jump, per the PRM
> description.
The PRM lies, in this as well as other cases. :-)
> What's really going on is that the KL microcode implementing JRA
> appears to be buggy to begin with, and its actual behavior was never
> documented in the PRM. From KLX.MCR:
>
> JRA: AR12-17_PC SEC ;[235] put section in jump address.
>
> My interpretation is that this forces the EA to always be clobbered
> with the current PC section. No other jump instruction appears to be
> similarly crippled (although where the ucode is concerned, one can
> never be completely sure of anything).
If JRA behaved consistently with other instructions, it would be virtually
useless when running extended. DEC chose usefulness over consistency.
It would have been less "crippled" if this kludge had been applied only
when XR==AC, but that would have needed extra hardware (and probably extra
time). Thus, you can't do something like
JRA AC,@[BAR]
to JRA to another section.
> > Solution:
> > In the KLH10 source module injrst.c, in routine i_jra(), change:
> > PC_JUMP(e); /* Jump to E */
> > to:
> > va_lmake(va, PC_SECT, va_insect(e));
> > PC_JUMP(va); / Jump to PC section,,RH(E) */
>
> This should work. (Don't forget to make that a "/* Jump" instead of
> "/ Jump" :-)
Actually, I did it slightly differently, in that I used
va_setinsect(va, va_insect(e)); /* Form PC sect,,E */
to form the address. That exploits the fact that VA is already a local
address in the correct section, and merely needs the in-section part
replaced by RH(E) to form the correct jump address.
I attached the complete diff as I implemented it. The conditional is
there mostly for informational purposes regarding the "old way", and isn't
logically required.
> > [And you thought that nobody ever used JSA/JRA any more! :-)]
>
> Indeed!
Actually, I didn't write the JRAs that caused trouble (in BACKUP's AC
save/restore coroutines), but I did make the previously section-0-only
code run extended, and there was no need to "fix" the JRAs on a properly
working processor.
On Fri, 18 Mar 2005, Ralph Gorin wrote:
> Although the behavior of JSA/JRA is incompletely described in DEC's
> processor reference manual, it is discussed in some detail in
> the "Extended Addressing" memorandum, revision 5, dating from July 1983.
Fortunately we had a copy of that when writing the SC30 microcode.
> The grammar leaves a lot to be desired, but the meaning is clear enough:
>
> The normal usage of JRA is of the form JRA AC,(AC) and the
> operation of the instruction is defined to take this into account.
> After the normal effective address calculation is performed, PC
> section is appended to the in-section addresses in AC to form the
> address of where the old contents of AC were stored and the new PC
> address. This forces all references to be in PC section.
>
> The KL10 microcode that Ken quotes forces E to be in the PC section.
> The AC restore address must be forced into a section also.
Yes, although the latter part is pretty much obvious given that the AC
restore address is unequivocally an 18-bit (and hence local) address. E,
however, is always a 30-bit address even when it's local, since it's
possible to have a local address in a different section. Any application
of "PC section" normally occurs during the EA calculation, not the
instruction execution, with the local/global flag being retained only to
determine increment style and which sections contain ACs. Hence, using PC
section is natural for the AC restore, but a special kludge for the jump
address.
Fred Wright
---559023410-469368732-1111299478=:173494936
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="injrst.diff"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.AMI.4.21.0503192217580.173494936@Amiga.local>
Content-Description:
Content-Disposition: attachment; filename="injrst.diff"
LS0tIGtsaDEwLTIuMGgtZncvc3JjL2luanJzdC5jLm9yaWcJVGh1IE1hciAy
MSAwMTo1MTozNyAyMDAyDQorKysga2xoMTAtMi4waC1mdy9zcmMvaW5qcnN0
LmMJRnJpIEp1bCAzMCAwMDo0NDowOCAyMDA0DQpAQCAtMTE2LDcgKzExNiwx
MiBAQA0KIA0KICAgICB2YV9sbWFrZSh2YSwgUENfU0VDVCxhY19nZXRsaChh
YykpOwkvKiBNYWtlIEFDLmxoIGEgbG9jYWwgYWRkcmVzcyAqLw0KICAgICBh
Y19zZXQoYWMsIHZtX3JlYWQodmEpKTsJCS8qIEdldCBjKEFDLmxoKSBpbnRv
IEFDICovDQorI2lmICFLTEgxMF9FWFRBRFIJCS8qIEZpeGVkIHRoaXMgZm9y
IGV4dGVuZGVkIGNhc2UgLSBGVyAqLw0KICAgICBQQ19KVU1QKGUpOwkJCQkv
KiBKdW1wIHRvIEUgKi8NCisjZWxzZQ0KKwl2YV9zZXRpbnNlY3QodmEsIHZh
X2luc2VjdChlKSk7CS8qIEZvcm0gUEMgc2VjdCwsRSAqLw0KKwlQQ19KVU1Q
KHZhKTsJCQkJCS8qIEp1bXAgdGhlcmUgKi8NCisjZW5kaWYNCiAgICAgcmV0
dXJuIFBDSU5DXzA7DQogfQ0KIAwNCg==
---559023410-469368732-1111299478=:173494936--
20-Mar-2005 09:15:16-PST,3680;000000000000
Return-Path: <MRC@lingling.panda.com>
Received: from mxout5.cac.washington.edu ([140.142.32.135]) by lingling.panda.com with TCP/SMTP; Sun, 20 Mar 2005 09:10:40 -0800 (PST)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
by mxout5.cac.washington.edu (8.13.3+UW05.01/8.13.3+UW05.01) with ESMTP id j2KHAfTW032672;
Sun, 20 Mar 2005 09:10:41 -0800
Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.37.170])
(authenticated bits=0)
by smtp.washington.edu (8.13.3+UW05.01/8.13.3+UW05.01) with ESMTP id j2KHAe9R016179
(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT);
Sun, 20 Mar 2005 09:10:40 -0800
Date: Sun, 20 Mar 2005 09:10:40 -0800 (PST)
From: Mark Crispin <MRC@lingling.panda.com>
Sender: mrc@shiva0.cac.washington.edu
To: Fred Wright <fw@well.com>
cc: TOPS-20@lingling.panda.com
Subject: Re: bug in JRA instruction in KLH10
In-Reply-To: <Pine.AMI.4.21.0503192136160.173494936-200000@Amiga.local>
Message-ID: <Pine.LNX.4.63.0503200850020.5965@shiva0.cac.washington.edu>
References: <Pine.AMI.4.21.0503192136160.173494936-200000@Amiga.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed
Content-ID: <Pine.LNX.4.63.0503200850022.5965@shiva0.cac.washington.edu>
On Sat, 19 Mar 2005, Fred Wright wrote:
> Whassamatta, you not willing to take the word of someone who's written
> PDP-10 extended addressing microcode that runs TOPS-10 and TOPS-20
> and passes all the diagnostics? :-)
I think that we can stipulate that Fred's expertise is unquestioned on
this mailing list. We're not a newsgroup here! :-) :-)
> It would have been less "crippled" if this kludge had been applied only
> when XR==AC, but that would have needed extra hardware (and probably extra
> time). Thus, you can't do something like
> JRA AC,@[BAR]
> to JRA to another section.
However, if I understand things correctly, indirection *can* reference
other sections during the EA calculation via a GFIW; it's just the final
value of E which is coerced to the PC section.
I can't imagine how this would be useful. Although I wager that, if we
said that in Stew Nelson's presence, he'd come up with something. :-)
> Actually, I did it slightly differently, in that I used
> va_setinsect(va, va_insect(e)); /* Form PC sect,,E */
> to form the address. That exploits the fact that VA is already a local
> address in the correct section, and merely needs the in-section part
> replaced by RH(E) to form the correct jump address.
I'm neutral on which patch to use, and am willing to punt the decision to
Ken. I doubt that it makes a significant performance difference either
way. Fred's patch may be faster, my patch may be less likely to break if
someone ever changes the i_jra() code in the future without looking
carefully.
> Actually, I didn't write the JRAs that caused trouble (in BACKUP's AC
> save/restore coroutines), but I did make the previously section-0-only
> code run extended, and there was no need to "fix" the JRAs on a properly
> working processor.
Wow. I don't know what amazes me me more, the fact that BACKUP uses
JSA/JRA or that you made it run in a non-zero section.
This sounds like a fascinating story. Care to tell it?
>> the "Extended Addressing" memorandum, revision 5, dating from July 1983.
> Fortunately we had a copy of that when writing the SC30 microcode.
Ken has that document; he just overlooked the section about JSA/JRA.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
20-Mar-2005 09:20:29-PST,1042;000000000000
Mail-From: MRC created at 20-Mar-2005 09:16:17
Date: Sun, 20 Mar 2005 09:16:17 -0800 (PST)
From: Mark Crispin <MRC@Lingling.Panda.COM>
Subject: CONS?
To: TOPS-20@Lingling.Panda.COM
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14011523305.10.MRC@lingling.panda.com>
Does anyone know how CONS worked on the Stanford PDP-6? The only
documentation that I have about it is "read the prints" and the
paper tape of the source of the CONS diagnostic. The Stanford
PDP-6 was, sadly, donated to the Computer Museum which destroyed
it.
Although we are using opcode 247 for CIRC (which is definitely
more useful), I think that there is hack value in implementing
CONS in the 7xx space. I suspect that it's hopelessly tied to
section 0 though.
If someone in the Seattle area has a paper tape reader and is willing
to read that tape, please let me know. It's definitely an ASCII
tape. People more distant have offered to read it, but I don't
want to let that tape out of my sight.
-------
20-Mar-2005 14:21:17-PST,2638;000000000000
Return-Path: <AMartin.MA.UltraNet@RCN.Com>
Received: from smtp04.mrf.mail.rcn.net ([207.172.4.63]) by lingling.panda.com with TCP/SMTP; Sun, 20 Mar 2005 14:15:57 -0800 (PST)
Received: from 207-172-216-226.s988.apx1.sbo.ma.dialup.rcn.com (HELO RCN.Com) (207.172.216.226)
by smtp04.mrf.mail.rcn.net with ESMTP; 20 Mar 2005 17:15:55 -0500
Message-ID: <423DF621.863B1C5B@RCN.Com>
Date: Sun, 20 Mar 2005 17:16:01 -0500
From: "Alan H. Martin" <AMartin.MA.UltraNet@RCN.Com>
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en,en-US,en-GB,es
MIME-Version: 1.0
To: TOPS-20@lingling.panda.com
Subject: Re: bug in JRA instruction in KLH10
References: <Pine.AMI.4.21.0503192136160.173494936-200000@Amiga.local> <Pine.LNX.4.63.0503200850020.5965@shiva0.cac.washington.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Mark Crispin wrote:
>
> On Sat, 19 Mar 2005, Fred Wright wrote:
...
> > Actually, I didn't write the JRAs that caused trouble (in BACKUP's AC
> > save/restore coroutines), but I did make the previously section-0-only
> > code run extended, and there was no need to "fix" the JRAs on a properly
> > working processor.
>
> Wow. I don't know what amazes me me more, the fact that BACKUP uses
> JSA/JRA ...
BACKUP.MAC (the command scanner) calls .SAVE1 in the .SAVE module of
SCAN:
"
;%4(275) DEC, 1973
...
;307 IMPLEMENT D.TODD'S LATEST .SAVEN
...
;%6(370) JULY, 1974
...
;521 IMPROVE SAVEN ROUTINES EVEN MORE
...
;.SAVE1 -- SUBROUTINE TO SAVE P1 FOR A SUBROUTINE
;CALL: PUSHJ P,.SAVE1
;RETURN POPJ OR .POPJ1, RESTORES P1 AND EXITS AS SKIP OR NON-SKIP
.SAVE1::EXCH P1,(P) ;SAVE P1, GET CALLER PC
HRLI P1,(P) ;GET ADDRESS WHERE P1 IS SAVED [307,521]
PUSHJ P,SAVJMP ;STACK NEW RETURN PC AND JUMP [521]
SOS -1(P) ;NON-SKIP RETURN, COMPENSATE .POPJ1 [521]
JRST RET1 ;RESTORE P1 AND EXIT
...
RET1: POP P,P1 ;RESTORE P1
.POPJ1::AOS (P) ;INCREMENT PC [521]
.POPJ:: POPJ P, ;RETURN
;THE FOLLOWING INSTRUCTION RETSTORES P1 AND DISPATCHES TO THE CALLER.
SAVJMP: JRA P1,(P1) ;RETURN TO CALLER [521]
"
SCAN itself can call all of .SAVE1-.SAVE4 for one reason or another.
BACKRS.MAC (where the rubber hits the road) has similar routines SAVE1-
SAVE4:
"
SAVE1: EXCH P1,(P)
PUSH P,.+3
HRLI P1,-1(P)
JRA P1,(P1)
CAIA .
AOS -1(P)
JRST POP1
...
POP1: POP P,P1
POPJ P,0
"
Note that there are no uses of JSA in SCAN, BACKUP or BACKRS, just some
JRAs.
/AHM
--
Alan Howard Martin AMartin.MA.UltraNet@RCN.Com
20-Mar-2005 16:04:12-PST,3616;000000000000
Return-Path: <fw@well.com>
Received: from a.mail.sonic.net ([64.142.16.245]) by lingling.panda.com with TCP/SMTP; Sun, 20 Mar 2005 15:59:51 -0800 (PST)
Received: from [172.24.0.5] (64-142-29-113.dsl.static.sonic.net [64.142.29.113])
(authenticated bits=0)
by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j2KNxmLI009488
(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
for <TOPS-20@lingling.panda.com>; Sun, 20 Mar 2005 15:59:51 -0800
Date: Sun, 20 Mar 2005 15:59:48 -0800
From: Fred Wright <fw@well.com>
Reply-To: Fred Wright <fw@well.com>
To: TOPS-20@lingling.panda.com
Subject: Re: bug in JRA instruction in KLH10
Message-ID: <1D1ED96D2E8CA364CDDC99D9@[172.24.0.5]>
In-Reply-To: <Pine.LNX.4.63.0503200850020.5965@shiva0.cac.washington.edu>
References: <Pine.AMI.4.21.0503192136160.173494936-200000@Amiga.local>
<Pine.LNX.4.63.0503200850020.5965@shiva0.cac.washington.edu>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--On Sunday, March 20, 2005 9:10 AM -0800 Mark Crispin
<MRC@lingling.panda.com> wrote:
> On Sat, 19 Mar 2005, Fred Wright wrote:
>> Whassamatta, you not willing to take the word of someone who's written
>> PDP-10 extended addressing microcode that runs TOPS-10 and TOPS-20
>> and passes all the diagnostics? :-)
>
> I think that we can stipulate that Fred's expertise is unquestioned on
> this mailing list. We're not a newsgroup here! :-) :-)
Anyone need any consulting? No smiley.
>> It would have been less "crippled" if this kludge had been applied only
>> when XR==AC, but that would have needed extra hardware (and probably
>> extra time). Thus, you can't do something like
>> JRA AC,@[BAR]
>> to JRA to another section.
>
> However, if I understand things correctly, indirection *can* reference
> other sections during the EA calculation via a GFIW; it's just the final
> value of E which is coerced to the PC section.
Exactly. As always, the EA calc is oblivious to the opcode. But the
section coercion renders constructs like the above pretty useless, which is
what I was getting at.
> I can't imagine how this would be useful. Although I wager that, if we
> said that in Stew Nelson's presence, he'd come up with something. :-)
Yeah, I imagine the guy who saw FSC as "add immediate to opcode" (until DEC
spoiled the fun by making it normalize) could think of something. :-)
>> Actually, I didn't write the JRAs that caused trouble (in BACKUP's AC
>> save/restore coroutines), but I did make the previously section-0-only
>> code run extended, and there was no need to "fix" the JRAs on a properly
>> working processor.
>
> Wow. I don't know what amazes me me more, the fact that BACKUP uses
> JSA/JRA or that you made it run in a non-zero section.
>
> This sounds like a fascinating story. Care to tell it?
I didn't make all of BACKUP run extended by a long shot, and certainly not
SCAN. But I did make enough of the code run extended (as well as fixing a
number of monitor bugs related to extended buffered-mode I/O) to allow it
to use an extended section for the tape buffers, so that it could buffer
more data. On helical-scan drives, not keeping up with the tape isn't
merely a performance issue - it's also a reliability issue due to the
effects of all the "tape rocking". Of course that was before the more
recent "fix" for the tape-rocking problem, which was to teach it to dump on
DVD-RAM. :-)
Fred Wright
20-Mar-2005 16:40:29-PST,3849;000000000000
Return-Path: <fw@well.com>
Received: from a.mail.sonic.net ([64.142.16.245]) by lingling.panda.com with TCP/SMTP; Sun, 20 Mar 2005 16:36:11 -0800 (PST)
Received: from [172.24.0.5] (64-142-29-113.dsl.static.sonic.net [64.142.29.113])
(authenticated bits=0)
by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j2L0a4mg015961
(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
for <TOPS-20@lingling.panda.com>; Sun, 20 Mar 2005 16:36:07 -0800
Date: Sun, 20 Mar 2005 16:36:05 -0800
From: Fred Wright <fw@well.com>
Reply-To: Fred Wright <fw@well.com>
To: TOPS-20@lingling.panda.com
Subject: Re: CONS?
Message-ID: <E170671EAC1AEFA5067496ED@[172.24.0.5]>
In-Reply-To: <14011523305.10.MRC@lingling.panda.com>
References: <14011523305.10.MRC@lingling.panda.com>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--On Sunday, March 20, 2005 9:16 AM -0800 Mark Crispin
<MRC@lingling.panda.com> wrote:
> Does anyone know how CONS worked on the Stanford PDP-6? The only
> documentation that I have about it is "read the prints" and the
> paper tape of the source of the CONS diagnostic. The Stanford
> PDP-6 was, sadly, donated to the Computer Museum which destroyed
> it.
Bruce Baumgart has been transferring a lot of stuff from old DART tapes to
CD. If the CONS diagnostic source was still on disk at that time it's
probably been preserved. I have a CD he gave me, but only with "FW" files.
> Although we are using opcode 247 for CIRC (which is definitely
Which is much harder to do in software. Though it's also hard (and slow)
in hardware that uses a barrel shifter and doesn't have a bit-reversing
data path.
That's a problem with committing to making it a part of the architecture -
sure it's an easy mod to a machine with an old bit-serial shifter, but is
it worth forcing every modern design to include the extra data path?
The SC15 had a bit-reversing data path because it needed to make a one-way
shift register sometimes shift the other way. At one point, I implemented
a "reverse bits" instruction by removing the wire that prevented its
existence. :-)
> more useful), I think that there is hack value in implementing
> CONS in the 7xx space. I suspect that it's hopelessly tied to
> section 0 though.
I actually doubt that there's much value in CONS, since it's so
memory-bound that you don't gain much by making a single instruction out of
it. Note that Stanford never bothered implementing it on the KA.
The SC30 and SC40 have some special LISP instructions, but CONS isn't among
them. This was to speed up some of the Common LISP stuff that used runtime
data types. Originally, all of the operators were calls to subroutines
that handled all the combinations of data types. The special instructions
dispatch on the data types and "cherry pick" the easy cases to do quickly,
with a skip in those cases. The other cases fall through to the same old
subroutine call. So the common cases get sped up significantly without
having to implement the hairier cases in the microcode.
The Common LISP updated to exploit the new instructions ran benchmarks
around a factor of 5 faster than the standard version. Who says that
performance is always gained by moving complexity *out of* the processor?
:-)
> If someone in the Seattle area has a paper tape reader and is willing
> to read that tape, please let me know. It's definitely an ASCII
> tape. People more distant have offered to read it, but I don't
> want to let that tape out of my sight.
Or you could pull the tape past a video camera. Then, recovering the data
is just a small matter of software. :-)
Fred Wright
20-Mar-2005 16:52:29-PST,1155;000000000000
Mail-From: MRC created at 20-Mar-2005 16:48:17
Date: Sun, 20 Mar 2005 16:48:17 -0800 (PST)
From: Mark Crispin <MRC@Lingling.Panda.COM>
Subject: Re: bug in JRA instruction in KLH10
To: AMartin.MA.UltraNet@RCN.Com
cc: TOPS-20@Lingling.Panda.COM
In-Reply-To: <423DF621.863B1C5B@RCN.Com>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14011605591.14.MRC@lingling.panda.com>
> BACKUP.MAC (the command scanner) calls .SAVE1 in the .SAVE module of
> SCAN:
Wow. At least they didn't use JSA.
I guess they didn't want to use a scratch AC for JSP (ala MACSYM)
which would have been fewer instructions:
JSP CX,.SAVE1
.SAVE1: PUSH P,P1
PUSHJ P,(CX)
TRNA
AOS -1(P)
POP P,P1
POPJ P,
You can also do (assuming I haven't brain-farted):
PUSHJ P,.SAVE1
.SAVE1: POP P,OLDPC
PUSH P,P1
PUSHJ P,@OLDPC
TRNA
AOS -1(P)
POP P,P1
POPJ P,
which is the same number of memory locations but one less machine
instruction (but OLDPC can be used by other .SAVEx routines).
So, other than being a hack that actually uses JRA, I don't see
much value to doing it that way.
-------
20-Mar-2005 17:21:23-PST,1649;000000000000
Mail-From: MRC created at 20-Mar-2005 17:16:48
Date: Sun, 20 Mar 2005 17:16:48 -0800 (PST)
From: Mark Crispin <MRC@Lingling.Panda.COM>
Subject: Re: CONS?
To: fw@well.com
cc: TOPS-20@Lingling.Panda.COM
In-Reply-To: <E170671EAC1AEFA5067496ED@[172.24.0.5]>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14011610781.14.MRC@lingling.panda.com>
> Bruce Baumgart has been transferring a lot of stuff from old DART tapes to
> CD. If the CONS diagnostic source was still on disk at that time it's
> probably been preserved. I have a CD he gave me, but only with "FW" files.
It was long gone from disk (if it was ever there) in 1977 when I
started work at SAIL.
Is your SAILDART CD still readable? Mine isn't; I think that
maybe the label he used is corrosive.
> That's a problem with committing to making it a part of the architecture -
> sure it's an easy mod to a machine with an old bit-serial shifter, but is
> it worth forcing every modern design to include the extra data path?
Well, you need some number of data paths to do ROTC. If you can
reverse the bits in a word, then CIRC AC,n is equivalent to:
<reverse AC+1>
ROTC AC,n
<reverse AC+1>
> I actually doubt that there's much value in CONS, since it's so
> memory-bound that you don't gain much by making a single instruction out of
> it. Note that Stanford never bothered implementing it on the KA.
I don't think that Stanford LISP ever used it on the PDP-6
either. I remain curious as to what it did. It had to be simple
enough to implement on the PDP-6, yet complex enough to be worth doing.
-------
20-Mar-2005 18:36:52-PST,3091;000000000000
Return-Path: <slogin@optonline.net>
Received: from mta1.srv.hcvlny.cv.net ([167.206.4.196]) by lingling.panda.com with TCP/SMTP; Sun, 20 Mar 2005 18:32:31 -0800 (PST)
Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta1.srv.hcvlny.cv.net
(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004))
with ESMTP id <0IDO000NWKEKQY@mta1.srv.hcvlny.cv.net> for
TOPS-20@lingling.panda.com; Sun, 20 Mar 2005 21:32:44 -0500 (EST)
Received: from [10.240.3.41] (Forwarded-For: [24.47.48.231])
by mstr3.srv.hcvlny.cv.net (mshttpd); Sun, 20 Mar 2005 21:32:30 -0500
Date: Sun, 20 Mar 2005 21:32:30 -0500
From: slogin@optonline.net
Subject: BBN FTPSER one bit width byte processing observations
To: TOPS-20@lingling.panda.com
Message-id: <4202aaa42018ab.42018ab4202aaa@optonline.net>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
I've been doing some regression testing on my new FTP server (EFTPSR).
The data conversion routines that I've been writing to support the
various bit formats that the PDP-10 supports are complex to me and
I've wanted to make sure everything is compatible and correct by doing
a lot of double checking.
Thus far, ASCII mode is completely implemented, debugged and known to
be good. PAGED mode is not implemented. IMAGE mode is partially
implemented. Code to support 8 bit mode exists, is completely
debugged and is known to be good. 16 and 32 bit mode code exists, is
debugged and is strongly suspected to be okay since it is part of the
8 bit code.
So, I've got 33 more byte widths to implement and test... An
arbitrary wrapper/driver routine exists for all cases and is coded to
handle a lot of the house keeping chores for the lower level bit
bangers. I finished the one bit byte code earlier this weekend and
began testing it against the BBN FTP server (FTPSER). Boy was I
surprised to find that FTPSER chopped off the entire end of a test
file!
It's definately doing it; for one transfer, it didn't deliver a little
over one K of the tail of the file. The good news, however, is that
the beginning of the transferred files match perfectly and decode
properly when transferred back. A RETR to EFTPSR sends the entire
file while FTPSER doesn't deliver the last K or so. So, interesting
... I don't have any other information about this, other than it's
definately happening and is repeatable.
Anybody have any ideas? I hesitate to flat out call this a bug
because it's hard to see how it could have escaped detection for all
these years. I'd assume that a one bit file format would have been
used to transmit early monochrome picture data. If that is the case,
then I would guess that this would have been bumped into before. One
wonders if this is a problem with how FTPSER is closing the data
connection and not necessarily with the bit bangers.
20-Mar-2005 19:24:35-PST,2179;000000000000
Mail-From: MRC created at 20-Mar-2005 19:20:18
Date: Sun, 20 Mar 2005 19:20:18 -0800 (PST)
From: Mark Crispin <MRC@Lingling.Panda.COM>
Subject: Re: BBN FTPSER one bit width byte processing observations
To: slogin@optonline.net
cc: TOPS-20@Lingling.Panda.COM
In-Reply-To: <4202aaa42018ab.42018ab4202aaa@optonline.net>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14011633262.10.MRC@lingling.panda.com>
> Thus far, ASCII mode is completely implemented, debugged and known to
> be good. PAGED mode is not implemented. IMAGE mode is partially
> implemented. Code to support 8 bit mode exists, is completely
> debugged and is known to be good. 16 and 32 bit mode code exists, is
> debugged and is strongly suspected to be okay since it is part of the
> 8 bit code.
This is strictly IMHO,...
The following modes are important:
(1) ASCII mode (TYPE A)
-> generic
(2) IMAGE mode in bytesize 36 (TYPE I and TYPE L 36)
-> ITS, WAITS, TOPS-10
(3) IMAGE mode in bytesize 8 (TYPE L 8)
-> UNIX, Windows, VMS, etc.
(4) PAGED mode (STRU P with TYPE L 36)
-> TOPS-20
Although 16 and 32-bit IMAGE modes are easy enough to do, they
aren't particularly interesting or useful due to the little
endian problem.
Consequently, rather than implement other byte sizes, I strongly
recommend that you get PAGED and 36-bit IMAGE mode working.
I don't see any point to implementing any TYPE L values other
than 8 and 36. Note that in PAGED mode, even odd-sized files are
still transferred with an underlying TYPE L 36.
> I hesitate to flat out call this a bug
> because it's hard to see how it could have escaped detection for all
> these years.
I call it a bug. I very much doubt that anyone before you has
ever attempted to send a 1-bit bytesize file via a "TYPE L 1"
transfer in FTP.
> I'd assume that a one bit file format would have been
> used to transmit early monochrome picture data.
Even if it was a 1-bit file format on TOPS-20, it would have been
transmitted as PAGED to other TOPS-20 systems.
On UNIX systems, it would have just been an 8-bit bytesize file.
-- Mark --
-------
25-Mar-2005 21:58:44-PST,1036;000000000000
Mail-From: MRC created at 25-Mar-2005 21:54:11
Date: Fri, 25 Mar 2005 21:54:11 -0800 (PST)
From: Mark Crispin <MRC@Lingling.Panda.COM>
Subject: bug in PA1050
To: TOPS-20@Lingling.Panda.COM
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14012971998.14.MRC@lingling.panda.com>
Problem:
TOPS-10 programs that do GETTAB UUO can crash.
Diagnosis:
Routine SKPUSR has a SAVEAC macro invocation which is not only
unnecessary, but also generate bad code. MACREL isn't loaded,
and USRSAV (which MACREL normally defines) is a memory location
in PAT.
Solution:
Remove the unnecessary SAVEAC, and remember that you can't use
MACREL routines in PA1050! In PAT.MAC, at SKPUSR:, change:
SKPUSR: SAVEAC <A,B,C,D>
SKIPE STRNG1+.JIT20 ;TOPS20 EXEC MODE?
to:
SKPUSR: SKIPE STRNG1+.JIT20 ;TOPS20 EXEC MODE?
Believe it or not, I found this bug while running FOCAL!!
-- Mark --
PS: Man, it feels good to be posting TOPS-20 bugfixes on the TOPS-20 list
again...
-------
27-Mar-2005 11:28:47-PST,2968;000000000000
Mail-From: MRC created at 27-Mar-2005 11:20:23
Date: Sun, 27 Mar 2005 11:20:23 -0800 (PST)
From: Mark Crispin <MRC@Lingling.Panda.COM>
Subject: TOPS-20 future directions
To: TOPS-20@Lingling.Panda.COM
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14013380906.10.MRC@lingling.panda.com>
I have been giving some thought to future directions for the Panda
distribution. There isn't enough critical mass yet to actually start
on any of these projects, so currently these are gedanken exercises.
First is the question of disk space. Currently, we're using emulated
RP07s with about 220,000 pages of disk space. The Panda distribution
has DSKNB moved from 1B15 to 1B13, thus allowing two-RP07 structures
of about 440,000 pages but being compatible with structures built with
DEC monitors (basically adding 1B15 to available address space). We
can go as far as 1B12, adding 1B14 to available address space, at the
cost of compatibility; this allows about 440,000 pages.
If we create a new type of disk, and address by pages instead of 128
word blocks, we can then address 2,097,152 pages before running
out. That's a bit over 4GB.
Second is the question about SSH/SSL support. This may sound heretical,
but I believe that the proper way to do an SSH server is to have the
SSH code run on the host system and the connections feed the PDP-10 like
front end (DTE) lines. There's no need to go through all the overhead
of TOPS-20 TCP, and the DTE protocol could be extended to provide for
such features as terminal geometry.
SSL is tougher. Someone's going to have to port it to the PDP-10, and
I shudder at the thought even if we can sweet-talk XKL into giving us
their GCC so we don't have to use KCC. On the other hand, the idea of
ultimately being able to run Pine from TOPS-20 is quite attractive!
Finally is the question about leaving the KL behind and offering more
memory. We're currently limited to 22 bits physical, 23 bits virtual.
By adopting a system of a "super section table", we can expand virtual
addressing to 30 bits. Expanding physical addressing to 27 bits involves
some more work, but nothing like the work needed to go to 30 bits the way
XKL did.
In applications, as I said earlier I would like to see Pine on TOPS-20; I
know that XKL made MM run in extended addressing but I think that it's
time to let MM go. I suspect that we'd do better in porting UW imapd to
TOPS-20 rather than all the work to upgrade MAPSER from IMAP2 to
IMAP4rev1; even though MAPSER was the Penultimate PDP-10 Assembly Program.
MMAILR probably needs to be totally rewritten, but we may be able to
salvage MMAILBOX and MAISER. [Yes, this list is hopelessly biased towards
the mailsystem...]
Anyway, I thought that I would get a dialog started. Note that I am not
volunteering to do any of this work, although probably I will take on some
part of it eventually.
-------
30-Mar-2005 18:31:46-PST,1558;000000000000
Mail-From: MRC created at 30-Mar-2005 18:27:09
Date: Wed, 30 Mar 2005 18:27:09 -0800 (PST)
From: Mark Crispin <MRC@Lingling.Panda.COM>
Subject: TOPS-20 Unicode utility library
To: TOPS-20@Lingling.Panda.COM
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14014245027.11.MRC@lingling.panda.com>
I have begun a set of TOPS-20 Unicode utility routines. The latest version
will always be available via ANONYMOUS FTP from lingling.panda.com on
<UTF9>UTOOLS.MAC
The current version contains support to convert between a Unicode codepoint
and UTF-9, UTF-18, UTF-8, and UTF-16. Additional routines are planned,
including conversion support between various encodings.
The specification on UTF-9 and UTF-18 will be published on Friday. Briefly,
UTF-9 and UTF-18 are space-efficient encodings of Unicode that are particularly
suitable for PDP-10 systems. By increasing the byte size for characters from 7
to 9 bits, UTF-9 allows encoding US-ASCII and ISO Latin 1 in one byte, all of
the Unicode Basic Multilingual Plane in no more than 2 bytes (including all
characters used in email in all charsets!), and all of Unicode in no more than
3 bytes. UTF-18 encodes all of the assigned characters of Unicode in 18-bit
halfwords.
Of course, it will be necessary to support UTF-8 for terminals, but I think
that this is something that can be done through filters and we will want to
store Unicode data in UTF-9 and/or UTF-18.
Time to roll up sleeves and start programming... ;-)
-- Mark --
-------
30-Mar-2005 20:46:18-PST,633;000000000000
Mail-From: MRC created at 30-Mar-2005 20:41:55
Date: Wed, 30 Mar 2005 20:41:55 -0800 (PST)
From: Mark Crispin <MRC@Lingling.Panda.COM>
Subject: since RFC 4042 got released early...
To: TOPS-20@Lingling.Panda.COM
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14014269561.10.MRC@lingling.panda.com>
RFC 4042 is the specification for UTF-9 and UTF-18. It was easier to get it
published as an April 1 RFC than to go through the formal procedures.
Actually, some of the Unicode people *have* looked at it (although I wouldn't
go so far as to say that they approve!).
-- Mark --
-------
31-Mar-2005 07:46:37-PST,1287;000000000000
Return-Path: <bygg@cafax.se>
Received: from nic.cafax.se ([192.71.228.17]) by lingling.panda.com with TCP/SMTP; Thu, 31 Mar 2005 07:41:27 -0800 (PST)
Received: from nic.cafax.se (localhost [127.0.0.1])
by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j2VFfPFO009327
for <TOPS-20@lingling.panda.com>; Thu, 31 Mar 2005 17:41:25 +0200 (MEST)
Received: (from bygg@localhost)
by nic.cafax.se (8.12.11/8.12.11/Submit) id j2VFfPS6024125
for TOPS-20@lingling.panda.com; Thu, 31 Mar 2005 17:41:25 +0200 (MEST)
Date: Thu, 31 Mar 2005 17:41:25 WET DST
From: Johnny Eriksson <bygg@cafax.se>
To: TOPS-20@lingling.panda.com
Subject: Re: TOPS-20 Unicode utility library
In-Reply-To: Your message of Wed, 30 Mar 2005 18:27:09 -0800 (PST)
Message-ID: <CMM.0.91.0.1112283685.bygg@nic.cafax.se>
> I have begun a set of TOPS-20 Unicode utility routines. The latest version
> will always be available via ANONYMOUS FTP from lingling.panda.com on
> <UTF9>UTOOLS.MAC
I have taken a quick look at the code. Comments so far:
The routine U42UT8 does not seem to end with a return statement.
The routines U42UT8 and U42U16 contain ILDB's with the byte pointer
in a literal. I don't think that this is a good thing. Maybe LDB's
are a better choice.
> -- Mark --
--Johnny
31-Mar-2005 10:02:38-PST,726;000000000000
Mail-From: MRC created at 31-Mar-2005 09:58:12
Date: Thu, 31 Mar 2005 09:58:12 -0800 (PST)
From: Mark Crispin <MRC@Lingling.Panda.COM>
Subject: Re: TOPS-20 Unicode utility library
To: TOPS-20@Lingling.Panda.COM
In-Reply-To: <CMM.0.91.0.1112283685.bygg@nic.cafax.se>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14014414520.10.MRC@lingling.panda.com>
I forgot to cc TOPS-20 on my reply to Johnny. He is, of course, correct;
U42UT8 should end with a RETSKP and the ILDBs of literal pointers should
all be LDBs. Fixed in the updated <UTF9>UTOOLS.MAC on lingling.panda.com.
The UTF-8 and UTF-16 with last minute afterthoughts, and I didn't test
those routines... :-)
-------
1-Apr-2005 09:52:40-PST,7545;000000000000
Return-Path: <mrc@CAC.Washington.EDU>
Received: from mxout4.cac.washington.edu ([140.142.33.19]) by lingling.panda.com with TCP/SMTP; Fri, 1 Apr 2005 09:47:54 -0800 (PST)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
by mxout4.cac.washington.edu (8.13.3+UW05.01/8.13.3+UW05.01) with ESMTP id j31Hlqef011997
for <tops-20@lingling.panda.com>; Fri, 1 Apr 2005 09:47:52 -0800
Received: from shiva2.cac.washington.edu (shiva2.cac.washington.edu [140.142.37.173])
(authenticated bits=0)
by smtp.washington.edu (8.13.3+UW05.01/8.13.3+UW05.01) with ESMTP id j31HlpLF021299
(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT)
for <tops-20@lingling.panda.com>; Fri, 1 Apr 2005 09:47:51 -0800
X-Return-Path: <ietf-announce-bounces@ietf.org>
X-Received: via tmail-2000(13) (invoked by user mailnull) for mrc+ietf; Fri, 1 Apr 2005 09:22:18 -0800 (PST)
X-Return-Path: <ietf-announce-bounces@ietf.org>
X-Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.140])
by ndcms.cac.washington.edu (8.13.4+UW05.03/8.13.3+UW05.01) with ESMTP id j31HMIDe030372;
Fri, 1 Apr 2005 09:22:18 -0800
X-Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by mx1.cac.washington.edu (8.13.4+UW05.03/8.13.3+UW05.01) with ESMTP id j31HMAKm032724;
Fri, 1 Apr 2005 09:22:16 -0800
X-Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DHPj8-0004Om-8s; Fri, 01 Apr 2005 12:14:34 -0500
X-Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1DHPj6-0004OX-8O
for ietf-announce@megatron.ietf.org; Fri, 01 Apr 2005 12:14:32 -0500
X-Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16650
for <ietf-announce@ietf.org>; Fri, 1 Apr 2005 12:14:29 -0500 (EST)
X-Received: from boreas.isi.edu ([128.9.160.161])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHPqR-0002g6-E8
for ietf-announce@ietf.org; Fri, 01 Apr 2005 12:22:08 -0500
X-Received: from ISI.EDU (adma.isi.edu [128.9.160.239])
by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j31HDH602182;
Fri, 1 Apr 2005 09:13:17 -0800 (PST)
Message-Id: <200504011713.j31HDH602182@boreas.isi.edu>
To: ietf-announce@ietf.org
From: rfc-editor@rfc-editor.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 01 Apr 2005 09:13:17 -0800
X-ISI-4-39-6-MailScanner: Found to be clean
X-MailScanner-From: rfc-ed@isi.edu
X-Spam-Score: -14.6 (--------------)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632
Cc: rfc-editor@rfc-editor.org
Subject: RFC 4042 on UTF-9 and UTF-18 Efficient Transformation Formats of
Unicode
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ietf-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>,
<mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>,
<mailto:ietf-announce-request@ietf.org?subject=subscribe>
Sender: ietf-announce-bounces@ietf.org
Errors-To: ietf-announce-bounces@ietf.org
X-Scanned-By: MIMEDefang 2.49 on 140.142.32.140
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='NO_REAL_NAME 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0'
ReSent-Date: Fri, 1 Apr 2005 09:47:46 -0800 (PST)
ReSent-From: Mark Crispin <mrc@CAC.Washington.EDU>
ReSent-To: tops-20@lingling.panda.com
ReSent-Subject: RFC 4042 on UTF-9 and UTF-18 Efficient Transformation Formats
of Unicode
ReSent-Message-ID: <Pine.LNX.4.63.0504010947460.30429@shiva2.cac.washington.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 4042
Title: UTF-9 and UTF-18 Efficient Transformation Formats
of Unicode
Author(s): M. Crispin
Status: Informational
Date: 1 April 2005
Mailbox: UTF9@Lingling.Panda.COM
Pages: 9
Characters: 19123
Updates/Obsoletes/SeeAlso: None
URL: ftp://ftp.rfc-editor.org/in-notes/rfc4042.txt
ISO-10646 defines a large character set called the Universal
Character Set (UCS), which encompasses most of the world's writing
systems. The same set of codepoints is defined by Unicode, which
further defines additional character properties and other
implementation details. By policy of the relevant standardization
committees, changes to Unicode and amendments and additions to
ISO/IEC 646 track each other, so that the character repertoires and
code point assignments remain in synchronization.
The current representation formats for Unicode (UTF-7, UTF-8, UTF-16)
are not storage and computation efficient on platforms that utilize
the 9 bit nonet as a natural storage unit instead of the 8 bit octet.
This document describes a transformation format of Unicode that takes
advantage of the nonet so that the format will be storage and
computation efficient.
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info@RFC-EDITOR.ORG
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
server="RFC-INFO@RFC-EDITOR.ORG"
Content-Type: text/plain
Content-ID: <050401091153.RFC@RFC-EDITOR.ORG>
RETRIEVE: rfc
DOC-ID: rfc4042
--OtherAccess
Content-Type: Message/External-body; name="rfc4042.txt"; site="ftp.isi.edu";
access-type="anon-ftp"; directory="in-notes"
Content-Type: text/plain
Content-ID: <050401091153.RFC@RFC-EDITOR.ORG>
--OtherAccess--
--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce
--NextPart--
6-Apr-2005 00:28:00-PDT,1031;000000000000
Mail-From: MRC created at 6-Apr-2005 00:23:09
Date: Wed, 6 Apr 2005 00:23:09 -0700 (PDT)
From: Mark Crispin <MRC@Lingling.Panda.COM>
Subject: bug in MNETDV.MAC operating system handling
To: TOPS-20@Lingling.Panda.COM
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14015871778.14.MRC@lingling.panda.com>
Edit 9156 changed the OPSTAB table from being a TBLUK% format table to a
AOBJN lookup table that is handled via new routine OMATCH. Unfortunately,
the calculation of NUMOPS was not changed to correspond to this.
In file MNETDV.MAC, change
NUMOPS=.-OPSTAB-1
to be
NUMOPS=.-OPSTAB
Note that this fix *only* applies if your MNETDV.MAC has edit 9156. If
OPSTAB in your MNETDV.MAC has a first entry of XWD NUMOPS,NUMOPS then you
do *NOT* have edit 9156 and you should *NOT* apply this fix.
In particular, it appears that XKL monitors do *NOT* have edit 9156, and
thus this patch does not apply to XKL systems. It does, however, apply to
Panda monitors.
-------
6-Apr-2005 01:58:13-PDT,916;000000000000
Mail-From: MRC created at 6-Apr-2005 01:53:22
Date: Wed, 6 Apr 2005 01:53:22 -0700 (PDT)
From: Mark Crispin <MRC@Lingling.Panda.COM>
Subject: strange interpretation of AC1 in PSOUT%
To: TOPS-20@Lingling.Panda.COM
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14015888200.9.MRC@lingling.panda.com>
PSOUT% on TOPS-20 interprets the argument in AC1 in a strange way. Rather
than the straightforward
TLC 1,777777
TLCN 1,777777
HRLI 1,(<POINT 7,>)
XCTU [HLLM 1,1]
it does something truly wierd:
TLNE 1,777777
JUMPGE 1,PSOUT0
MOVSI C,440700
CAML 1,[777777,,0]
XCTU [HLLM C,1]
PSOUT0:
I've been trying to figure out why they did this. Tenex has the
straightforward way. The only effective difference that I can
see is that it allows
MOVEI 1,FOO
PSOUT%
as an alternative form of the more common:
HRROI 1,FOO
PSOUT%
-- Mark --
-------
17-May-2005 00:13:37-PDT,531;000000000000
Mail-From: MRC created at 17-May-2005 00:09:00
Date: Tue, 17 May 2005 00:09:00 -0700 (PDT)
From: Mark Crispin <MRC@Lingling.Panda.COM>
Subject: 22 years ago today...
To: TOPS-20@Lingling.Panda.COM
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14026617104.10.MRC@lingling.panda.com>
On May 17, 1983 was the infamous decision by DEC not only to cancel Project
Jupiter, but also not to make any new PDP-10 processors in favor of the VAX.
We're still here. DEC isn't any more.
-------
17-May-2005 03:02:09-PDT,1588;000000000000
Return-Path: <carl@reststop.com>
Received: from smtpauth07.mail.atl.earthlink.net ([209.86.89.67]) by lingling.panda.com with TCP/SMTP; Tue, 17 May 2005 02:56:53 -0700 (PDT)
Received: from [24.221.177.162] (helo=[204.238.239.105])
by smtpauth07.mail.atl.earthlink.net with asmtp (Exim 4.34)
id 1DXyon-0004pD-0j; Tue, 17 May 2005 05:56:53 -0400
In-Reply-To: <14026617104.10.MRC@lingling.panda.com>
References: <14026617104.10.MRC@lingling.panda.com>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <72c140597e5bd039a75bc0944a0531ea@reststop.com>
Content-Transfer-Encoding: 7bit
Cc: TOPS-20@lingling.panda.com
From: Carl Baltrunas <carl@reststop.com>
Subject: Re: 22 years ago today...
Date: Tue, 17 May 2005 02:56:53 -0700
To: Mark Crispin <MRC@lingling.panda.com>
X-Mailer: Apple Mail (2.622)
X-ELNK-Trace: 657dc9a5ceb70f7f3e74c9a82e36a01394f5150ab1c16ac06b48d29827cfba206eefe829dac86d3be27425419a301506350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 24.221.177.162
True... how true.
Last night I bumped into Doug Englebart at the Computer History Museum
and he mentioned that he is running Augment on Tops-20 under emulation.
It just goes to prove that some systems have timeless quality.
-Carl
On May 17, 2005, at 12:09 AM, Mark Crispin wrote:
> On May 17, 1983 was the infamous decision by DEC not only to cancel
> Project
> Jupiter, but also not to make any new PDP-10 processors in favor of
> the VAX.
>
> We're still here. DEC isn't any more.
> -------
17-May-2005 08:40:19-PDT,1454;000000000000
Return-Path: <wex@changing-leaves.com>
Received: from sccrmhc12.comcast.net ([204.127.202.56]) by lingling.panda.com with TCP/SMTP; Tue, 17 May 2005 08:35:04 -0700 (PDT)
Received: from [10.0.1.2] (c-24-91-108-249.hsd1.ma.comcast.net[24.91.108.249])
by comcast.net (sccrmhc12) with ESMTP
id <200505171535020120063qn4e>; Tue, 17 May 2005 15:35:03 +0000
Mime-Version: 1.0
X-Sender: (Unverified)
Message-Id: <p0611040abeafbe7fdd67@[10.0.1.2]>
In-Reply-To: <14026617104.10.MRC@lingling.panda.com>
References: <14026617104.10.MRC@lingling.panda.com>
Date: Tue, 17 May 2005 11:34:57 -0400
To: Mark Crispin <MRC@lingling.panda.com>, TOPS-20@lingling.panda.com
From: Paul Wexelblat <wex@changing-leaves.com>
Subject: Re: 22 years ago today...
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
At 12:09 AM -0700 5/17/05, Mark Crispin wrote:
>On May 17, 1983 was the infamous decision by DEC not only to cancel Project
>Jupiter, but also not to make any new PDP-10 processors in favor of the VAX.
>
>We're still here. DEC isn't any more.
>-------
Sure, but we all knew that a machine where the JUMP instruction
didn't Jump and the SKIP instruction didn't skip would live forever.
...and the Jump and clear flags Instruction did neither - but didn't
do either really fast
--
P.M. Wexelblat PhD
Dept. of Computer Science
University of Massachusetts Lowell
One University Ave
Lowell, MA 01854
17-May-2005 09:52:22-PDT,1397;000000000000
Return-Path: <wex@cs.uml.edu>
Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by lingling.panda.com with TCP/SMTP; Tue, 17 May 2005 09:47:08 -0700 (PDT)
Received: from [10.0.1.2] (c-24-91-108-249.hsd1.ma.comcast.net[24.91.108.249])
by comcast.net (rwcrmhc13) with ESMTP
id <20050517164707015007jh00e>; Tue, 17 May 2005 16:47:08 +0000
Mime-Version: 1.0
X-Sender: (Unverified)
Message-Id: <p0611040dbeafd06f11ae@[10.0.1.2]>
In-Reply-To: <14026617104.10.MRC@lingling.panda.com>
References: <14026617104.10.MRC@lingling.panda.com>
Date: Tue, 17 May 2005 12:47:03 -0400
To: TOPS-20@lingling.panda.com
From: Paul Wexelblat <wex@cs.uml.edu>
Subject: Re: 22 years ago today...
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
At 12:09 AM -0700 5/17/05, Mark Crispin wrote:
>On May 17, 1983 was the infamous decision by DEC not only to cancel Project
>Jupiter, but also not to make any new PDP-10 processors in favor of the VAX.
>
>We're still here. DEC isn't any more.
>-------
Sure, but we all knew that a machine where the JUMP instruction
didn't Jump and the SKIP instruction didn't skip would live forever.
...and the Jump and clear flags Instruction did neither - but didn't
do either really fast
--
P.M. Wexelblat PhD
Dept. of Computer Science
University of Massachusetts Lowell
One University Ave
Lowell, MA 01854
17-May-2005 14:14:36-PDT,1249;000000000000
Return-Path: <billw@cisco.com>
Received: from sj-iport-2.cisco.com ([171.71.176.71]) by lingling.panda.com with TCP/SMTP; Tue, 17 May 2005 14:07:02 -0700 (PDT)
Received: from sj-core-5.cisco.com (171.71.177.238)
by sj-iport-2.cisco.com with ESMTP; 17 May 2005 14:07:02 -0700
Received: from cisco.com (cypher.cisco.com [171.69.11.142])
by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4HL6sPo001703;
Tue, 17 May 2005 14:06:55 -0700 (PDT)
Received: (from billw@localhost)
by cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA18619;
Tue, 17 May 2005 14:06:54 -0700 (PDT)
Sender: Bill Westfield <billw@cisco.com>
Date: Tue, 17 May 2005 14:06:54 PDT
From: William "Chops" Westfield <billw@cisco.com>
To: Paul Wexelblat <wex@cs.uml.edu>
Cc: TOPS-20@lingling.panda.com
Subject: Re: 22 years ago today...
In-Reply-To: Your message of Tue, 17 May 2005 12:47:03 -0400
Message-ID: <CMM.0.90.4.1116364014.billw@cypher>
>We're still here.
"We" are hobbyists, right? Does that count as 'still here'?
...and the Jump and clear flags Instruction did neither - but didn't
do either really fast
But not as fast as (test and do nothing)
What's the fastest noop on the pentium micromachine PDP10s?
:-)
BillW
17-May-2005 14:29:24-PDT,1390;000000000000
Return-Path: <wex@cs.uml.edu>
Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by lingling.panda.com with TCP/SMTP; Tue, 17 May 2005 14:22:18 -0700 (PDT)
Received: from [10.0.1.2] (c-24-91-108-249.hsd1.ma.comcast.net[24.91.108.249])
by comcast.net (rwcrmhc11) with ESMTP
id <2005051721221701300pdvohe>; Tue, 17 May 2005 21:22:18 +0000
Mime-Version: 1.0
X-Sender: (Unverified)
Message-Id: <p06110402beb010f2ce3c@[10.0.1.2]>
In-Reply-To: <CMM.0.90.4.1116364014.billw@cypher>
References: <CMM.0.90.4.1116364014.billw@cypher>
Date: Tue, 17 May 2005 17:22:12 -0400
To: William "Chops" Westfield <billw@cisco.com>
From: Paul Wexelblat <wex@cs.uml.edu>
Subject: Re: 22 years ago today...
Cc: TOPS-20@lingling.panda.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
At 2:06 PM -0700 5/17/05, William "Chops" Westfield wrote:
> >We're still here.
>
>"We" are hobbyists, right? Does that count as 'still here'?
>
>
> ...and the Jump and clear flags Instruction did neither - but didn't
> do either really fast
>
>But not as fast as (test and do nothing)
>
>What's the fastest noop on the pentium micromachine PDP10s?
>
> :-)
>BillW
Wasn't JFCL the fastest no-op on the KA and KI?
--
P.M. Wexelblat PhD
Dept. of Computer Science
University of Massachusetts Lowell
One University Ave
Lowell, MA 01854
17-May-2005 14:36:32-PDT,514;000000000000
Mail-From: MRC created at 17-May-2005 14:30:12
Date: Tue, 17 May 2005 14:30:12 -0700 (PDT)
From: Mark Crispin <MRC@Lingling.Panda.COM>
Subject: Re: 22 years ago today...
To: wex@cs.uml.edu
cc: billw@cisco.com, TOPS-20@Lingling.Panda.COM
In-Reply-To: <p06110402beb010f2ce3c@[10.0.1.2]>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14026773881.13.MRC@lingling.panda.com>
Yes, JFCL was the fastest no-op on the KA and KI. TRN was the fastest no-op
on the KL.
-------
17-May-2005 14:42:46-PDT,588;000000000000
Mail-From: MRC created at 17-May-2005 14:31:05
Date: Tue, 17 May 2005 14:31:05 -0700 (PDT)
From: Mark Crispin <MRC@Lingling.Panda.COM>
Subject: Re: 22 years ago today...
To: billw@cisco.com
cc: wex@cs.uml.edu, TOPS-20@Lingling.Panda.COM
In-Reply-To: <CMM.0.90.4.1116364014.billw@cypher>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14026774044.13.MRC@lingling.panda.com>
"We" are hobbyists, right? Does that count as 'still here'?
Some of us still do real work on TOPS-20 systems, even if there
is a hobby component to it.
-------
24-May-2005 15:00:15-PDT,3592;000000000000
Return-Path: <beebe@math.utah.edu>
Received: from sunshine.math.utah.edu ([128.110.198.2]) by lingling.panda.com with TCP/SMTP; Tue, 24 May 2005 14:53:06 -0700 (PDT)
Received: from sunbeam.math.utah.edu (IDENT:5qsQgDc58Yd6MTEamyvykBIQvJgLMrOu@sunbeam.math.utah.edu [155.101.96.161])
by sunshine.math.utah.edu (8.13.3/8.13.3) with ESMTP id j4OLr5SL018199;
Tue, 24 May 2005 15:53:05 -0600 (MDT)
Received: from sunbeam.math.utah.edu (IDENT:ZZ59D1KEBfapbEip5YfBA98e2rmBEttq@localhost [127.0.0.1])
by sunbeam.math.utah.edu (8.12.11/8.12.10) with ESMTP id j4OLr5Jl023911;
Tue, 24 May 2005 15:53:05 -0600 (MDT)
Received: (from beebe@localhost)
by sunbeam.math.utah.edu (8.12.11/8.12.10/Submit) id j4OLr5t2023910;
Tue, 24 May 2005 15:53:05 -0600 (MDT)
Date: Tue, 24 May 2005 15:53:05 -0600 (MDT)
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
To: TOPS-20@lingling.panda.com
Cc: beebe@math.utah.edu
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: PDP-10 history: seeking TeX'78 source code in SAIL
Message-ID: <CMM.0.92.0.1116971585.beebe@sunbeam.math.utah.edu>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (sunshine.math.utah.edu [128.110.198.2]); Tue, 24 May 2005 15:53:05 -0600 (MDT)
I'm working on my keynote address for the Practical TeX '2005
conference next month, with a TUGboat article entitled ``The Design of
TeX and METAFONT: A retrospective''. The topic is how the PDP-10
architecture, operating systems, and programming languages of the time
influenced Donald Knuth in his design of TeX and Metafont.
The 1977--78 prototypes for these programs were written in SAIL, and
then redesigned in 1982--1983 in Pascal.
I have online mirrors of our six RP06 and RP07 disks as they existed
when science.utah.edu retired on 31-Oct-1990. In them, I have these
source files for the original METAFONT:
old-mf-local/dsbitg.sai old-mf/mfdovr.sai old-mf/mfout.sai
old-mf-local/dsgigi.sai old-mf/mff20.sai old-mf/mfpre.sai
old-mf-local/dsmult.sai old-mf/mffil.sai old-mf/mfrast.sai
old-mf-local/mfhdr.sai old-mf/mfhdr.sai old-mf/mfsys.sai
old-mf-local/mfrast.sai old-mf/mfntrp.sai old-mf/presso.sai
old-mf/mfbase.sai
fonts/fntbbg.sai mf/mffil.sai mf/mfpre.sai
fonts/vntbbg.sai mf/mfhdr.sai mf/mfrast.sai
mf/mfbase.sai mf/mfntrp.sai mf/mfsys.sai
mf/mfdovr.sai mf/mfout.sai mf/presso.sai
mf/mff20.sai mf/mfoutb.sai
However, I don't have companion sources for TeX in SAIL.
Does anyone have these in their TOPS-20 archives? A Web search found
one possible site, but it is unreachable.
I'm chagrined that I seem not to have preserved this important
original program, and I don't know why it is missing.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
- 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
24-May-2005 15:07:32-PDT,6683;000000000000
Return-Path: <beebe@math.utah.edu>
Received: from sunshine.math.utah.edu ([128.110.198.2]) by lingling.panda.com with TCP/SMTP; Tue, 24 May 2005 15:01:01 -0700 (PDT)
Received: from sunbeam.math.utah.edu (IDENT:OjuAc+S/mIeuRFl/nus1L15xmNaeNRrn@sunbeam.math.utah.edu [155.101.96.161])
by sunshine.math.utah.edu (8.13.3/8.13.3) with ESMTP id j4OM10Mb018714;
Tue, 24 May 2005 16:01:00 -0600 (MDT)
Received: from sunbeam.math.utah.edu (IDENT:72hsfl6fAAW18Hl0SMeEuA2WX9JwgkNS@localhost [127.0.0.1])
by sunbeam.math.utah.edu (8.12.11/8.12.10) with ESMTP id j4OM10eq024157;
Tue, 24 May 2005 16:01:00 -0600 (MDT)
Received: (from beebe@localhost)
by sunbeam.math.utah.edu (8.12.11/8.12.10/Submit) id j4OM10Bh024156;
Tue, 24 May 2005 16:01:00 -0600 (MDT)
Date: Tue, 24 May 2005 16:01:00 -0600 (MDT)
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
To: TOPS-20@lingling.panda.com
Cc: beebe@math.utah.edu
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: PDP-10 history: catalog of O/Ses
Message-ID: <CMM.0.92.0.1116972060.beebe@sunbeam.math.utah.edu>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (sunshine.math.utah.edu [128.110.198.2]); Tue, 24 May 2005 16:01:00 -0600 (MDT)
Another point in my Practical TeX '2005 keynote address article
mentioned in my previous posting is a recording of the operating
systems that ran on the PDP-10. I wrote:
The PDP-10 ran several operating systems, including DEC's
TOPS-10 (BBN Tenex) and TOPS-20 (BBN Twenex), MIT's ITS
(Incompatible Time Sharing System), and Stanford's LOTS (Low
Overhead Timesharing System) and WAITS (Westcoast
Alternative to ITS). Although the operating systems
differed, it was usually possible to move both source code
and binary executable programs among them with few if any
changes.
Two questions: (1) did I miss any operating systems? (2) is my last
statement in the extract above accurate? My memory says that it is,
but my wife asserts that my memory is not to be trusted.
I know that we often used the terms Tenex and Twenex informally, but
perhaps Twenex at least doesn't qualify as a proper name, in light of
this New Hacker's Dictionary entry from the jargon.info file:
:TWENEX:: /twe'neks/ /n./ The TOPS-20 operating system by DEC
-- the second proprietary OS for the PDP-10 -- preferred by most
PDP-10 hackers over TOPS-10 (that is, by those who were not
{{ITS}} or {{WAITS}} partisans). TOPS-20 began in 1969 as Bolt,
Beranek & Newman's TENEX operating system using special paging
hardware. By the early 1970s, almost all of the systems on the
ARPANET ran TENEX. DEC purchased the rights to TENEX from BBN and
began work to make it their own. The first in-house code name for
the operating system was VIROS (VIRtual memory Operating System);
when customers started asking questions, the name was changed to
SNARK so DEC could truthfully deny that there was any project
called VIROS. When the name SNARK became known, the name was
briefly reversed to become KRANS; this was quickly abandoned when
someone objected that `krans' meant `funeral wreath' in Swedish
(though some Swedish speakers have since said it means simply
`wreath'; this part of the story may be apocryphal). Ultimately
DEC picked TOPS-20 as the name of the operating system, and it was
as TOPS-20 that it was marketed. The hacker community, mindful of
its origins, quickly dubbed it TWENEX (a contraction of `twenty
TENEX'), even though by this point very little of the original
TENEX code remained (analogously to the differences between AT&T V6
Unix and BSD). DEC people cringed when they heard "TWENEX", but
the term caught on nevertheless (the written abbreviation `20x'
was also used). TWENEX was successful and very popular; in fact,
there was a period in the early 1980s when it commanded as fervent
a culture of partisans as Unix or ITS -- but DEC's decision to
scrap all the internal rivals to the VAX architecture and its
relatively stodgy VMS OS killed the DEC-20 and put a sad end to
TWENEX's brief day in the sun. DEC attempted to convince TOPS-20
users to convert to {VMS}, but instead, by the late 1980s, most
of the TOPS-20 hackers had migrated to Unix.
Here's what it records about WAITS:
:WAITS:: /wayts/ /n./ The mutant cousin of {{TOPS-10}} used
on a handful of systems at {{SAIL}} up to 1990. There was never
an `official' expansion of WAITS (the name itself having been
arrived at by a rather sideways process), but it was frequently
glossed as `West-coast Alternative to ITS'. Though WAITS was less
visible than ITS, there was frequent exchange of people and ideas
between the two communities, and innovations pioneered at WAITS
exerted enormous indirect influence. The early screen modes of
{EMACS}, for example, were directly inspired by WAITS's `E'
editor -- one of a family of editors that were the first to do
`real-time editing', in which the editing commands were invisible
and where one typed text at the point of insertion/overwriting.
The modern style of multi-region windowing is said to have
originated there, and WAITS alumni at XEROX PARC and elsewhere
played major roles in the developments that led to the XEROX Star,
the Macintosh, and the Sun workstations. Also invented there were
{bucky bits} -- thus, the ALT key on every IBM PC is a WAITS
legacy. One notable WAITS feature seldom duplicated elsewhere was
a news-wire interface that allowed WAITS hackers to read, store,
and filter AP and UPI dispatches from their terminals; the system
also featured a still-unusual level of support for what is now
called `multimedia' computing, allowing analog audio and video
signals to be switched to programming terminals.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
- 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
24-May-2005 15:44:56-PDT,7301;000000000000
Return-Path: <lougheed@cisco.com>
Received: from sj-iport-3.cisco.com ([171.71.176.72]) by lingling.panda.com with TCP/SMTP; Tue, 24 May 2005 15:37:45 -0700 (PDT)
Received: from sj-core-5.cisco.com (171.71.177.238)
by sj-iport-3.cisco.com with ESMTP; 24 May 2005 15:37:45 -0700
X-IronPort-AV: i="3.93,133,1115017200";
d="scan'208"; a="269231710:sNHT32420118"
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144])
by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4OMbalq007165;
Tue, 24 May 2005 15:37:36 -0700 (PDT)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
Tue, 24 May 2005 15:37:35 -0700
Received: from [10.34.249.187] ([10.34.249.187]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
Tue, 24 May 2005 15:37:35 -0700
Message-ID: <4293ACAF.5040107@cisco.com>
Date: Tue, 24 May 2005 15:37:35 -0700
From: Kirk Lougheed <lougheed@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Nelson H. F. Beebe" <beebe@math.utah.edu>
CC: TOPS-20@lingling.panda.com
Subject: Re: PDP-10 history: catalog of O/Ses
References: <CMM.0.92.0.1116972060.beebe@sunbeam.math.utah.edu>
In-Reply-To: <CMM.0.92.0.1116972060.beebe@sunbeam.math.utah.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 24 May 2005 22:37:35.0147 (UTC) FILETIME=[2E41CFB0:01C560B1]
You added an operating system. The LOTS machines were all TOPS-20.
I know you could run TOPS-10 binaries on TOPS-20 systems, but not
conversely. I rather doubt you could run an ITS or WAITS binary
on anything but ITS or WAITS.
Regards,
Kirk
Nelson H. F. Beebe wrote:
> Another point in my Practical TeX '2005 keynote address article
> mentioned in my previous posting is a recording of the operating
> systems that ran on the PDP-10. I wrote:
>
> The PDP-10 ran several operating systems, including DEC's
> TOPS-10 (BBN Tenex) and TOPS-20 (BBN Twenex), MIT's ITS
> (Incompatible Time Sharing System), and Stanford's LOTS (Low
> Overhead Timesharing System) and WAITS (Westcoast
> Alternative to ITS). Although the operating systems
> differed, it was usually possible to move both source code
> and binary executable programs among them with few if any
> changes.
>
> Two questions: (1) did I miss any operating systems? (2) is my last
> statement in the extract above accurate? My memory says that it is,
> but my wife asserts that my memory is not to be trusted.
>
> I know that we often used the terms Tenex and Twenex informally, but
> perhaps Twenex at least doesn't qualify as a proper name, in light of
> this New Hacker's Dictionary entry from the jargon.info file:
>
> :TWENEX:: /twe'neks/ /n./ The TOPS-20 operating system by DEC
> -- the second proprietary OS for the PDP-10 -- preferred by most
> PDP-10 hackers over TOPS-10 (that is, by those who were not
> {{ITS}} or {{WAITS}} partisans). TOPS-20 began in 1969 as Bolt,
> Beranek & Newman's TENEX operating system using special paging
> hardware. By the early 1970s, almost all of the systems on the
> ARPANET ran TENEX. DEC purchased the rights to TENEX from BBN and
> began work to make it their own. The first in-house code name for
> the operating system was VIROS (VIRtual memory Operating System);
> when customers started asking questions, the name was changed to
> SNARK so DEC could truthfully deny that there was any project
> called VIROS. When the name SNARK became known, the name was
> briefly reversed to become KRANS; this was quickly abandoned when
> someone objected that `krans' meant `funeral wreath' in Swedish
> (though some Swedish speakers have since said it means simply
> `wreath'; this part of the story may be apocryphal). Ultimately
> DEC picked TOPS-20 as the name of the operating system, and it was
> as TOPS-20 that it was marketed. The hacker community, mindful of
> its origins, quickly dubbed it TWENEX (a contraction of `twenty
> TENEX'), even though by this point very little of the original
> TENEX code remained (analogously to the differences between AT&T V6
> Unix and BSD). DEC people cringed when they heard "TWENEX", but
> the term caught on nevertheless (the written abbreviation `20x'
> was also used). TWENEX was successful and very popular; in fact,
> there was a period in the early 1980s when it commanded as fervent
> a culture of partisans as Unix or ITS -- but DEC's decision to
> scrap all the internal rivals to the VAX architecture and its
> relatively stodgy VMS OS killed the DEC-20 and put a sad end to
> TWENEX's brief day in the sun. DEC attempted to convince TOPS-20
> users to convert to {VMS}, but instead, by the late 1980s, most
> of the TOPS-20 hackers had migrated to Unix.
>
> Here's what it records about WAITS:
>
> :WAITS:: /wayts/ /n./ The mutant cousin of {{TOPS-10}} used
> on a handful of systems at {{SAIL}} up to 1990. There was never
> an `official' expansion of WAITS (the name itself having been
> arrived at by a rather sideways process), but it was frequently
> glossed as `West-coast Alternative to ITS'. Though WAITS was less
> visible than ITS, there was frequent exchange of people and ideas
> between the two communities, and innovations pioneered at WAITS
> exerted enormous indirect influence. The early screen modes of
> {EMACS}, for example, were directly inspired by WAITS's `E'
> editor -- one of a family of editors that were the first to do
> `real-time editing', in which the editing commands were invisible
> and where one typed text at the point of insertion/overwriting.
> The modern style of multi-region windowing is said to have
> originated there, and WAITS alumni at XEROX PARC and elsewhere
> played major roles in the developments that led to the XEROX Star,
> the Macintosh, and the Sun workstations. Also invented there were
> {bucky bits} -- thus, the ALT key on every IBM PC is a WAITS
> legacy. One notable WAITS feature seldom duplicated elsewhere was
> a news-wire interface that allowed WAITS hackers to read, store,
> and filter AP and UPI dispatches from their terminals; the system
> also featured a still-unusual level of support for what is now
> called `multimedia' computing, allowing analog audio and video
> signals to be switched to programming terminals.
>
> -------------------------------------------------------------------------------
> - Nelson H. F. Beebe Tel: +1 801 581 5254 -
> - University of Utah FAX: +1 801 581 4148 -
> - Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
> - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
> - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
> -------------------------------------------------------------------------------
>
24-May-2005 16:09:34-PDT,1931;000000000000
Return-Path: <billw@cisco.com>
Received: from sj-iport-1.cisco.com ([171.71.176.70]) by lingling.panda.com with TCP/SMTP; Tue, 24 May 2005 16:02:21 -0700 (PDT)
Received: from sj-core-2.cisco.com (171.71.177.254)
by sj-iport-1.cisco.com with ESMTP; 24 May 2005 16:02:21 -0700
X-IronPort-AV: i="3.93,133,1115017200";
d="scan'208"; a="638349244:sNHT433862340"
Received: from cisco.com (cypher.cisco.com [171.69.11.142])
by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4ON2Blw024231;
Tue, 24 May 2005 16:02:12 -0700 (PDT)
Received: (from billw@localhost)
by cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA07515;
Tue, 24 May 2005 16:02:16 -0700 (PDT)
Sender: Bill Westfield <billw@cisco.com>
Date: Tue, 24 May 2005 16:02:16 PDT
From: William "Chops" Westfield <billw@cisco.com>
To: "Nelson H. F. Beebe" <beebe@math.utah.edu>
Cc: TOPS-20@lingling.panda.com, beebe@math.utah.edu
Subject: Re: PDP-10 history: catalog of O/Ses
In-Reply-To: Your message of Tue, 24 May 2005 16:01:00 -0600 (MDT)
Message-ID: <CMM.0.90.4.1116975736.billw@cypher>
The PDP-10 ran several operating systems, including DEC's
TOPS-10 (BBN Tenex) and TOPS-20 (BBN Twenex), MIT's ITS
(Incompatible Time Sharing System), and Stanford's LOTS (Low
Overhead Timesharing System) and WAITS (Westcoast
TOPS10 was a DEC operating system not at all related to BBN TENEX.
TOPS20 was DECs rewrite(?) of BBN TENEX, but no long had any
connection with BBN.
LOTS was not an operating system; more of a concept in systems
administration; the LOTS facility ran essentially the same "stanford
modified tops20" that also ran at the computer science department
(SU-Score, Sushi) and EE department (Sierra...)
That leaves tops10, waits, its, tenex, and tops20 as the actual
operating sytems used, I think. I suppose that it's amusing that ALL
of them were still in use at the date the 36bit line was killed...
BillW
24-May-2005 17:42:47-PDT,2466;000000000000
Return-Path: <clive.dawson@amd.com>
Received: from amdext4.amd.com ([163.181.251.6]) by lingling.panda.com with TCP/SMTP; Tue, 24 May 2005 17:35:25 -0700 (PDT)
Received: from SAUSGW02.amd.com (sausgw02.amd.com [163.181.250.22])
by amdext4.amd.com (8.12.11/8.12.11/AMD) with ESMTP id j4P0YEla027291;
Tue, 24 May 2005 19:34:15 -0500
Received: from 163.181.250.1 by SAUSGW02.amd.com with ESMTP (AMD SMTP
Relay (Email Firewall v6.1.0)); Tue, 24 May 2005 19:34:07 -0500
X-Server-Uuid: 5FC0E2DF-CD44-48CD-883A-0ED95B391E89
Received: from optimon.amd.com (optimon.amd.com [163.181.34.104]) by
amdint2.amd.com (8.12.8/8.12.8/AMD) with ESMTP id j4P0Y6c7019077; Tue,
24 May 2005 19:34:06 -0500 (CDT)
Received: from labuena.amd.com (
IDENT:I4f63Ebe0TkARznlO/5D0mNlL3clSQ0M@labuena.amd.com
[163.181.10.243]) by optimon.amd.com (8.12.10/8.12.10) with ESMTP id
j4P0Y6ot001923; Tue, 24 May 2005 19:34:06 -0500
Received: (from clive@localhost) by labuena.amd.com (
8.9.3/8.9.3/8.9.3-MPD-evision: 1.5 $) id TAA14392; Tue, 24 May 2005
19:34:06 -0500
Date: Tue, 24 May 2005 19:34:06 -0500
Message-ID: <200505250034.TAA14392@labuena.amd.com>
From: "Clive Dawson" <clive.dawson@amd.com>
To: TOPS-20@lingling.panda.com
cc: beebe@math.utah.edu, billw@cisco.com
In-Reply-To: <CMM.0.90.4.1116975736.billw@cypher>
Subject: Re: PDP-10 history: catalog of O/Ses
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on
optimon.amd.com
X-Virus-Status: Clean
MIME-Version: 1.0
X-WSS-ID: 6E8D18752DO1987241-01-01
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
>That leaves tops10, waits, its, tenex, and tops20 as the actual
>operating sytems used, I think. I suppose that it's amusing that ALL
>of them were still in use at the date the 36bit line was killed...
Yes, I think Bill has pretty much covered the major variations.
As he said, TOPS10 had nothing to do with BBN's TENEX.
But I wonder if anybody from CMU, Compuserve and/or TYMSHARE might
want to chime in. As I recall, the OS's running at those places were
heavily modified versions of the original DEC OS for the PDP-10, which
didn't become known officially as "TOPS-10" until DEC went to
"Level D" and the venerable version 4S72 was replaced with version 5,
as I recall.
There is a lot of good info on this subject to be found at
http://www.ultimate.com/phil/pdp10/
along with plenty of links.
Clive Dawson
AMD
Austin, TX
24-May-2005 19:32:34-PDT,5462;000000000000
Return-Path: <carl@reststop.com>
Received: from smtpauth06.mail.atl.earthlink.net ([209.86.89.66]) by lingling.panda.com with TCP/SMTP; Tue, 24 May 2005 19:25:06 -0700 (PDT)
Received: from [24.221.177.162] (helo=[204.238.239.105])
by smtpauth06.mail.atl.earthlink.net with asmtp (Exim 4.34)
id 1DalZx-0004Gl-SD; Tue, 24 May 2005 22:25:06 -0400
In-Reply-To: <200505250034.TAA14392@labuena.amd.com>
References: <200505250034.TAA14392@labuena.amd.com>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <398d488b1204e2ba426c78bdc7ec60af@reststop.com>
Content-Transfer-Encoding: 7bit
Cc: TOPS-20@lingling.panda.com,
beebe@math.utah.edu,
billw@cisco.com
From: Carl Baltrunas <carl@reststop.com>
Subject: Re: PDP-10 history: catalog of O/Ses
Date: Tue, 24 May 2005 19:25:04 -0700
To: "Clive Dawson" <clive.dawson@amd.com>
X-Mailer: Apple Mail (2.622)
X-ELNK-Trace: 657dc9a5ceb70f7f3e74c9a82e36a01394f5150ab1c16ac06b48d29827cfba20a563a3c7eb3ea705c305942707c571ab350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 24.221.177.162
From what I recall visiting CMU and converting FINE from their OS to
run on TOPS-10 (and later TYMCOM-X), they were pretty much a TOPS-10
shop with modifications for user-id and terminal support. They had
their own image mode when DEC gave the rest of us PIM or Packed Image
Mode. Otherwise fairly vanilla compared to things like ITS or WAITS.
Someone from CMU can correct me if I'm mistaken.
BTW, thanks for the item about West-coast Alternative to ITS. I never
knew that. I'll have to look in my WAITS monitor calls manual and see
if it's listed in there.
TOPS-10 was called "Bottoms-10" by a lot of by a lot of the Tenex or
Twenex crowd because it didn't originally have networking or page
mapping until the KI model was released. Even then, ANF-10 was the
first networking it had, until the PDP-11 and VAXen had DECNET which
was retrofit to work on TOPS-10.
Both Compuserv and On-Line Systems had heavily modified systems to
provide their customers with a more "commercial" look and feel. I
recall hearing that On Line Systems started making their modifications
back on the DECtape version of the OS. I only saw it when taking a
tour for a job interview in 1980, but accepted a position at Tymshare
instead.
Tymshare had it's own custom OS called TYMCOM-X (and for the 2020s,
TYMCOM-XX) which diverged from TOPS-10 at the 5.02 level. Things were
added to match features with TOP-10 and some Tenex influences but
remained custom. We used a very close relative to COMPIL which was
originally written by Bill Wehir (sp?) or (WFW), which was called RPG.
If you look at versions of COMPIL you can still find many of the same
lines of code with the same comments. We had 4 different prompting
modes, TYMCOM-IX (SDS-940), PDP-10, SUDS, and restricted (which ran a
user level application immediately after LOGIN finished). Tymshare
never got around to multiple structures, so we had one very large DSKB:
structure striped across all of the disks. External memory, tape and
disk drives were connected via an SA-10. Tape controllers and drives
were all from STC and disks were AMPEX or Memorex drives we got as
hand-me-downs from the IBM systems.
Somewhere I have the "official" list that DEC supported in one of it's
tables that allowed a program to poll the OS for which OS was running.
It may even have made it into one of the JSYS entries... it's a good
place to check.
We also had a Tymshare partner in Paris and they maintained a separate
set of sources for many of the CUSPs which then prompted users in
French. I presume they watched whenever we came out with a new release
to retrofit their changes into our code.
Also, you may want to give Systems Concepts honorable mention for their
changes to the OS to run on their SC30M and later models. (I forget
where the "-" goes).
Likewise, XKL in Redmond, WA had to make significant changes to both
TOPS-20 and TOPS-10 in order to get them up and running on their
TOAD-1s. I don't know how extensive the TOPS-10 changes were, but they
also added a number of UNIX shell commands. TOPS-10 was running with
console access on the TOAD but I do not know if Vance (aka Ernie) Socci
or Ralph Gorin ever had network support for remote logins working.
Check with Ralph for complete information on that.
On May 24, 2005, at 5:34 PM, Clive Dawson wrote:
>
>> That leaves tops10, waits, its, tenex, and tops20 as the actual
>> operating sytems used, I think. I suppose that it's amusing that ALL
>> of them were still in use at the date the 36bit line was killed...
>
> Yes, I think Bill has pretty much covered the major variations.
> As he said, TOPS10 had nothing to do with BBN's TENEX.
>
> But I wonder if anybody from CMU, Compuserve and/or TYMSHARE might
> want to chime in. As I recall, the OS's running at those places were
> heavily modified versions of the original DEC OS for the PDP-10, which
> didn't become known officially as "TOPS-10" until DEC went to
> "Level D" and the venerable version 4S72 was replaced with version 5,
> as I recall.
>
> There is a lot of good info on this subject to be found at
>
> http://www.ultimate.com/phil/pdp10/
>
> along with plenty of links.
>
> Clive Dawson
> AMD
> Austin, TX
>
>
>
24-May-2005 19:46:40-PDT,1260;000000000000
Mail-From: MRC created at 24-May-2005 19:40:14
Date: Tue, 24 May 2005 19:40:14 -0700 (PDT)
From: Mark Crispin <MRC@Lingling.Panda.COM>
Subject: Re: PDP-10 history: catalog of O/Ses
To: TOPS-20@Lingling.Panda.COM
In-Reply-To: <4293ACAF.5040107@cisco.com>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14028665330.10.MRC@lingling.panda.com>
I know you could run TOPS-10 binaries on TOPS-20 systems, but not
conversely. I rather doubt you could run an ITS or WAITS binary
on anything but ITS or WAITS.
Some WAITS binaries (most notably, SUDS and PUB) could run under
ITS using DECUUO (the ITS equivalent of PA1050) set for SAIL
emulation. You couldn't run the binary directly; you had to run
DECUUO and then have DECUUO load the WAITS binary.
DECUUO also could run some TOPS-10 binaries; at least well enough
to run MACRO and LINK.
If you converted a WAITS binary from the DMP format into SAV
format using FILEX, you could then try running it on TOPS-20. To
the extent that you stuck to the traditional DEC UUOs circa 4
series monitors, it should run. REL files were almost always
easier to port than a DMP file.
AFAIK, ITS binaries never ran anywhere other than on ITS.
-------
24-May-2005 19:54:44-PDT,1032;000000000000
Mail-From: MRC created at 24-May-2005 19:48:28
Date: Tue, 24 May 2005 19:48:28 -0700 (PDT)
From: Mark Crispin <MRC@Lingling.Panda.COM>
Subject: Re: PDP-10 history: catalog of O/Ses
To: TOPS-20@Lingling.Panda.COM
In-Reply-To: <CMM.0.90.4.1116975736.billw@cypher>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14028666827.10.MRC@lingling.panda.com>
> TOPS20 was DECs rewrite(?) of BBN TENEX, but no long had any
> connection with BBN.
DEC bought Tenex from BBN, and hired Dan Murphy (one of the two
original authors of Tenex). That system became TOPS-20.
TOPS-20 forked from Tenex before Tenex 1.34, but I don't know
when exactly the fork happened. Unfortunately, DEC deleted a lot
of old edit history in TOPS-20 sources so it's no longer possible
to track when things happened. However, I see a SUBTTL in
PHYSIO.MAC from Len Bosack dated 17-May-75, and it looks like
Tenex 1.34 started in January 1975, so it's possible that TOPS-20
began as late as Tenex 1.33.
-------
24-May-2005 20:01:44-PDT,7401;000000000000
Return-Path: <carl@reststop.com>
Received: from smtpauth06.mail.atl.earthlink.net ([209.86.89.66]) by lingling.panda.com with TCP/SMTP; Tue, 24 May 2005 19:49:15 -0700 (PDT)
Received: from [24.221.177.162] (helo=[204.238.239.105])
by smtpauth06.mail.atl.earthlink.net with asmtp (Exim 4.34)
id 1DalxK-0007ep-UV; Tue, 24 May 2005 22:49:15 -0400
In-Reply-To: <398d488b1204e2ba426c78bdc7ec60af@reststop.com>
References: <200505250034.TAA14392@labuena.amd.com> <398d488b1204e2ba426c78bdc7ec60af@reststop.com>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <5d9f4b278cc5abb3897adb89c75256ec@reststop.com>
Content-Transfer-Encoding: 7bit
Cc: TOPS-20@lingling.panda.com,
beebe@math.utah.edu,
"Clive Dawson" <clive.dawson@amd.com>,
billw@cisco.com
From: Carl Baltrunas <carl@reststop.com>
Subject: Re: PDP-10 history: catalog of O/Ses -- PS
Date: Tue, 24 May 2005 19:49:12 -0700
To: Carl Baltrunas <carl@reststop.com>
X-Mailer: Apple Mail (2.622)
X-ELNK-Trace: 657dc9a5ceb70f7f3e74c9a82e36a01394f5150ab1c16ac06b48d29827cfba20becdb55da7340c63048ca60730777d58350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 24.221.177.162
Two more sets that I've overlooked.... someone can fill in for the
remaining info...
At Tymshare, we had Doug Englebart (creator of the mouse) and his
Augment project which ran under "August", a modified version of Tenex.
It was running on KA-10s, KIs, KLs, Foonly F4s and 26KLs.
Dave Poole of Stanford and Foonly fame created the Foonly F1, F2, F3
and F4. The F1 project was a fast machine and really introduced KL
paging which DEC reconstructed for their TOPS-20. The F2 never saw the
light of day (I'm pretty sure that was what I heard). The F3 was a
competitor for the 2020 and was able to run a modified Tenex, and
TYMCOM-X/XX. The F4 was also re-dubbed by McDonnell Douglas, the 26KL,
and ran a modified Tenex/August OS.
Tymshare, aka McDonnell Douglas Field Service Company, took the F3/F4
designs and created a TOAD, but the project was scrapped shortly after
they had working prototypes as management felt that the manufacturing
costs would not cover actual production of the new machines due to
actual low demands.
The other missing OS is the one run on MAX-A, MAX-B and MAX-C at PARC.
They were on the ARPAnet but I do not know if they were running a
version of Tenex or something that XEROX created. The scientists and
researchers at PARC were so taken by the PDP-10s that they wanted to
install a couple but were told by management that XEROX was a computer
maker and they would not allow their engineers to buy another company's
computers. So, the engineers built their own. They made 3 of them,
and that was all that was ever made (or so I had heard).
-Carl
On May 24, 2005, at 7:25 PM, Carl Baltrunas wrote:
> From what I recall visiting CMU and converting FINE from their OS to
> run on TOPS-10 (and later TYMCOM-X), they were pretty much a TOPS-10
> shop with modifications for user-id and terminal support. They had
> their own image mode when DEC gave the rest of us PIM or Packed Image
> Mode. Otherwise fairly vanilla compared to things like ITS or WAITS.
> Someone from CMU can correct me if I'm mistaken.
>
> BTW, thanks for the item about West-coast Alternative to ITS. I never
> knew that. I'll have to look in my WAITS monitor calls manual and see
> if it's listed in there.
>
> TOPS-10 was called "Bottoms-10" by a lot of by a lot of the Tenex or
> Twenex crowd because it didn't originally have networking or page
> mapping until the KI model was released. Even then, ANF-10 was the
> first networking it had, until the PDP-11 and VAXen had DECNET which
> was retrofit to work on TOPS-10.
>
> Both Compuserv and On-Line Systems had heavily modified systems to
> provide their customers with a more "commercial" look and feel. I
> recall hearing that On Line Systems started making their modifications
> back on the DECtape version of the OS. I only saw it when taking a
> tour for a job interview in 1980, but accepted a position at Tymshare
> instead.
>
> Tymshare had it's own custom OS called TYMCOM-X (and for the 2020s,
> TYMCOM-XX) which diverged from TOPS-10 at the 5.02 level. Things were
> added to match features with TOP-10 and some Tenex influences but
> remained custom. We used a very close relative to COMPIL which was
> originally written by Bill Wehir (sp?) or (WFW), which was called RPG.
> If you look at versions of COMPIL you can still find many of the same
> lines of code with the same comments. We had 4 different prompting
> modes, TYMCOM-IX (SDS-940), PDP-10, SUDS, and restricted (which ran a
> user level application immediately after LOGIN finished). Tymshare
> never got around to multiple structures, so we had one very large
> DSKB: structure striped across all of the disks. External memory,
> tape and disk drives were connected via an SA-10. Tape controllers
> and drives were all from STC and disks were AMPEX or Memorex drives we
> got as hand-me-downs from the IBM systems.
>
> Somewhere I have the "official" list that DEC supported in one of it's
> tables that allowed a program to poll the OS for which OS was running.
> It may even have made it into one of the JSYS entries... it's a good
> place to check.
>
> We also had a Tymshare partner in Paris and they maintained a separate
> set of sources for many of the CUSPs which then prompted users in
> French. I presume they watched whenever we came out with a new
> release to retrofit their changes into our code.
>
> Also, you may want to give Systems Concepts honorable mention for
> their changes to the OS to run on their SC30M and later models. (I
> forget where the "-" goes).
>
> Likewise, XKL in Redmond, WA had to make significant changes to both
> TOPS-20 and TOPS-10 in order to get them up and running on their
> TOAD-1s. I don't know how extensive the TOPS-10 changes were, but
> they also added a number of UNIX shell commands. TOPS-10 was running
> with console access on the TOAD but I do not know if Vance (aka Ernie)
> Socci or Ralph Gorin ever had network support for remote logins
> working. Check with Ralph for complete information on that.
>
>
> On May 24, 2005, at 5:34 PM, Clive Dawson wrote:
>
>>
>>> That leaves tops10, waits, its, tenex, and tops20 as the actual
>>> operating sytems used, I think. I suppose that it's amusing that ALL
>>> of them were still in use at the date the 36bit line was killed...
>>
>> Yes, I think Bill has pretty much covered the major variations.
>> As he said, TOPS10 had nothing to do with BBN's TENEX.
>>
>> But I wonder if anybody from CMU, Compuserve and/or TYMSHARE might
>> want to chime in. As I recall, the OS's running at those places were
>> heavily modified versions of the original DEC OS for the PDP-10, which
>> didn't become known officially as "TOPS-10" until DEC went to
>> "Level D" and the venerable version 4S72 was replaced with version 5,
>> as I recall.
>>
>> There is a lot of good info on this subject to be found at
>>
>> http://www.ultimate.com/phil/pdp10/
>>
>> along with plenty of links.
>>
>> Clive Dawson
>> AMD
>> Austin, TX
>>
>>
>>
>
24-May-2005 20:27:40-PDT,1928;000000000000
Return-Path: <wex@cs.uml.edu>
Received: from sccrmhc12.comcast.net ([204.127.202.56]) by lingling.panda.com with TCP/SMTP; Tue, 24 May 2005 20:20:29 -0700 (PDT)
Received: from [10.0.1.2] (c-24-91-108-249.hsd1.ma.comcast.net[24.91.108.249])
by comcast.net (sccrmhc12) with ESMTP
id <2005052503202701200a49rpe>; Wed, 25 May 2005 03:20:28 +0000
Mime-Version: 1.0
X-Sender: (Unverified)
Message-Id: <p06110402beb99e62c0b7@[10.0.1.2]>
In-Reply-To: <14028666827.10.MRC@lingling.panda.com>
References: <14028666827.10.MRC@lingling.panda.com>
Date: Tue, 24 May 2005 23:20:26 -0400
To: Mark Crispin <MRC@lingling.panda.com>, TOPS-20@lingling.panda.com
From: Paul Wexelblat <wex@cs.uml.edu>
Subject: Re: PDP-10 history: catalog of O/Ses
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
At 7:48 PM -0700 5/24/05, Mark Crispin wrote:
> > TOPS20 was DECs rewrite(?) of BBN TENEX, but no long had any
>> connection with BBN.
>
>DEC bought Tenex from BBN, and hired Dan Murphy (one of the two
>original authors of Tenex). That system became TOPS-20.
>
>TOPS-20 forked from Tenex before Tenex 1.34, but I don't know
>when exactly the fork happened. Unfortunately, DEC deleted a lot
>of old edit history in TOPS-20 sources so it's no longer possible
>to track when things happened. However, I see a SUBTTL in
>PHYSIO.MAC from Len Bosack dated 17-May-75, and it looks like
>Tenex 1.34 started in January 1975, so it's possible that TOPS-20
>began as late as Tenex 1.33.
>-------
Gee, I have code in TOPS-10, TOPS-20 (Inter-process communications
stuff - at DEC) Tenex (some Input routines for an ASCIIish noise
monitor- at BBN), and PA1050 (The compatibility package (at BBN)). Am
I the only one? Hadn't thought about that before
(PMW)
--
P.M. Wexelblat PhD
Dept. of Computer Science
University of Massachusetts Lowell
One University Ave
Lowell, MA 01854
24-May-2005 20:37:16-PDT,1402;000000000000
Return-Path: <phil@ultimate.com>
Received: from sccrmhc11.comcast.net ([204.127.202.55]) by lingling.panda.com with TCP/SMTP; Tue, 24 May 2005 20:30:21 -0700 (PDT)
Received: from c-66-30-204-193.hsd1.ma.comcast.net ([66.30.204.193])
by comcast.net (sccrmhc11) with ESMTP
id <2005052503302001100or35ge>; Wed, 25 May 2005 03:30:20 +0000
Received: (from phil@localhost)
by ultimate.com (8.12.10/8.12.10) id j4P3UJAm022994;
Tue, 24 May 2005 23:30:19 -0400 (EDT)
Date: Tue, 24 May 2005 23:30:19 -0400 (EDT)
From: Phil Budne <phil@ultimate.com>
Message-Id: <200505250330.j4P3UJAm022994@ultimate.com>
To: carl@reststop.com
Subject: Re: PDP-10 history: catalog of O/Ses -- PS
Cc: TOPS-20@lingling.panda.com, beebe@math.utah.edu, billw@cisco.com,
clive.dawson@amd.com
Butler Lampson has this to say about MAXC at
http://research.microsoft.com/~lampson/Systems.html#maxc
MAXC
(1971-3): I designed and implemented the micro-programmed processor
for a machine which emulated a PDP-10 [E. R. Fiala, The MAXC
systems, IEEE Computer 11, 5 (May 1978), pp 57-67]. It ran somewhat
faster than a KA-10, and much more reliably, more than once
attaining an interval of 2000 hours between crashes while running
the Tenex time-sharing system. Two of these machines were built;
each operated for about 9 years before being decommissioned.
24-May-2005 20:44:03-PDT,1875;000000000000
Mail-From: MRC created at 24-May-2005 20:37:46
Date: Tue, 24 May 2005 20:37:46 -0700 (PDT)
From: Mark Crispin <MRC@Lingling.Panda.COM>
Subject: Re: PDP-10 history: catalog of O/Ses
To: TOPS-20@Lingling.Panda.COM
In-Reply-To: <p06110402beb99e62c0b7@[10.0.1.2]>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14028675803.10.MRC@lingling.panda.com>
> Gee, I have code in TOPS-10, TOPS-20 (Inter-process communications
> stuff - at DEC) Tenex (some Input routines for an ASCIIish noise
> monitor- at BBN), and PA1050 (The compatibility package (at BBN)). Am
> I the only one? Hadn't thought about that before
Hmm, I can't claim something as good as that.
However, I did write the standard TELNET client for ITS, WAITS,
and TOPS-20 (my user interface was immortalized by Guy Steele in
"The Telnet Song" in the April 1984 Communications of the ACM) as
well as several of the network daemons for these three operating
systems.
I have written user programs (in more or less chronological
order): TOPS-10, ITS, CompuServe's TOPS-10 variant, Tenex, WAITS,
CMU's TOPS-10 variant, and TOPS-20; and have done kernel hacking
in WAITS, TOPS-20, and (very limited) ITS.
My very first kernel hacking project (strictly unauthorized) was
to convert WAITS' NCP to use 32-bit IMP addresses instead of
8-bit addresses. It took me about a week. I later found out
that BBN had been working on the corresponding project for Tenex
for quite a bit longer, and I apparently caused some embarassment
and consternation when I advertised my project (the first PDP-10
32-bit NCP). BBN set up a special TIP in the high address space
to debunk my claim, and were a bit unhappy to find that I had
succeeded. Then Dave Moon poured salt on the wounds by doing the
same thing for ITS' NCP in even less time.
-- Mark --
-------
24-May-2005 22:54:57-PDT,1459;000000000000
Return-Path: <billw@cisco.com>
Received: from sj-iport-1.cisco.com ([171.71.176.70]) by lingling.panda.com with TCP/SMTP; Tue, 24 May 2005 22:47:23 -0700 (PDT)
Received: from sj-core-1.cisco.com (171.71.177.237)
by sj-iport-1.cisco.com with ESMTP; 24 May 2005 22:47:24 -0700
X-IronPort-AV: i="3.93,134,1115017200";
d="scan'208"; a="638417872:sNHT25970376"
Received: from cisco.com (cypher.cisco.com [171.69.11.142])
by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4P5lLbw010166;
Tue, 24 May 2005 22:47:21 -0700 (PDT)
Received: (from billw@localhost)
by cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA28888;
Tue, 24 May 2005 22:47:20 -0700 (PDT)
Sender: Bill Westfield <billw@cisco.com>
Date: Tue, 24 May 2005 22:47:20 PDT
From: William "Chops" Westfield <billw@cisco.com>
To: Phil Budne <phil@ultimate.com>
Cc: carl@reststop.com, TOPS-20@lingling.panda.com, beebe@math.utah.edu,
clive.dawson@amd.com
Subject: Re: PDP-10 history: catalog of O/Ses -- PS
In-Reply-To: Your message of Tue, 24 May 2005 23:30:19 -0400 (EDT)
Message-ID: <CMM.0.90.4.1117000040.billw@cypher>
>> MaxC, Foonley, Systems Concepts, XKL...
I suppose it's a matter of deep thought for techno-philosophers, when to
say that an operating system has become "new", but I don't think merely
making the changes necessary to port to new hardware causes this to happen.
MaxC and Foonley ran Tenex, SC and XKL ran Tops (primarily.)
BillW
24-May-2005 23:28:45-PDT,2227;000000000000
Return-Path: <carl@reststop.com>
Received: from smtpauth01.mail.atl.earthlink.net ([209.86.89.61]) by lingling.panda.com with TCP/SMTP; Tue, 24 May 2005 23:21:30 -0700 (PDT)
Received: from [24.221.177.162] (helo=[204.238.239.105])
by smtpauth01.mail.atl.earthlink.net with asmtp (Exim 4.34)
id 1DapGk-0002dT-2f
for TOPS-20@lingling.panda.com; Wed, 25 May 2005 02:21:30 -0400
Mime-Version: 1.0 (Apple Message framework v622)
In-Reply-To: <CMM.0.90.4.1117000040.billw@cypher>
References: <CMM.0.90.4.1117000040.billw@cypher>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <d47d8216f68fd6d227bd91d3fb1ff100@reststop.com>
Content-Transfer-Encoding: 7bit
From: Carl Baltrunas <carl@reststop.com>
Subject: Re: PDP-10 history: catalog of O/Ses -- PS
Date: Tue, 24 May 2005 23:21:28 -0700
To: Tops-20 Wizards <TOPS-20@lingling.panda.com>
X-Mailer: Apple Mail (2.622)
X-ELNK-Trace: 657dc9a5ceb70f7f3e74c9a82e36a01394f5150ab1c16ac06b48d29827cfba20b9159e4b2bfb73b61749700a972b1698350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 24.221.177.162
On May 24, 2005, at 10:47 PM, William Chops Westfield wrote:
>>> MaxC, Foonley, Systems Concepts, XKL...
>
> I suppose it's a matter of deep thought for techno-philosophers, when
> to
> say that an operating system has become "new", but I don't think merely
> making the changes necessary to port to new hardware causes this to
> happen.
> MaxC and Foonley ran Tenex, SC and XKL ran Tops (primarily.)
>
> BillW
>
The Foonly ran Tenex, TYMCOM-X, August (Doug's variant of Tenex), and
TOPS-20 pretty much in that order. Changes to the microcode were
necessary, of course, and tweaks were made to support both KI and KL
style paging. The F3 ran Tenex and TYMCOM-X. The F4/26KL ran all
except TYMCOM-X.
I think they made microcode changes so that the F4 could run TYMCOM-X
but it never ran it.
The link someone had provided that said that PARC ran Tenex at least
answered the question if they had to write their own. I'd still swear
there were three, but you can't argue with one of the machine builders.
If he said they only built two, that third machine must have been
something else.
-Carl
25-May-2005 11:23:23-PDT,1783;000000000000
Return-Path: <rossman@columbia.edu>
Received: from brinza.cc.columbia.edu ([128.59.29.8]) by Lingling.Panda.COM with TCP/SMTP; Wed, 25 May 2005 11:16:47 -0700 (PDT)
Received: from [192.168.0.101] (pcp09163523pcs.verona01.nj.comcast.net [69.141.118.203])
(user=rossman mech=PLAIN bits=0)
by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j4PFj9vn000387
(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT)
for <TOPS-20@lingling.panda.com>; Wed, 25 May 2005 11:45:10 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v730)
In-Reply-To: <14028665330.10.MRC@lingling.panda.com>
References: <14028665330.10.MRC@lingling.panda.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <EDB827D9-1F17-454F-A702-4A6E4CB20717@columbia.edu>
Content-Transfer-Encoding: 7bit
From: Ken Rossman <rossman@columbia.edu>
Subject: Re: PDP-10 history: catalog of O/Ses
Date: Wed, 25 May 2005 11:45:08 -0400
To: TOPS-20@lingling.panda.com
X-Mailer: Apple Mail (2.730)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8
On May 24, 2005, at 10:40 PM, Mark Crispin wrote:
> I know you could run TOPS-10 binaries on TOPS-20 systems, but not
> conversely. I rather doubt you could run an ITS or WAITS binary
> on anything but ITS or WAITS.
>
> Some WAITS binaries (most notably, SUDS and PUB) could run under
> ITS using DECUUO (the ITS equivalent of PA1050) set for SAIL
> emulation. You couldn't run the binary directly; you had to run
> DECUUO and then have DECUUO load the WAITS binary.
So did that make DECUUO an *emulator*, or did it merely sit "alongside"
the loaded WAITS binaries (in a similar fashion to PA1050) and catch
kernel calls and handle them?
Ken Rossman
rossman@columbia.edu
25-May-2005 12:17:11-PDT,1961;000000000000
Mail-From: MRC created at 25-May-2005 12:10:45
Date: Wed, 25 May 2005 12:10:45 -0700 (PDT)
From: Mark Crispin <MRC@Lingling.Panda.COM>
Subject: Re: PDP-10 history: catalog of O/Ses
To: TOPS-20@Lingling.Panda.COM
In-Reply-To: <EDB827D9-1F17-454F-A702-4A6E4CB20717@columbia.edu>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14028845648.10.MRC@Lingling.Panda.COM>
> So did that make DECUUO an *emulator*, or did it merely sit "alongside"
> the loaded WAITS binaries (in a similar fashion to PA1050) and catch
> kernel calls and handle them?
DECUUO was neither.
Like PA1050, DECUUO lived in the upper portion of the address
space, ran in user mode, received MUUOs, and issued appropriate
ITS UUOs to do what the TOPS-10 UUO would have done.
Unlike PA1050, DECUOO was an ITS program. Among its functions
was a loader that could read WAITS DMP files and TOPS-20 SAV (and
I think SHR) files and load them into the job's address space.
With PA1050, the first non-JSYS MUUO you did would cause the
TOPS-20 kernel to load PA1050 into your address space and set up
the traps to it. With DECUUO, this had to be done by explicitly
running DECUOO on the program.
Think of having to do something like:
@pa1050 sys:macro.exe
to run MACRO.
There is actually a good reason why DECUUO had to be that way;
there was overlap between TOPS-20 and ITS MUUOs. Fortunately,
the overlap was modest, and the overlapped ITS MUUOs could be
done in a different way. But this meant that there had to be a
system call that would disable the overlapping ITS MUUO so that
the MUUO would trap to DECUUO instead.
Since TOPS-20 only used JSYS as its system call (and on KAs with
Tenex it was a machine instruction not an MUUO) it was possible
to make PA1050 more seamless. Also, the TOPS-20 kernel could
recognize and load TOPS-10 EXE and SAV files (I don't remember if
TOPS-20 can do SHR files).
-------
26-May-2005 12:39:22-PDT,2870;000000000000
Return-Path: <beebe@math.utah.edu>
Received: from sunshine.math.utah.edu ([128.110.198.2]) by Lingling.Panda.COM with TCP/SMTP; Thu, 26 May 2005 12:32:30 -0700 (PDT)
Received: from psi.math.utah.edu (IDENT:Ae6kMt9eiMl11k7+ksC0HdtS+QF8ibaa@psi.math.utah.edu [155.101.96.19])
by sunshine.math.utah.edu (8.13.3/8.13.3) with ESMTP id j4QEraiS027984;
Thu, 26 May 2005 08:53:36 -0600 (MDT)
Received: from psi.math.utah.edu (IDENT:g+uD3qdAgvcwNEl6P+Ea+CwgzeywjBCQ@localhost [127.0.0.1])
by psi.math.utah.edu (8.12.11/8.12.10) with ESMTP id j4QEraur015971;
Thu, 26 May 2005 08:53:36 -0600 (MDT)
Received: (from beebe@localhost)
by psi.math.utah.edu (8.12.11/8.12.10/Submit) id j4QEraqB015969;
Thu, 26 May 2005 08:53:36 -0600 (MDT)
Date: Thu, 26 May 2005 08:53:36 -0600 (MDT)
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
To: TOPS-20@lingling.panda.com
Cc: beebe@math.utah.edu
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: Re: PDP-10 history: catalog of O/Ses
Message-ID: <CMM.0.92.0.1117119216.beebe@psi.math.utah.edu>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (sunshine.math.utah.edu [128.110.198.2]); Thu, 26 May 2005 08:53:36 -0600 (MDT)
Many thanks to the list members who responded to my request for a
verification of the list of operating systems that ran on the PDP-10.
I think that it is important to get history recorded, and I've done a
bit in that direction in the preprint of my conference talk:
Keynote address: The design of TeX and METAFONT: A retrospective
http://www.math.utah.edu/~beebe/publications/2005/pt2005.pdf
I'm giving that talk at Practical TeX 2005 next month in Chapel Hill,
NC, and a similar talk at TUG 2005 in Wuhan, China, in August.
Comments about the article via email to me offlist are welcome; they
need not clutter this list. The proceedings won't be published for
several months, so there is time to repair any mistakes or omissions.
I have some TO-DO items left for the article, but I had a deadline of
midnight last night for the preprint volume printing that I barely
made.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
- 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
28-May-2005 19:28:10-PDT,17269;000000000000
Return-Path: <fw@well.com>
Received: from b.mail.sonic.net ([64.142.19.5]) by lingling.panda.com with TCP/SMTP; Sat, 28 May 2005 19:21:18 -0700 (PDT)
Received: from Amiga.local (64-142-29-113.dsl.static.sonic.net [64.142.29.113])
by b.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j4T2LGuK004997
for <TOPS-20@lingling.panda.com>; Sat, 28 May 2005 19:21:16 -0700
Date: Sat, 28 May 2005 19:21:15 -0700 (PDT)
From: Fred Wright <fw@well.com>
X-Sender: fw@Amiga.local
Reply-To: Fred Wright <fw@well.com>
To: TOPS-20@lingling.panda.com
Subject: Re: PDP-10 history: catalog of O/Ses
In-Reply-To: <14028845648.10.MRC@Lingling.Panda.COM>
Message-ID: <Pine.AMI.4.21.0505281524170.167059480-100000@Amiga.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 24 May 2005, Clive Dawson wrote:
> Yes, I think Bill has pretty much covered the major variations.
> As he said, TOPS10 had nothing to do with BBN's TENEX.
True, and as someone pointed out, "TOPS-10" was just a rename of a system
formerly just referred to as "Monitor", which dated back to the PDP-6
*long* before TENEX. Early versions came in both a timesharing and a
single-user flavor, so that one could write standalone programs using some
of the same UUOs. Although I don't have the manual handy for the exact
quote, my favorite line from the beginning of the AID manual goes
something like:
-----------------------------------------------------------------------
AID requires 11K of core, and won't run on a 16K machine if the Monitor
requires more than 5K.
-----------------------------------------------------------------------
Not only did TENEX have nothing to do with TOPS-10, but also it wasn't
really a new design in its own right, being merely a rewrite of the SDS
940 system for the PDP-10. The 940 system, as well as the hardware
enhancements that turned the 930 into the 940, came from Project Genie at
UC Berkeley. The hardware enhancements were taken over by SDS (later XDS)
to become the 940, though I'm not sure if SDS distributed a version of the
Project Genie OS or not. There were certainly service bureaus running it,
though, since I recall using one of them in '68.
The 940 OS (mostly written by Peter Deutsch) was based on paging, viewed
memory primarily as a cache for drum, had jobs with multiple forks which
could optionally share pages, used the topmost fork of the job for the
"shell", and had command and filename completion. Sound familiar?
Although the 940 only had a 16KW (24 bits) address space (64KW physical),
the OS made page switching fairly convenient (and reasonably efficient) so
that programs could "juggle their way" around that with overlays.
BBN had developed a popular LISP implementation that ran on the 940, and
was getting squeezed by the limited address space. They wanted to move to
another machine with more addressing, and the PDP-10 seemed like a good
candidate, but it lacked paging (this was years before the KI). So they
decided to build their own pager for the KA10, with some rather complex
features designed to put some of the 940 OS's mechanisms into
hardware. They also came up with the ugliest "fixes" for the KA10's
difficulties with recoverable memory protect violations anywhere (and a
step backwards from the 940). I know of at least three cases of fixing
this "right", before DEC started getting it right on the KI and later.
TENEX was really not much more than a port of the 940 OS to the PDP-10,
except for changing some things that didn't scale well to larger address
spaces and storage devices. I can recall seeing TENEX code that looked
literally like a line-by-line translation of 940 code, right down to using
only three registers (like the 940's A, B, and X), and with half the
instructions being MOVEs and MOVEMs since you can't keep much in three
registers. They did, however, use a stack and PUSHJ/POPJ instead of
JSR/JRST. :-) The exception model for system calls was as ugly as their
hardware, instead of adopting an ITS-like PCLSR approach - another step
backwards from the 940 system, which in essence had simplified PCLSR.
When ARPA got onto their kick of wanting to standardize on a single PDP-10
OS for all ARPA sites, TENEX was the only available choice that supported
paging, which of course was a highly desirable feature. Thus, TENEX was
selected as the "ARPA standard" OS on that basis alone. However, BBN had
initially designed TENEX solely as a vehicle to support BBN LISP. It was
designed almost in a vacuum, drawing only from the 940 system while
ignoring the substantial benefits of some of the features in ITS and
WAITS. Needels to say, there was a lot of kicking and screaming over the
prospect of giving up important features just so that some bureaucrats in
DC could see the same commands no matter what ARPAnet site they connected
to, and eventually ARPA relented on the "TENEX mandate". DEC's
willingness to take over TENEX and turn it into TOPS-20 may have played a
part in this; I'm not sure.
One of the things DEC did with TOPS-20 was to junk the TENEX filesystem,
which was widely known to be the most unreliable of all PDP-10
filesystems, and start over. It's still not as robust as the TOPS-10
filesystem, but it's a lot better than TENEX. The flaky TENEX filesystem
was probably also a 940 legacy, but the 940 only used it on the drum.
Long-term storage was either on magtape (and it had an elaborate means for
allowing magtape files to be overwritten in place), or on disk partitions
accessed purely through a user program called KDF (Kludge Disk Files).
Restoring the drum filesystem from tape was a frequent occurrence.
On Tue, 24 May 2005, Carl Baltrunas wrote:
> Tymshare had it's own custom OS called TYMCOM-X (and for the 2020s,
> TYMCOM-XX) which diverged from TOPS-10 at the 5.02 level. Things were
> added to match features with TOP-10 and some Tenex influences but
> remained custom. We used a very close relative to COMPIL which was
> originally written by Bill Wehir (sp?) or (WFW), which was called RPG.
Actually, the *very* original author was Dick Gruen. Officially, "RPG"
stood for "Rapid Program Generation". It was of course mere coincidence
that it happened to be written by Richard P. Gruen. :-) But indeed much
more of the code was from Bill Weiher.
> structure striped across all of the disks. External memory, tape and
> disk drives were connected via an SA-10. Tape controllers and drives
> were all from STC and disks were AMPEX or Memorex drives we got as
> hand-me-downs from the IBM systems.
Well, I'm pretty sure your *memory* wasn't connected via an SA10. :-) But
it may have been from SC as well, since we did build some PDP-10 add-on
memory (including a fast 20-port memory for the ILLIAC-IV complex).
> Somewhere I have the "official" list that DEC supported in one of it's
> tables that allowed a program to poll the OS for which OS was running.
> It may even have made it into one of the JSYS entries... it's a good
> place to check.
One of the CALLIs is GETTAB, which is the general call for obtaining
information from published system tables. One particular entry (112) of
one particular table (11) includes the OS type code. TOPS-20 has a
special kludge that handles that one case directly without mapping in
PA1050, so that a "TOPS-36" program which uses that as its very first
system call can decide which kind of calls to use without a gratuitous
PA1050. I don't know if this works on ITS, since I don't remember what
ITS call that would be (it's opcode 47, which is in the ITS range).
Naturally, a *fully* portable program should check user mode before
executing any UUOs.
> We also had a Tymshare partner in Paris and they maintained a separate
> set of sources for many of the CUSPs which then prompted users in
> French. I presume they watched whenever we came out with a new release
> to retrofit their changes into our code.
I imagine that was a legal requirement. :-)
> Also, you may want to give Systems Concepts honorable mention for their
> changes to the OS to run on their SC30M and later models. (I forget
> where the "-" goes).
If it's there, it would be "SC-30", although I've always preferred to use
"SC30". And nobody ever used the letter except in "marketing stuff".
The changes *required* to run either TOPS-10 or TOPS-20 on the SC30 or
SC40 are zero, since they're fully upward-compatible with the KL (at my
insistence), though IIRC the TOPS-20 NI code needs a trivial patch to get
around some stupid program-delay timeout during the fake "microcode
load" or some such. I actually came up with a scheme to eliminate even
that incompatibility, but never got around to implementing it.
One of the things that impressed one of the SC30 customers (besides the
speed) was the way they were able to bring their own RP06 pack to our
site, stick it in the drive, boot their TOPS-20, and run their
applications.
Of course if you want to run non-DEC-compatible *channels*, you need
drivers, and if you want to use more than 4MW of memory you need a bunch
of fixes, etc.
On Tue, 24 May 2005, Carl Baltrunas wrote:
> Dave Poole of Stanford and Foonly fame created the Foonly F1, F2, F3
I'm pretty sure that Foonly Inc. involved Phil Petit as well as Dave
Poole, and I think Jack Holloway was somewhat involved as well.
> and F4. The F1 project was a fast machine and really introduced KL
It was fast for its day, but the SC30 was just as fast, and the SC40 was
much faster. Both were much more "manufacturable". :-)
> paging which DEC reconstructed for their TOPS-20. The F2 never saw the
Meaning that DEC actually used stuff from the F1, or just that they
independently adapted the BBN pager architecture to the KL?
As far back as Super Foonly (which was pre-KI), it was recognized that the
machine would have paging, and would probably need to support some variant
of the BBN pager architecture, and possibly the MIT/ITS pager architecture
(Holloway's design) as well, but I'm not sure how much that part was
nailed down by the time the plug was pulled.
On Wed, 25 May 2005, Mark Crispin wrote:
> > So did that make DECUUO an *emulator*, or did it merely sit "alongside"
> > the loaded WAITS binaries (in a similar fashion to PA1050) and catch
> > kernel calls and handle them?
>
> DECUUO was neither.
>
> Like PA1050, DECUUO lived in the upper portion of the address
Are you sure about that, or are you just looking at it through
"TOPS-20-colored glasses"? Because it certainly differs from the way I
envisioned it when I implemented the support for it. I made the hardware
and OS changes necessary to make DEC monitor emulation possible, but left
the user-mode portion as an exercise for the reader. Note that this was
on the *PDP-6*, which didn't even have dual protect-relocate, let alone
paging (though I'm not sure if the complete feature was ever implemented
on the -6).
Mapping emulation code into the target address space is a bad idea, albeit
an unavoidable one in some cases. Aside from the lack of emulation
accuracy when "other stuff" is in the address space, not to mention the
possibility for strange bugs when emualtor *storage* is in the target
address space, there's also the risk of collision with the target code.
I've sometimes had undesirable constraints imposed on the layout of
TOPS-10 code by the desire to be compatible with PA1050. Of course that
would have been considerably alleviated if PA1050 had ever learned to run
extended (nad *completely* alleviated until such time as PA1050 actually
supported TOPS-10 extended addressing).
For an emulation to be "invisible", either the host needs a larger address
space than the target, or the host and target have to have distinct
address spaces. The VAX's PDP-11 emulation won by virtue of the former,
and I'd intended ITS's "DEC monitor mode" to rely on the latter.
ITS has the concept of multiple "jobs" arranged in a tree, somewhat more
like Unix processes than TOPS-20 forks, but more compartmentalized in that
each job has its own I/O as well as memory. There are software interrupts
(something like Unix signals), some of which stop the affected job and
interrupt its superior. Class 1 interrupts do this always, class 2
interrupts do this by default but can interrupt the affected job instead
when enabled to do so, and class 3 interrupts either interrupt the
affected job or are ignored. The idea here was that a job could enable
"DEC monitor mode" for an inferior, which would cause all MUUOs executed
by that inferior to generate class 1 interrupts. There were already
calls permitting a job to read and/or write any portion of an inferior's
address space, so shared mapping was never a requirement (and not even a
possibility at the time). This wasn't intended to be blindingly fast,
just usable.
This also required a hardware change to the MIT PDP-6, related to the
definition of "MUUO". In the original PDP-6 design, all UUOs were MUUOs,
and hence trapped into exec mode using exec 40/41. The MAC hackers
realized that UUOs are a useful construct within programs, and that the
overhead of trapping through the OS in that case is undesirable, so the
logic was modified to trap some UUOs through user 40/41 with no mode
switch. ITS was very sparing in its use of major opcodes for system
calls, fitting entirely into the 40-47 range. So the modified PDP-6
only trapped 0 and 40-47 (and illegal instructions) to exec mode, with
1-37 and 50-77 being LUUOs.
Clearly the emulation couldn't work if some DEC UUOs didn't trap to the OS
at all, so this had to be changed. Greenblatt and I discussed this, since
some user programs took advantage of the dual ranges to allow two
independent parts of the code to allocate UUO opcodes independently.
However, we decided that 1-37 was sufficient for the total *number* of
LUUOs, and that one could still get dual allocation by allocating one
group from the top down, and that fixing a few programs was a worthwhile
price for not having to take ITS down whenever someone wanted to run a DEC
program. I believe ITS already had code to turn non-ITS MUUOs into LUUOs
in the normal case (probably dating back to before the hardware change),
so the only impact of turning 50-77 into MUUOs in the hardware on such
unupdated programs would be a performance penalty. And of course, all
PDP-10 processors have adopted this definition of LUUO vs. MUUO.
The actual hardware change to the PDP-6 was pretty trivial (aside from
having to do it by soldering instead of wire-wrapping). So trivial in
fact, that I not only didn't bother to power the machine off to make the
change (and risk killing a 6205), but I also made the mod with ITS running
and real users on. Hey, it was only the instruction decoding logic. :-)
> Unlike PA1050, DECUOO was an ITS program. Among its functions
> was a loader that could read WAITS DMP files and TOPS-20 SAV (and
> I think SHR) files and load them into the job's address space.
That *could have* been avoided by building the necessary support into DDT
(the ITS equivalent to the EXEC), but I guess nobody considered that
important.
> With PA1050, the first non-JSYS MUUO you did would cause the
> TOPS-20 kernel to load PA1050 into your address space and set up
> the traps to it. With DECUUO, this had to be done by explicitly
Except of course for the %CNMNT GETTAB as noted above.
> There is actually a good reason why DECUUO had to be that way;
> there was overlap between TOPS-20 and ITS MUUOs. Fortunately,
Umm, TOPS-10 and ITS MUUOs.
> the overlap was modest, and the overlapped ITS MUUOs could be
> done in a different way. But this meant that there had to be a
> system call that would disable the overlapping ITS MUUO so that
> the MUUO would trap to DECUUO instead.
"Modest"? From the ITS point of view, the "overlap" is total. But as
long as the emulator runs as a different job (without the emulation mode
enabled) there's no conflict.
> Since TOPS-20 only used JSYS as its system call (and on KAs with
> Tenex it was a machine instruction not an MUUO) it was possible
> to make PA1050 more seamless. Also, the TOPS-20 kernel could
> recognize and load TOPS-10 EXE and SAV files (I don't remember if
> TOPS-20 can do SHR files).
A complete "old-style" loader would need to accomodate SAV, LOW, HGH, and
SHR, though even TOPS-10 deprecated those a while back.
On the flip side, when I ported the TOPS-20 TCP/IP code to TOPS-10, I
implemented the JSYSes as JSYSes. It seemed pointless to have a "JSYS
version" and "MUUO version" of each call (though some DEC "TOPS-36"
mechanisms tend to do something like that). In the process, I threw in a
few simple non-network JSYSes as well. I added a separate bit to the
%CNMNT GETTAB to indicate whether JSYSes are supported - once you know
they are you can use ERJMP et al in the usual way to test specific cases
without elaborate trap intercepts.
Fred Wright
30-May-2005 08:41:19-PDT,2006;000000000000
Return-Path: <AMartin.MA.UltraNet@RCN.Com>
Received: from smtp05.mrf.mail.rcn.net ([207.172.4.64]) by lingling.panda.com with TCP/SMTP; Mon, 30 May 2005 08:33:46 -0700 (PDT)
Received: from 207-172-216-91.s853.apx1.sbo.ma.dialup.rcn.com (HELO RCN.Com) (207.172.216.91)
by smtp05.mrf.mail.rcn.net with ESMTP; 30 May 2005 11:32:41 -0400
Message-ID: <429B31DE.E58A9390@RCN.Com>
Date: Mon, 30 May 2005 11:31:42 -0400
From: "Alan H. Martin" <AMartin.MA.UltraNet@RCN.Com>
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en,en-US,en-GB,es
MIME-Version: 1.0
To: Fred Wright <fw@well.com>
CC: TOPS-20@lingling.panda.com
Subject: Re: PDP-10 history: catalog of O/Ses
References: <Pine.AMI.4.21.0505281524170.167059480-100000@Amiga.local>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Fred Wright wrote:
>
> On Tue, 24 May 2005, Clive Dawson wrote:
>
> > Yes, I think Bill has pretty much covered the major variations.
> > As he said, TOPS10 had nothing to do with BBN's TENEX.
>
> True, and as someone pointed out, "TOPS-10" was just a rename of a system
> formerly just referred to as "Monitor", which dated back to the PDP-6
> *long* before TENEX. .... Although I don't have the manual handy for the exact
> quote, my favorite line from the beginning of the AID manual goes
> something like:
>
> -----------------------------------------------------------------------
> AID requires 11K of core, and won't run on a 16K machine if the Monitor
> requires more than 5K.
> -----------------------------------------------------------------------
AID runs in approximately 11K of core memory (with 1K of user
data area) and expands to 14K of core (with 4K of user data
area) as required. Note that AID will not run on a 16K
machine if Monitor occupies more than 5K of core.
- _AID_,
_PDP-10 Timesharing Handbook_,
Copyright 1968, 1969, 1970
/AHM
--
Alan Howard Martin AMartin.MA.UltraNet@RCN.Com
30-May-2005 23:06:42-PDT,2640;000000000000
Mail-From: MRC created at 30-May-2005 22:59:53
Date: Mon, 30 May 2005 22:59:53 -0700 (PDT)
From: Mark Crispin <MRC@Lingling.Panda.COM>
Subject: Re: PDP-10 history: catalog of O/Ses
To: fw@well.com
cc: TOPS-20@Lingling.Panda.COM
In-Reply-To: <Pine.AMI.4.21.0505281524170.167059480-100000@Amiga.local>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14030274540.10.MRC@lingling.panda.com>
> One of the CALLIs is GETTAB, which is the general call for obtaining
> information from published system tables. One particular entry (112) of
> one particular table (11) includes the OS type code. TOPS-20 has a
> special kludge that handles that one case directly without mapping in
> PA1050, so that a "TOPS-36" program which uses that as its very first
> system call can decide which kind of calls to use without a gratuitous
> PA1050. I don't know if this works on ITS
This was implemented in DECUUO on ITS but not in the monitor since CALLI
conflicted with .ACCES on ITS.
> > Like PA1050, DECUUO lived in the upper portion of the address
> Are you sure about that, or are you just looking at it through
> "TOPS-20-colored glasses"? Because it certainly differs from the way I
> envisioned it when I implemented the support for it.
Yes. I was the maintainer of DECUUO in the mid 1970s.
> I made the hardware
> and OS changes necessary to make DEC monitor emulation possible, but left
> the user-mode portion as an exercise for the reader.
I think Jack Holloway wrote the original DECUUO. Stallman hacked on it a
lot, and then me. Stallman probably hacked on it after me too.
> (and risk killing a 6205)
*Snicker*. I have a 6205 from Berkeley's PDP-6. A truly jaw-dropping
board. No wonder they went to tiny modules on the KA.
> > With PA1050, the first non-JSYS MUUO you did would cause the
> > TOPS-20 kernel to load PA1050 into your address space and set up
> > the traps to it. With DECUUO, this had to be done by explicitly
> Except of course for the %CNMNT GETTAB as noted above.
Correct, except that %CNMNT only did that on TOPS-20, not ITS.
> "Modest"? From the ITS point of view, the "overlap" is total.
Not at all. ITS used UUOs 40-47. TOPS-10 used UUOs 40, 41, 47-51, 55-100.
All ITS system calls could be accessed through one UUO: .CALL (043), so
there was no need to use the three ITS UUOs which conflicted with TOPS-10
UUOs: .IOT / CALL (040), .OPEN / INIT (041), and .ACCES / CALLI (047).
This may have been after your time in ITS. By the mid 1970s, .CALL was the
preferred way to do things.
-- Mark --
-------
31-May-2005 03:29:50-PDT,10765;000000000000
Return-Path: <carl@reststop.com>
Received: from smtpauth01.mail.atl.earthlink.net ([209.86.89.61]) by lingling.panda.com with TCP/SMTP; Tue, 31 May 2005 03:22:32 -0700 (PDT)
Received: from [24.221.177.162] (helo=[204.238.239.105])
by smtpauth01.mail.atl.earthlink.net with asmtp (Exim 4.34)
id 1Dd3tG-0000ar-6p; Tue, 31 May 2005 06:22:30 -0400
In-Reply-To: <Pine.AMI.4.21.0505281524170.167059480-100000@Amiga.local>
References: <Pine.AMI.4.21.0505281524170.167059480-100000@Amiga.local>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <a5bb9372e1461b516f5a54cae77d2b99@reststop.com>
Content-Transfer-Encoding: 7bit
Cc: TOPS-20@lingling.panda.com
From: Carl Baltrunas <carl@reststop.com>
Subject: Re: PDP-10 history: catalog of O/Ses
Date: Tue, 31 May 2005 03:22:28 -0700
To: Fred Wright <fw@well.com>
X-Mailer: Apple Mail (2.622)
X-ELNK-Trace: 657dc9a5ceb70f7f3e74c9a82e36a01394f5150ab1c16ac06b48d29827cfba20f43c8c91908013ea90f85249787c93e6350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 24.221.177.162
On May 28, 2005, at 7:21 PM, Fred Wright wrote:
> On Tue, 24 May 2005, Clive Dawson wrote:
>
>> Yes, I think Bill has pretty much covered the major variations.
>> As he said, TOPS10 had nothing to do with BBN's TENEX.
>
> Not only did TENEX have nothing to do with TOPS-10, but also it wasn't
> really a new design in its own right, being merely a rewrite of the SDS
> 940 system for the PDP-10. The 940 system, as well as the hardware
> enhancements that turned the 930 into the 940, came from Project Genie
> at
> UC Berkeley. The hardware enhancements were taken over by SDS (later
> XDS)
> to become the 940, though I'm not sure if SDS distributed a version of
> the
> Project Genie OS or not. There were certainly service bureaus running
> it,
> though, since I recall using one of them in '68.
This is interesting news here as one of those service bureaus was
Tymshare.
When I joined them in 1980, we had 21 SDS-940s up and running on Tymnet
as hosts 1-21. Our OS was called TYMCOM-IX. Some network services were
still running on those 940s including user validations and network
access
information.
On the PDP-10s about 90% of the users were by default set to TYMCOM-IX
mode, which provided nearly identical commands and syntax to the users.
Only the TYMCOM-X OS group and a few TOPS-10 customers were set to
PDP-10 mode which looked very much like TOPS-10 v5.02 with lots of
extensions. At our peak we had 54 PDP-10s running TYMCOM-X/XX and
as many as 11 or 12 F4s or 26KLs running TENEX or TOPS-20/August.
I would NEVER have made the comparison of the TYMCOM-IX commands
to be similar to TENEX or TOPS-20. It's quite possible that Tymshare
was
running their own highly modified OS on the 940s as well, but I wasn't
given
that impression. Now that you've piqued my interest, I'm going to have
to
check that out with one of my manager friends who did much of the 940
support while I was there. I may also have a TYMCOM-IX assembler
manual around somewhere,
>
> The 940 OS (mostly written by Peter Deutsch) was based on paging,
> viewed
> memory primarily as a cache for drum, had jobs with multiple forks
> which
> could optionally share pages, used the topmost fork of the job for the
> "shell", and had command and filename completion. Sound familiar?
> Although the 940 only had a 16KW (24 bits) address space (64KW
> physical),
> the OS made page switching fairly convenient (and reasonably
> efficient) so
> that programs could "juggle their way" around that with overlays.
Hmmm. I don't recall anything like that in TYMCOM-IX.
>
> TENEX was really not much more than a port of the 940 OS to the PDP-10,
> except for changing some things that didn't scale well to larger
> address
> spaces and storage devices. I can recall seeing TENEX code that looked
> literally like a line-by-line translation of 940 code, right down to
> using
> only three registers (like the 940's A, B, and X), and with half the
> instructions being MOVEs and MOVEMs since you can't keep much in three
> registers. They did, however, use a stack and PUSHJ/POPJ instead of
> JSR/JRST. :-) The exception model for system calls was as ugly as their
> hardware, instead of adopting an ITS-like PCLSR approach - another step
> backwards from the 940 system, which in essence had simplified PCLSR.
> The flaky TENEX filesystem
> was probably also a 940 legacy, but the 940 only used it on the drum.
> Long-term storage was either on magtape (and it had an elaborate means
> for
> allowing magtape files to be overwritten in place), or on disk
> partitions
> accessed purely through a user program called KDF (Kludge Disk Files).
> Restoring the drum filesystem from tape was a frequent occurrence.
The 940 tape drives actually wrote a sequence of bits to the tape
rather than
bytes or words that we normally think of with PDP-10 writing to tape.
So,
writing in-place was not that difficult. I recall seeing somewhere the
actual
bit patterns for tape marks, end of file markers, end of tape, etc. I
found it
amazing that some systems still did that.
>
> On Tue, 24 May 2005, Carl Baltrunas wrote:
>
>> Tymshare had it's own custom OS called TYMCOM-X (and for the 2020s,
>> TYMCOM-XX) which diverged from TOPS-10 at the 5.02 level. Things were
>> added to match features with TOP-10 and some Tenex influences but
>> remained custom. We used a very close relative to COMPIL which was
>> originally written by Bill Wehir (sp?) or (WFW), which was called RPG.
>
> Actually, the *very* original author was Dick Gruen. Officially, "RPG"
> stood for "Rapid Program Generation". It was of course mere
> coincidence
> that it happened to be written by Richard P. Gruen. :-) But indeed much
> more of the code was from Bill Weiher.
Actually I do recall Dick Gruen's name on the software. At Tymshare, I
was the last person to ever modify RPG, which seemed to carry the
sticky fingers curse. Last person to touch it had to fix all the
remaining
bugs. The only way to pass it on to someone else was to quit. :-)
>
>> structure striped across all of the disks. External memory, tape and
>> disk drives were connected via an SA-10. Tape controllers and drives
>> were all from STC and disks were AMPEX or Memorex drives we got as
>> hand-me-downs from the IBM systems.
>
> Well, I'm pretty sure your *memory* wasn't connected via an SA10. :-)
> But
> it may have been from SC as well, since we did build some PDP-10 add-on
> memory (including a fast 20-port memory for the ILLIAC-IV complex).
Well, it was and it wasn't. We used external, multi-port memory. If I
recall
correctly, the KI/KL used one port, the SA-10 used one port, and the
Tymnet
interface (a wire-wrapped board with several modules and it's own local
memory plugged into a Tymnet Engine (a 1-MB machine based on the
Interdata computer)). I'd swear that something was connected to a 4th
port, but my memory was failing. Since all disk and tape I/O went
through
the SA-10, I can't imagine why either the STC tape controllers or disk
drive controller would use another port, so I must be hallucinating.
>
>> Somewhere I have the "official" list that DEC supported in one of it's
>> tables that allowed a program to poll the OS for which OS was running.
>> It may even have made it into one of the JSYS entries... it's a good
>> place to check.
>
> One of the CALLIs is GETTAB, which is the general call for obtaining
> information from published system tables. One particular entry (112)
> of
> one particular table (11) includes the OS type code. TOPS-20 has a
> special kludge that handles that one case directly without mapping in
> PA1050, so that a "TOPS-36" program which uses that as its very first
> system call can decide which kind of calls to use without a gratuitous
> PA1050. I don't know if this works on ITS, since I don't remember what
> ITS call that would be (it's opcode 47, which is in the ITS range).
> Naturally, a *fully* portable program should check user mode before
> executing any UUOs.
That was it. The table included TOPS-10, TOPS-20, TENEX, ITS and
TYMCOM-X, not necessarily in that order. I don't recall that it had an
entry for WAITS, but it may have.
> Of course if you want to run non-DEC-compatible *channels*, you need
> drivers, and if you want to use more than 4MW of memory you need a
> bunch
> of fixes, etc.
We did use 4MW on several systems. One problem we ran into which
was funny when you think about it, was if we traipsed through the entire
page table for 4MW of physical memory on a page-fault, we would
completely invalidate/reload the cache table. This was quickly fixed
by making sure the page table was not cached, but it could have been
a great source of thrashing.
>
> On Tue, 24 May 2005, Carl Baltrunas wrote:
>
>> Dave Poole of Stanford and Foonly fame created the Foonly F1, F2, F3
>
> I'm pretty sure that Foonly Inc. involved Phil Petit as well as Dave
> Poole, and I think Jack Holloway was somewhat involved as well.
>
>> and F4. The F1 project was a fast machine and really introduced KL
>
> It was fast for its day, but the SC30 was just as fast, and the SC40
> was
> much faster. Both were much more "manufacturable". :-)
I only saw Dave Poole once when they brought him in to work on a
microcode problem on the F4 and all my other stories about him were
2nd hand. What I had heard was that he developed (with others) the
Foonly design while at Stanford. Somehow, DEC was given the
opportunity to evaluate the Foonly design before they had finished
hammering out the details for the KL and they co-opted much of
his design, but "broke it" as far as Dave was concerned. So Foonly
was formed to do it right. This may be hear-say, or even an urban
legend. If someone on this list actually knows what happened, I'd
love to hear the story.
To my understanding, one of the last times that Dave Poole had
visited Tymshare, shortly before I arrived, he and probably EVS
came in carrying a number of grocery bags which they proceeded
to take into the lab. The bags contained all the "parts" needed to
assemble a Foonly F3 which was to be used for OS development
by our group.
>
>> paging which DEC reconstructed for their TOPS-20. The F2 never saw
>> the
>
> Meaning that DEC actually used stuff from the F1, or just that they
> independently adapted the BBN pager architecture to the KL?
I have no real info on this. Just that Poole thought that DEC did it
wrong.
-Carl
31-May-2005 06:33:58-PDT,4665;000000000000
Return-Path: <beebe@math.utah.edu>
Received: from sunshine.math.utah.edu ([128.110.198.2]) by lingling.panda.com with TCP/SMTP; Tue, 31 May 2005 06:27:06 -0700 (PDT)
Received: from psi.math.utah.edu (IDENT:Or6+Rd25YB+G8KSbE0AQvn+Sv6gEAk1T@psi.math.utah.edu [155.101.96.19])
by sunshine.math.utah.edu (8.13.3/8.13.3) with ESMTP id j4VDR4U2008260;
Tue, 31 May 2005 07:27:04 -0600 (MDT)
Received: from psi.math.utah.edu (IDENT:7sAJiYVCrwodzXQvvl9p3wNQeMyXxz3w@localhost [127.0.0.1])
by psi.math.utah.edu (8.12.11/8.12.10) with ESMTP id j4VDR36q020497;
Tue, 31 May 2005 07:27:03 -0600 (MDT)
Received: (from beebe@localhost)
by psi.math.utah.edu (8.12.11/8.12.10/Submit) id j4VDR3La020496;
Tue, 31 May 2005 07:27:03 -0600 (MDT)
Date: Tue, 31 May 2005 07:27:03 -0600 (MDT)
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
To: TOPS-20@lingling.panda.com
Cc: beebe@math.utah.edu
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: Re: PDP-10 history: catalog of O/Ses
Message-ID: <CMM.0.92.0.1117546023.beebe@psi.math.utah.edu>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (sunshine.math.utah.edu [128.110.198.2]); Tue, 31 May 2005 07:27:04 -0600 (MDT)
Fred Wright <fw@well.com> writes on Sat, 28 May 2005 19:21:15 -0700 (PDT):
>> The 940 OS (mostly written by Peter Deutsch) was based on paging, ...
There are two such well-known people in computer science: one
publishes as "Peter Deutsch" or "Peter J. Deutsch" and founded Bunyip
Information Systems Inc. The other is "L. Peter Deutsch".
Which one was meant? I suspect the latter.
L. Peter Deutsch is the author of ghostscript, though now retired from
Aladdin Software and ghostscript work. I'm a long-time ghostscript
beta tester, and I had the great pleasure of having dinner with Peter
and his partner on a visit to the San Francisco Bay Area a couple of
years ago. Had I known then of his work on the PDP-10, we could have
had a topic for another dinner. He is cited in Fiala's May 1978
Computer article ``The Maxc Systems'' as the developer of the Byte
Lisp instruction set that was added to the Maxc PDP-10 systems.
Here's an interesting table from that paper:
>> ...
>> Table 2. Some 2000 microinstructions implement the Maxc system,
>> although 5000 more are used in the diagnostics.
>>
>> ==================================================
>> Use Instruction Count
>> ==================================================
>> PDP-10 instruction set 774
>> Interlisp instruction set 474
>> Tenex Map 157
>> Disk 228
>> I/O instructions 237
>> Priority interrupt system 107
>> Other 93
>>
>> Total 2038
>> Diagnostics ~5000
>> ==================================================
>> ...
The large size of the instruction is pretty amazing, although Fiala
notes several times that the cleanness of the PDP-10 design made it
possible to reuse circuitry for many different instructions.
Before reading this article, I was unaware of any work on extending
the PDP-10 instruction set. The PDP-11 was well-known for
user-written microcode extensions, but to do this on the PDP-10, I
guess that you had to design your own system like Fiala's group at
Xerox PARC did.
This morning, I scanned to PDF and OCR'ed the Fiala article, since the
online IEEE Computer archives only go back to 1978. I suppose for
copyright reasons, I cannot post it on the Internet, but I might be
convinced to make it available to list members on individual off-list
request.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
- 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
1-Jun-2005 15:54:19-PDT,2375;000000000000
Return-Path: <beebe@math.utah.edu>
Received: from sunshine.math.utah.edu ([128.110.198.2]) by lingling.panda.com with TCP/SMTP; Wed, 1 Jun 2005 15:47:20 -0700 (PDT)
Received: from psi.math.utah.edu (IDENT:6xG+cgYxjYhcAXitX/NtnvR1ABhWEgVw@psi.math.utah.edu [155.101.96.19])
by sunshine.math.utah.edu (8.13.3/8.13.3) with ESMTP id j51MlImj007017;
Wed, 1 Jun 2005 16:47:18 -0600 (MDT)
Received: from psi.math.utah.edu (IDENT:7cadSpjnn2CesdfWSpeovYJ09IggKA6c@localhost [127.0.0.1])
by psi.math.utah.edu (8.12.11/8.12.10) with ESMTP id j51MlIZr002639;
Wed, 1 Jun 2005 16:47:18 -0600 (MDT)
Received: (from beebe@localhost)
by psi.math.utah.edu (8.12.11/8.12.10/Submit) id j51MlHMV002638;
Wed, 1 Jun 2005 16:47:17 -0600 (MDT)
Date: Wed, 1 Jun 2005 16:47:17 -0600 (MDT)
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
To: tops-20@lingling.panda.com
Cc: beebe@math.utah.edu
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: BBN in the news
Message-ID: <CMM.0.92.0.1117666037.beebe@psi.math.utah.edu>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (sunshine.math.utah.edu [128.110.198.2]); Wed, 01 Jun 2005 16:47:18 -0600 (MDT)
Some of you may be interested in looking at the new issue of
IEEE Annals of Computing, April-June 2005:
Bolt Beranek and Newman: The First 40 Years
http://www.computer.org/pubs/annals
There are links from that page to the journal contents. Readers
with IEEE digital library memberships (or belonging to suitable
subscribing institutions) should be able to download electronic
copies of the articles in HTML or PDF.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
- 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
3-Jun-2005 21:56:47-PDT,827;000000000000
Mail-From: MRC created at 3-Jun-2005 21:40:06
Date: Fri, 3 Jun 2005 21:38:55 -0700 (PDT)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: TOPS-20 list messages leaked to Google
To: TOPS-20@lingling.panda.com
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14031308374.10.MRC@lingling.panda.com>
I just discovered that TOPS-20 mailing list messages have been leaked and
appear on Google groups via a newsgroup called fa.info-tops20 that apparently
was linked by the info-tops20.ifi.uio.no address in the TOPS-20 mailing
list.
That address has been removed from the TOPS-20 mailing list. I apologize for
any spam you may have received as result of your postings appearing in
Google. I know that I've received some spam at this (previously secret)
email address.
-------
4-Jun-2005 09:40:55-PDT,1055;000000000000
Return-Path: <phil@ultimate.com>
Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by lingling.panda.com with TCP/SMTP; Sat, 4 Jun 2005 09:33:35 -0700 (PDT)
Received: from c-66-30-204-193.hsd1.ma.comcast.net ([66.30.204.193])
by comcast.net (rwcrmhc12) with ESMTP
id <20050604163333014003ji10e>; Sat, 4 Jun 2005 16:33:33 +0000
Received: (from phil@localhost)
by ultimate.com (8.12.10/8.12.10) id j54GXWBQ001494;
Sat, 4 Jun 2005 12:33:32 -0400 (EDT)
Date: Sat, 4 Jun 2005 12:33:32 -0400 (EDT)
From: Phil Budne <phil@ultimate.com>
Message-Id: <200506041633.j54GXWBQ001494@ultimate.com>
To: MRC@lingling.panda.com, TOPS-20@lingling.panda.com
Subject: Re: TOPS-20 list messages leaked to Google
There has been some great info posted here, and I had been thinking it's
a shame if it wasn't being archived in a place that got picked up by search
engines. Perhaps the mail could be sanitized (by replacing the domain
name in e-mail addrs with some constant string), and forwarded on to
the usenet group?
phil
4-Jun-2005 14:03:18-PDT,684;000000000000
Mail-From: MRC created at 4-Jun-2005 13:56:42
Date: Sat, 4 Jun 2005 13:56:42 -0700 (PDT)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: Re: TOPS-20 list messages leaked to Google
To: phil@ultimate.com
cc: TOPS-20@lingling.panda.com
In-Reply-To: <200506041633.j54GXWBQ001494@ultimate.com>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14031486376.10.MRC@lingling.panda.com>
The mail is archived (in multiple places) but I do not want to
allow search engines to pick it up; at least not without my
consent and the consent of the list membership. So far, such
consent has not been sought, much less given.
-- Mark --
-------
21-Jun-2005 21:58:57-PDT,1355;000000000000
Mail-From: MRC created at 21-Jun-2005 21:54:42
Date: Tue, 21 Jun 2005 21:54:42 -0700 (PDT)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: starting DECnet on Ethernet?
To: TOPS-20@lingling.panda.com
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14036029839.10.MRC@lingling.panda.com>
Does anyone remember how to start DECnet on an NI?
I have two TOPS-20 systems on the same Ethernet, but I can't get them to
talk to each other. In NCP, I see that line NI-0-0 has state "on", but
circuit NI-0-0 has state "off". The command "set circuit ni-0-0 state on"
results in "Set Circuit Failed, Operation failure".
As far as I can tell, it goes into the bowels of the utterly undocumented
and unmaintainable NMLT20, from which no rational person can figure out
what's going on.
I saw in the DECNET.BWR file that DECnet wants to set the last two bytes
of the MAC address to match the DECnet node address. Thinking that this
may be the problem, I observed that on one machine the MAC address was
00:11:24:79:17:26. So, I swap bytes to get a DECNET address of 0x2617;
the high 6 bits are the area and the low 10 bits are the node number, so
that's a node address of 9.535 (decimal). I set that up as the system's
DECnet node address and rebooted, but no joy in Mudville.
-- Mark --
-------
21-Jun-2005 22:24:30-PDT,1067;000000000000
Return-Path: <phil@ultimate.com>
Received: from rwcrmhc14.comcast.net ([216.148.227.89]) by lingling.panda.com with TCP/SMTP; Tue, 21 Jun 2005 22:20:15 -0700 (PDT)
Received: from c-66-30-204-193.hsd1.ma.comcast.net ([66.30.204.193])
by comcast.net (rwcrmhc14) with ESMTP
id <20050622052010014008eqkee>; Wed, 22 Jun 2005 05:20:10 +0000
Received: (from phil@localhost)
by ultimate.com (8.13.4/8.13.4) id j5M5K92P005137;
Wed, 22 Jun 2005 01:20:09 -0400 (EDT)
Date: Wed, 22 Jun 2005 01:20:09 -0400 (EDT)
From: Phil Budne <phil@ultimate.com>
Message-Id: <200506220520.j5M5K92P005137@ultimate.com>
To: MRC@lingling.panda.com, TOPS-20@lingling.panda.com
Subject: Re: starting DECnet on Ethernet?
> I saw in the DECNET.BWR file that DECnet wants to set the last two bytes
> of the MAC address to match the DECnet node address.
More than that... DECnet wants to set the first four octets of your
MAC address to be AA-00-04-00
I woulda thunk it would do this for you when bringing up DECnet, but
you might as well give it a try.
21-Jun-2005 23:00:50-PDT,935;000000000000
Mail-From: MRC created at 21-Jun-2005 22:56:59
Date: Tue, 21 Jun 2005 22:56:59 -0700 (PDT)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: Re: starting DECnet on Ethernet?
To: phil@ultimate.com
cc: TOPS-20@lingling.panda.com
In-Reply-To: <200506220520.j5M5K92P005137@ultimate.com>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14036041179.10.MRC@lingling.panda.com>
> > I saw in the DECNET.BWR file that DECnet wants to set the last two bytes
> > of the MAC address to match the DECnet node address.
> More than that... DECnet wants to set the first four octets of your
> MAC address to be AA-00-04-00
Ugh. Where does it do that? Please don't tell me it's in NMLT20.
The MAC address can't be changed, because it's the same as the
host system's MAC address. I was hoping to get it so that it
wouldn't try to change it at all.
Is it the .SFSEA code in SMON%?
-------
21-Jun-2005 23:09:43-PDT,566;000000000000
Mail-From: MRC created at 21-Jun-2005 23:06:04
Date: Tue, 21 Jun 2005 23:06:04 -0700 (PDT)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: Re: starting DECnet on Ethernet?
To: phil@ultimate.com, TOPS-20@lingling.panda.com
In-Reply-To: <14036041179.10.MRC@lingling.panda.com>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14036042832.10.MRC@lingling.panda.com>
Double ugh. I found it. It's symbol RTRHIO in D36COM.MAC, and ROUTER.MAC
uses it in multiple places.
What were they thinking?
-- Mark --
-------
21-Jun-2005 23:35:03-PDT,1471;000000000000
Return-Path: <billw@cisco.com>
Received: from sj-iport-3.cisco.com ([171.71.176.72]) by lingling.panda.com with TCP/SMTP; Tue, 21 Jun 2005 23:30:49 -0700 (PDT)
Received: from sj-core-5.cisco.com (171.71.177.238)
by sj-iport-3.cisco.com with ESMTP; 21 Jun 2005 23:30:45 -0700
X-IronPort-AV: i="3.93,220,1115017200";
d="scan'208"; a="281674007:sNHT25799768"
Received: from cisco.com (cypher.cisco.com [171.69.11.142])
by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5M6Uhqi005157;
Tue, 21 Jun 2005 23:30:43 -0700 (PDT)
Received: (from billw@localhost)
by cisco.com (8.8.8-Cisco List Logging/8.8.8) id XAA25664;
Tue, 21 Jun 2005 23:30:36 -0700 (PDT)
Sender: Bill Westfield <billw@cisco.com>
Date: Tue, 21 Jun 2005 23:30:36 PDT
From: William "Chops" Westfield <billw@cisco.com>
To: Mark Crispin <MRC@lingling.panda.com>
Cc: phil@ultimate.com, TOPS-20@lingling.panda.com
Subject: Re: starting DECnet on Ethernet?
In-Reply-To: Your message of Tue, 21 Jun 2005 22:56:59 -0700 (PDT)
Message-ID: <CMM.0.90.4.1119421836.billw@cypher>
The MAC address can't be changed, because it's the same as the
host system's MAC address. I was hoping to get it so that it
wouldn't try to change it at all.
Note that modern ethernet controllers (of the sort that go in ia86 "micro
engines") usually support multiple mac addresses on a single controller.
I don't know if the "microcode" supports and API for that, though...
BillW
21-Jun-2005 23:41:34-PDT,1874;000000000000
Return-Path: <billw@cisco.com>
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by lingling.panda.com with TCP/SMTP; Tue, 21 Jun 2005 23:37:24 -0700 (PDT)
Received: from sj-core-2.cisco.com (171.71.177.254)
by sj-iport-5.cisco.com with ESMTP; 21 Jun 2005 23:37:18 -0700
Received: from cisco.com (cypher.cisco.com [171.69.11.142])
by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5M6bGlO011793;
Tue, 21 Jun 2005 23:37:16 -0700 (PDT)
Received: (from billw@localhost)
by cisco.com (8.8.8-Cisco List Logging/8.8.8) id XAA26921;
Tue, 21 Jun 2005 23:37:05 -0700 (PDT)
Sender: Bill Westfield <billw@cisco.com>
Date: Tue, 21 Jun 2005 23:37:05 PDT
From: William "Chops" Westfield <billw@cisco.com>
To: Mark Crispin <MRC@lingling.panda.com>
Cc: phil@ultimate.com, TOPS-20@lingling.panda.com
Subject: Re: starting DECnet on Ethernet?
In-Reply-To: Your message of Tue, 21 Jun 2005 23:06:04 -0700 (PDT)
Message-ID: <CMM.0.90.4.1119422225.billw@cypher>
What were they thinking?
They were probably thinking that they were one of the big three creators
of ethernet, and could do pretty much whatever they wanted. There's
some little known verbage in ethernet (and token ring) specs about
"localy defined" ethernet addresses. Presumably they were thinking all
of this rather before the ip community invented ARP. It was a long time
ago, remember. Xerox used raw ethernet addresses as XNS node
identifiers as well, although they didn't have so much in the way of
existing addressing infrastructure to remain compatible with.
There don't seem to be any downsides for most other protocols if the
ethernet switches "HW address" to the DECNet value. That's how cisco
(and everyone else) was able to create multi-protocol routers that
included DECNet support even before the fancy multi-address ethernet
chips showed up.
BillW
22-Jun-2005 00:16:29-PDT,3982;000000000000
Return-Path: <fw@well.com>
Received: from b.mail.sonic.net ([64.142.19.5]) by lingling.panda.com with TCP/SMTP; Wed, 22 Jun 2005 00:12:52 -0700 (PDT)
Received: from Amiga.local (64-142-29-113.dsl.static.sonic.net [64.142.29.113])
by b.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j5M7CmPi032383
for <TOPS-20@lingling.panda.com>; Wed, 22 Jun 2005 00:12:48 -0700
Date: Wed, 22 Jun 2005 00:12:48 -0700 (PDT)
From: Fred Wright <fw@well.com>
X-Sender: fw@Amiga.local
Reply-To: Fred Wright <fw@well.com>
To: TOPS-20@lingling.panda.com
Subject: Re: starting DECnet on Ethernet?
In-Reply-To: <14036042832.10.MRC@lingling.panda.com>
Message-ID: <Pine.AMI.4.21.0506212335140.165027672-100000@Amiga.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 21 Jun 2005, Mark Crispin wrote:
> > > I saw in the DECNET.BWR file that DECnet wants to set the last two bytes
> > > of the MAC address to match the DECnet node address.
> > More than that... DECnet wants to set the first four octets of your
> > MAC address to be AA-00-04-00
>
> Ugh. Where does it do that? Please don't tell me it's in NMLT20.
>
> The MAC address can't be changed, because it's the same as the
> host system's MAC address. I was hoping to get it so that it
> wouldn't try to change it at all.
You have no choice, if you want to use TOPS-20 DECnet.
On Tue, 21 Jun 2005, Mark Crispin wrote:
> Double ugh. I found it. It's symbol RTRHIO in D36COM.MAC, and ROUTER.MAC
> uses it in multiple places.
>
> What were they thinking?
DEC was always a bunch of complete idiots when it came to ARP-like issues.
I recall arguing with Stu Grossman about this. In fact, all the stuff for
the INTERNET-ETHERNET-MAPPINGS.BIN file suggests that they only grudgingly
supported ARP for IP. :-)
All versions of DECnet up through Phase IV lack the equivalent of ARP, and
demand that there be a 1:1 correspondence between DECnet addresses and MAC
addresses, as noted above. AIUI they finally fixed that in Phase V, but
TOPS-20 never got past Phase IV. So the only way to use TOPS-20 DECnet
with an emulator is either to clobber the NIC's MAC address to the DECnet
value, or to simulate an additional MAC address with promiscuous mode
(unless it actually supports multiple unicast addesses in the hardware and
OS). This creates a strong motivation to have a separate dedicated NIC
just for the emulator. It also caused me to put in a delay for initial
LAT multicasts, because some LAT implementations refuse to talk to a host
that changes its MAC address (for "security" reasons).
This stuff is controlled by the NODE and ETHERNET statements read from
7-CONFIG.CMD by SETSPD. It may *also* be possible to fiddle it with NCP
commands, but that's not the normal way it's set.
They had a similar crock for IPCI, where the low byte of the IP address
was expected to match the CI node number. I fixed that by implementing a
"trafficless" ARP exchange by using the SCA "connection data" to exchange
IP addresses with the peer nodes.
On Tue, 21 Jun 2005, William Chops Westfield wrote:
> There don't seem to be any downsides for most other protocols if the
> ethernet switches "HW address" to the DECNet value. That's how cisco
> (and everyone else) was able to create multi-protocol routers that
> included DECNet support even before the fancy multi-address ethernet
> chips showed up.
As I pointed out to Stu years ago, this is analogous to designing a device
with a built-in terminator which hence demands that it be installed at the
end of the bus. When you get *two* devices that *both* want to be "last",
you're in big trouble. Similarly, running multiple protocols demanding
specific MAC address assignments won't work. The only "fair" thing to do
is to insist that *no* protocol demand a specific MAC address. Apparently
DEC eventually agreed, but too late for TOPS-20 (or TOPS-10).
Fred Wright
22-Jun-2005 04:12:45-PDT,1704;000000000000
Return-Path: <rossman@columbia.edu>
Received: from serrano.cc.columbia.edu ([128.59.29.6]) by lingling.panda.com with TCP/SMTP; Wed, 22 Jun 2005 04:08:56 -0700 (PDT)
Received: from [192.168.0.101] (pcp09163523pcs.verona01.nj.comcast.net [69.141.118.203])
(user=rossman mech=PLAIN bits=0)
by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5MB56uF019411
(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT);
Wed, 22 Jun 2005 07:05:06 -0400 (EDT)
In-Reply-To: <CMM.0.90.4.1119422225.billw@cypher>
References: <CMM.0.90.4.1119422225.billw@cypher>
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <17B3EFF7-AD84-4D35-87CD-3663FE3234C8@columbia.edu>
Cc: Ken Rossman <rossman@columbia.edu>
Content-Transfer-Encoding: 7bit
From: Ken Rossman <rossman@columbia.edu>
Subject: Re: starting DECnet on Ethernet?
Date: Wed, 22 Jun 2005 07:05:06 -0400
To: TOPS-20@lingling.panda.com
X-Mailer: Apple Mail (2.730)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6
My impression of this whole MAC address transformation thing with DECnet
always was that this was DEC's way of getting around having to have any
official ARP protocol equivalent. Why do address resolution when you
can
do address *calculation* instead? I guess DEC thought that maybe DECnet
was going to eventually be THE network protocol or something.
Things get even more fun when you have a diskless workstation on the
network
that you then want to run DECnet on also (as I did way back when)...
somehow
I made it work, but it wasn't pretty. I eventually gave up trying to
run DECnet.
K
22-Jun-2005 04:20:56-PDT,3313;000000000000
Return-Path: <tpb@doctor.zk3.dec.com>
Received: from palrel12.hp.com ([156.153.255.237]) by lingling.panda.com with TCP/SMTP; Wed, 22 Jun 2005 04:16:44 -0700 (PDT)
Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152])
by palrel12.hp.com (Postfix) with ESMTP id A9E3C403858;
Wed, 22 Jun 2005 04:16:40 -0700 (PDT)
Received: from yquarry.zk3.dec.com (brrquarry.zk3.dec.com [16.141.56.3])
by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 56AFC4D3;
Wed, 22 Jun 2005 04:16:37 -0700 (PDT)
Received: from doctor.zk3.dec.com by yquarry.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM)
id HAA09318; Wed, 22 Jun 2005 07:16:39 -0400 (EDT)
Received: from localhost by doctor.zk3.dec.com (8.8.8/1.1.22.3/07Jun00-0914PM)
id HAA0000010967; Wed, 22 Jun 2005 07:16:38 -0400 (EDT)
Message-Id: <200506221116.HAA0000010967@doctor.zk3.dec.com>
X-Authentication-Warning: doctor.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol
To: Mark Crispin <MRC@lingling.panda.com>
Cc: TOPS-20@lingling.panda.com
Subject: Re: starting DECnet on Ethernet?
In-reply-to: Your message of "Tue, 21 Jun 2005 23:06:04 PDT."
Date: Wed, 22 Jun 2005 07:16:37 -0400
From: "Dr Thomas.Blinn@HP.com" <tpb@doctor.zk3.dec.com>
X-Mts: smtp
> What were they thinking?
They were thinking that they "owned" the network and the hardware and
that every possible future "NI" built would support doing what they
were doing, to wit, setting the MAC address with software. It worked
fine for DECnet, which was always an intranet, it would be a bad idea
for routed TCP/IP but that's not DECnet. IIRC, other DECnet stacks of
the era did the same thing and it was all interoperable and so on..
It probably wasn't really necessary, provided each NI really had its
own unique MAC address, but using the hardware address introduces a
level of complexity in terms of discovering the mapping from the MAC
addresses to the software addresses; I'm no DECnet expert, but I'd
bet that has a lot to do with the implementation. If you know the
DECnet address of your intended communication partner (typically
from your hosts file since you don't have a DECnet name service in
most places) that is all you need with this approach. I remember
the scripting used on VMS systems to copy in the corporate wide copy
of the hosts file for DECnet back in the day..
Tom
Dr. Thomas P. Blinn + Tru64 UNIX Software + Hewlett-Packard Company
Internet: tpb@zk3.dec.com, thomas.blinn@compaq.com, thomas.blinn@hp.com
110 Spit Brook Road, MS ZKO3-2/W17 Nashua, New Hampshire 03062-2698
Alpha Tru64 UNIX kernel support Phone: (603) 884-0646
ACM Member: tpblinn@acm.org PC@Home: tom@felines.mv.com
Worry kills more people than work because more people worry than work.
Keep your stick on the ice. -- Steve Smith ("Red Green")
My favorite palindrome is: Satan, oscillate my metallic sonatas.
-- Phil Agre, pagre@alpha.oac.ucla.edu
Yesterday it worked / Today it is not working / UNIX is like that
-- apologies to Margaret Segall
Opinions expressed herein are my own, and do not necessarily represent
those of my employer or anyone else, living or dead, real or imagined.
4-Jul-2005 16:38:14-PDT,1779;000000000000
Return-Path: <smj@cirr.com>
Received: from sdf.lonestar.org (mx.freeshell.org [192.94.73.21]) by lingling.panda.com with TCP/SMTP; Mon, 4 Jul 2005 16:33:22 -0700 (PDT)
Received: from [10.0.0.2] (dsl254-015-081.sea1.dsl.speakeasy.net [216.254.15.81])
(authenticated (0 bits))
by sdf.lonestar.org (8.13.1/8.12.10) with ESMTP id j64NWgjv022860
for <tops-20@lingling.panda.com>; Mon, 4 Jul 2005 23:32:42 GMT
Mime-Version: 1.0 (Apple Message framework v622)
Content-Transfer-Encoding: 7bit
Message-Id: <54fe210dabd40c004686dfc2e3ac1305@cirr.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: tops-20@lingling.panda.com
From: Stephen Jones <smj@cirr.com>
Subject: EXEC SubDir access control facility bug
Date: Mon, 4 Jul 2005 16:33:11 -0700
X-Mailer: Apple Mail (2.622)
I suppose this is directed mostly at MRC, but maybe it wasn't a bug.
I seem to remember something broken in EXEC or in the access control
facility that prevented an account from created a FILES-ONLY or even
LOGIN
subdirectory under their own account. I even remember MRC maybe having
a fix for this available for FTP, but I might be wrong ..
Does this sound familiar?
Also, does anyone know how to ^ESPEAK to SYSJOB in lowercase? It
takes my command arguments and forces UPCASE.
Has anyone played with XKL's port of lynx? I first played around with
it on the public toad 10 years ago and have been curious about it
lately. The bin I have runs, but wants a hardcoded UNIX path to a
config file:
@lynx
Configuration file /usr/local/lib/lynx.cfg is not available.
I remember on the TD-1 they had a directory called <ROOT.USR.LOCAL.ETC>
where this file was located, and I played around with it, but had no
luck. Maybe the bin could be edited?
9-Jul-2005 23:00:10-PDT,1651;000000000000
Mail-From: MRC created at 9-Jul-2005 22:53:31
Date: Sat, 9 Jul 2005 22:53:31 -0700 (PDT)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: Re: EXEC SubDir access control facility bug
To: smj@cirr.com
cc: tops-20@lingling.panda.com, tops-20@lingling.panda.com
In-Reply-To: <54fe210dabd40c004686dfc2e3ac1305@cirr.com>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14040759141.16.MRC@lingling.panda.com>
> I seem to remember something broken in EXEC or in the access control
> facility that prevented an account from created a FILES-ONLY or even
> LOGIN
> subdirectory under their own account. I even remember MRC maybe having
> a fix for this available for FTP, but I might be wrong ..
If you are using the Panda ACJ, it prevents unprivileged users
from creating loginable subdirectories; unprivileged users must
create FILES-ONLY subdirectories. Feature, not a bug.
> Also, does anyone know how to ^ESPEAK to SYSJOB in lowercase? It
> takes my command arguments and forces UPCASE.
I'm not surprised (at least with SYSJOB, SYSJB1 may be more
forgiving) but the question is, why do you need lowercase with
any SYSJOB task? Most SYSJOB tasks don't need it. If you're
trying to talk to a PTY under SYSJOB, most people just ADVISE it.
> Has anyone played with XKL's port of lynx?
As far as I can tell, even if you fix the path issue LYNX will
not run on a vanilla TOPS-20 system. It complains about an I/o
error on the network. I suspect that it may use an XKL-only
monitor feature. I never considered it important enough to
investigate further.
-- Mark --
-------
13-Jul-2005 14:27:44-PDT,3587;000000000000
Return-Path: <beebe@math.utah.edu>
Received: from sunshine.math.utah.edu ([128.110.198.2]) by lingling.panda.com with TCP/SMTP; Wed, 13 Jul 2005 14:23:24 -0700 (PDT)
Received: from psi.math.utah.edu (IDENT:Ayw0TeXu54CKh7X8dm1Gy/9TEc4nv7/W@psi.math.utah.edu [155.101.96.19])
by sunshine.math.utah.edu (8.13.4/8.13.4) with ESMTP id j6DLNI6O021952;
Wed, 13 Jul 2005 15:23:18 -0600 (MDT)
Received: from psi.math.utah.edu (IDENT:lnjUCc/VEHqYSXEc5VPyvcAbc5TtILg0@localhost [127.0.0.1])
by psi.math.utah.edu (8.13.4/8.13.4) with ESMTP id j6DLNIed007537;
Wed, 13 Jul 2005 15:23:18 -0600 (MDT)
Received: (from beebe@localhost)
by psi.math.utah.edu (8.13.4/8.13.4/Submit) id j6DLNHpq007535;
Wed, 13 Jul 2005 15:23:18 -0600 (MDT)
Date: Wed, 13 Jul 2005 15:23:18 -0600 (MDT)
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
To: tops-20@lingling.panda.com
Cc: beebe@math.utah.edu
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: PDP-10 history, TeX, and Metafont
Message-ID: <CMM.0.92.0.1121289797.beebe@psi.math.utah.edu>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (sunshine.math.utah.edu [128.110.198.2]); Wed, 13 Jul 2005 15:23:18 -0600 (MDT)
I've just completed the final version of the conference proceedings
paper for my keynote address at the Practical TeX 2005 conference in
Chapel Hill, NC, June 14--17, 2005.
The paper is entitled
The design of TeX and METAFONT: A retrospective
and is available here in alternate formats:
http://www.math.utah.edu/~beebe/talks/pt2005/pt2005.pdf
http://www.math.utah.edu/~beebe/talks/pt2005/pt2005.ps
http://www.math.utah.edu/~beebe/talks/pt2005/pt2005.ps.gz
The final bundle of files for my article needs to go to the journal
editors by this Friday, but if anyone on this list is interested in
reading the article and commenting before then, I may be able to make
small tweaks before it goes to press.
There is a lot of PDP-10 history in the article, and some new
performance data in Figure 11 that list members may find interesting.
I've tried to make the document as typographically perfect as I can,
and the bibliography contains plenty of fodder for readers who wish to
delve further into this important piece of computer history. It is
written for a very broad audience, including people with little
computing experience, and none on the PDP-10, so there is a fair
amount of background provided to aid in understanding how the PDP-10
affected TeX and METAFONT.
I'm taking a PDP-10 in my pocket to Wuhan, China next month, where
I'll present a talk similar to my Chapel Hill one, but to an entirely
different audience.
The slides of the first talk are available here
http://www.math.utah.edu/~beebe/talks/pt2005/pt2005-slides.pdf
but will be somewhat revised for China.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
- 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
13-Jul-2005 15:29:22-PDT,7262;000000000000
Return-Path: <beebe@math.utah.edu>
Received: from sunshine.math.utah.edu ([128.110.198.2]) by lingling.panda.com with TCP/SMTP; Wed, 13 Jul 2005 15:25:21 -0700 (PDT)
Received: from psi.math.utah.edu (IDENT:mtty/Mv8rzn5sbO+tvCoF7v0bGA/iCpC@psi.math.utah.edu [155.101.96.19])
by sunshine.math.utah.edu (8.13.4/8.13.4) with ESMTP id j6DMPGsv024238;
Wed, 13 Jul 2005 16:25:16 -0600 (MDT)
Received: from psi.math.utah.edu (IDENT:LTcxK13LnDKJ+vewEVYMCHgyZM4kBkmk@localhost [127.0.0.1])
by psi.math.utah.edu (8.13.4/8.13.4) with ESMTP id j6DMPGLM008303;
Wed, 13 Jul 2005 16:25:16 -0600 (MDT)
Received: (from beebe@localhost)
by psi.math.utah.edu (8.13.4/8.13.4/Submit) id j6DMPGFS008301;
Wed, 13 Jul 2005 16:25:16 -0600 (MDT)
Date: Wed, 13 Jul 2005 16:25:16 -0600 (MDT)
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
To: tops-20@lingling.panda.com
Cc: beebe@math.utah.edu
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: PDP-10 history: seeking TeX sources in SAIL
Message-ID: <CMM.0.92.0.1121293515.beebe@psi.math.utah.edu>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (sunshine.math.utah.edu [128.110.198.2]); Wed, 13 Jul 2005 16:25:16 -0600 (MDT)
As part of my reconstruction of my PDP-10 working environment of the
early 1980s on the KLH10, I wanted to resurrect TeX and METAFONT in
their original incarnations in SAIL, before the 1979--1982 redesign
and rewrite in WEB/Pascal.
I have online on my desktop Unix workstation copies of all of the
contents of the RP06 and RP07 disks that we saved when our
DECsystem-20/60, UTAH-SCIENCE.ARPA (aka SCIENCE.UTAH.EDU) was retired
on 31-Oct-1990. The text files are all intact, but due to a
regrettable error when the files were moved to or from optical disks,
all of the files with 36-bit bytes got corrupted: thus, all .rel and
.exe files need to be rebuilt on KLH10.
On those disk images, I find METAFONT in SAIL in the directory
ps:<tex.mf> in these files:
alfhug.rel mff20.sai mfntrp.rel mfpre.rel mfsys.sai t.compare
files.inf mffil.sai mfntrp.sai mfpre.sai mlogo.mf
mf.exe mfhdr.sai mfout.rel mfrast.rel presso.sai
mfbase.sai mfini.tbl mfout.sai mfrast.sai sq.dvi
mfdovr.sai mflogo.mf mfoutb.sai mfsys.rel sq.mf
I am able to compile, some, but not all, of these files:
@compile mfbase.sai
SAIL: MFBASE.SAI.1 1
START YOUR PROGRAM WITH BEGIN OR ENTRY - WILL SCAN FOR BEGIN.
MFBASE.SAI.1, Page 1
01000 internaldef
innput=0 # "input";
^
...
@compile mfntrp.sai
SAIL: MFNTRP.SAI.1 1
MFHDR.SAI.1 1 2 3 4 5 6
2
MFBASE.SAI.1 1 2 3 4 5
3 4
MFF20.SAI.1 1
5 6 7 8 9 10
@compile mfout.sai
SAIL: MFOUT.SAI.1 1
MFHDR.SAI.1 1 2 3 4 5 6
2 3 4 5 6 7 8 9 10 11 12 13
....
The compilations produce these object files successfully:
MFNTRP.REL.1
MFOUT.REL.1
MFPRE.REL.1
MFRAST.REL.1
MFSYS.REL.1
The compilation failures seem to be a dependency on source order, but
the directory has no .cmd or .mic files to automate the build, or any
documentation of how to do so.
There OUGHT to be a ps:<tex.tex> directory (or something similar) with
TeX in SAIL, but I don't have it, and I thus don't even know the names
that the files had. I'm deeply chagrined and annoyed to have lost
this important part of history. The DECUS PDP-10 software archive at
http://pdp-10.trailing-edge.com/
does not have the METAFONT code, or as least the search-by-name box
does not find those files by name or by wildcard. I tried *.sai, and
found only 89 files dating from 15-Dec-1975 to 30-Oct-1984, and none
of them appear to be TeX-related. In my PDP-10 filesystem here, I
have 168 *.sai files.
Searches at http://www.google.com and http://www.archive.org/ found
nothing.
Does anyone on this list have any TeX/METAFONT material from the SAIL
days, and would be willing to make it available? I also need the *.mf
files and *.tex files that made these systems usable: I have these
*.mf files in aps:<tex.old-mf.am>, and the command and documentation
files have enough info to generate fonts once I can get a working
mf.exe file:
--fontlist.tex font2160.ctl iamsy8.tfm lasy8.tfm msym5.mf
--mf-xref.txt font2592.ctl iamtt8.mf lasy9.mf msym6.mf
--readme.txt font3110.ctl iamtt8.tfm lasy9.tfm msym7.mf
00dir.cmd font3732.ctl icmbase.mf lfonts.mic msym8.mf
00dir.lst font528.ctl iitalic.mf line.mf msym9.mf
00tdir.cmd font579.ctl ilasy.mf line10.mf olddig.mf
00tdir.lst font590.ctl ilasy8.mf line10.tfm punct.mf
accent.mf font694.ctl ilasy8.tfm linew10.mf roman.mf
calu.mf font833.ctl imathex.mf linew10.tfm romand.mf
circle.mf font912.ctl iroman.mf logo10.tfm romanl.mf
circle10.mf gray.tfm isroman.mf logo8.tfm romanp.mf
circle10.tfm greekl.mf isymbol.mf logosl10.tfm romans.mf
circlew10.mf greeku.mf itald.mf make-1500-family.mic romanu.mf
circlew10.tfm iaccent.mf italic.mf makeallsizes.mic romlig.mf
comlig.mf iamex10.mf italig.mf makefont.mic romms.mf
cscset.mf iamex10.tfm itall.mf manfnt.mf romsub.mf
dummy.tfm iammi8.mf italms.mf manfnt.tfm sfonts.ctl
euf10.tfm iammi8.tfm italp.mf manspe.mf sfonts.mic
euf7.tfm iamssq8.mf itals.mf manspec.mf spec.mf
eufb12.tfm iamssq8.tfm lasy.mf mathdl.mf sroman.mf
eufm12.tfm iamssqi8.mf lasy10.mf mathex.mf stip14.mf
eul10.tfm iamssqi8.tfm lasy10.tfm mathop.mf stippl.mf
eurb12.tfm iamsss8.mf lasy5.mf msxm10.mf sym.mf
eurm12.tfm iamsss8.tfm lasy5.tfm msxm5.mf symbol.mf
eusb12.tfm iamsssb8.mf lasy6.mf msxm6.mf texfonts.sub
eusm12.tfm iamsssb8.tfm lasy6.tfm msxm7.mf texset.mf
font1500.ctl iamsssi8.mf lasy7.mf msxm8.mf
font1643.ctl iamsssi8.tfm lasy7.tfm msxm9.mf
font1971.ctl iamsy8.mf lasy8.mf msym10.mf
I can successfully build and run the Pascal versions of these
programs, as illustrated in Figures in the article that I posted a
note about earlier today.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
- 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
13-Jul-2005 15:46:13-PDT,1230;000000000000
Return-Path: <phil@ultimate.com>
Received: from sccrmhc11.comcast.net ([204.127.202.55]) by lingling.panda.com with TCP/SMTP; Wed, 13 Jul 2005 15:41:58 -0700 (PDT)
Received: from c-66-30-204-193.hsd1.ma.comcast.net ([66.30.204.193])
by comcast.net (sccrmhc11) with ESMTP
id <2005071322415201100il1ake>; Wed, 13 Jul 2005 22:41:53 +0000
Received: (from phil@localhost)
by ultimate.com (8.13.4/8.13.4) id j6DMfpW9018473;
Wed, 13 Jul 2005 18:41:51 -0400 (EDT)
Date: Wed, 13 Jul 2005 18:41:51 -0400 (EDT)
From: Phil Budne <phil@ultimate.com>
Message-Id: <200507132241.j6DMfpW9018473@ultimate.com>
To: beebe@math.utah.edu, tops-20@lingling.panda.com
Subject: Re: PDP-10 history: seeking TeX sources in SAIL
> I am able to compile, some, but not all, of these files:
>
> @compile mfbase.sai
> SAIL: MFBASE.SAI.1 1
> START YOUR PROGRAM WITH BEGIN OR ENTRY - WILL SCAN FOR BEGIN.
> MFBASE.SAI.1, Page 1
> 01000 internaldef
> innput=0 # "input";
>
> ^
>
> ...
I suspect the 01000 is a "line squence number" or LSN, added by some
line editor (e.g. SOS). Compilers knew to ignore them because they
had the low order bit (the one you've lost) set.....
phil
13-Jul-2005 15:56:28-PDT,6960;000000000000
Return-Path: <beebe@math.utah.edu>
Received: from sunshine.math.utah.edu ([128.110.198.2]) by lingling.panda.com with TCP/SMTP; Wed, 13 Jul 2005 15:52:53 -0700 (PDT)
Received: from psi.math.utah.edu (IDENT:uGzQREC1kFxJnW8Hp0W2V0po8kxnZmgH@psi.math.utah.edu [155.101.96.19])
by sunshine.math.utah.edu (8.13.4/8.13.4) with ESMTP id j6DMqlAM025316;
Wed, 13 Jul 2005 16:52:47 -0600 (MDT)
Received: from psi.math.utah.edu (IDENT:Cm6ruIG/LvrweNQHA+erTOzu6N0piS+8@localhost [127.0.0.1])
by psi.math.utah.edu (8.13.4/8.13.4) with ESMTP id j6DMqlm1008431;
Wed, 13 Jul 2005 16:52:47 -0600 (MDT)
Received: (from beebe@localhost)
by psi.math.utah.edu (8.13.4/8.13.4/Submit) id j6DMqlK6008429;
Wed, 13 Jul 2005 16:52:47 -0600 (MDT)
Date: Wed, 13 Jul 2005 16:52:47 -0600 (MDT)
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
To: tops-20@lingling.panda.com
Cc: beebe@math.utah.edu
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: News of mm
Message-ID: <CMM.0.92.0.1121295167.beebe@psi.math.utah.edu>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (sunshine.math.utah.edu [128.110.198.2]); Wed, 13 Jul 2005 16:52:47 -0600 (MDT)
Back in 1986--1990, at Columbia University (CUCCA) Howie Kaye and
Andrew Lowry prepared ccmd, a C implementation of the TOPS-20 COMND%
JSYS. With this code available, Chris Maio, Fuat Baran, Howie Kaye
and Melissa Metz translated Mark Crispin's mm from PDP-10 assembly
code to C, and so Columbia-MM was born.
We have used this code at Utah since at least 1990 on our Sun SunOS
and Solaris systems, but it is not been buildable on most other
flavors of Unix (we have 20+ in our software development lab).
In October 1998, I spent time examining the ccmd and mm code to see
whether I could make it 8-bit clean. I wrote then:
>> ...
>> I make some experiments today in a several-hour-long session to see
>> whether mm could be made 8-bit clean, so that mail messages in the ISO
>> 8859-n character sets could be successfully sent and received.
>>
>> In summary, the answer is a RESOUNDING NO!
>>
>> Sadly, the assumptions about 7-bit characters run deep into both mm
>> and ccmd. In ccmd.h, I tried moving the CC_QUO flag bit above the 8th
>> bit, but this breaks most code dealing with CC_QUO in ccmd, where
>> character strings are passed around as char* data, and it is assumed
>> that such data can be tested for the CC_QUO bit.
>>
>> With ISO 8859-n becoming widespread, and Unicode increasingly common,
>> the lack of 8-bit (and eventually, 16-bit and 32-bit) character
>> support is going to make mm less and less desirable as a mail client.
>>
>> This could be remedied by converting ccmd from char* to wchar_t* data
>> (wchar_t is typedef'ed to a 32-bit integer type in modern C
>> implementations). However, the changes in ccmd, and then in mm, would
>> be rather extensive:
>>
>> In ccmd:
>> % cat *.[ch] | grep -c 'char *[*]'
>> 1040
>>
>> In mm:
>> % cat *.[ch] | grep -c 'char *[*]'
>> 1458
>>
>> Obviously, a simple sed script could be used to change the char* data
>> types to wchar_t universally, but then all of the strxxx() functions
>> would have to be changed too:
>>
>> In ccmd:
>> cat *.[ch] | egrep -c 'str[a-z0-9]+ *[(]'
>> 383
>>
>> In mm:
>> cat *.[ch] | egrep -c 'str[a-z0-9]+ *[(]'
>> 585
>>
>> and then all bitmasks would have to be carefully examined to see
>> whether further hidden assumptions of byte size were present, and all
>> I/O statements would have to be modified as well.
>>
>> This is probably too big a project to tackle, given the many other
>> defiencies of the ccmd library.
>>
>> This is further evidence of the desirability of a redesign in C++ (or
>> perhaps even Java!) to make the code independent of character-set
>> size, and much cleaner; there is altogether too much exposure of the
>> cmscb data structure in the code:
>>
>> In ccmd:
>> cat *.[ch] | egrep -c 'cmcsb[.]'
>> 762
>>
>> In mm:
>> cat *.[ch] | egrep -c 'cmcsb[.]'
>> 127
>> ...
It has bothered me ever since that ccmd and/or mm would not build on
most other flavors of Unix, and particularly, on GNU/Linux, which is
commonly present on personal and lab computers in our academic
computing environment.
When ccmd/mm failed to build on Sun Solaris 10, to which we are in the
process of migrating from Solaris 7, 8, and 9, it became urgent,
because for several of us, handling our large mail volume without mm
is utterly unthinkable. [Yes, we have pine, emacs rmail, and several
others, and Mark Crispin and I had a long telephone conversation a
couple of months ago about the merits of various mail clients.]
In May of this year, I therefore spent more time on those packages,
primarily to get them working on Solaris 10. I'm pleased to report
that I largely succeeded. My README.mm-0.94 file records this:
>> ...
>> The Makefiles contain new solaris10 targets.
>>
>> An additional extensive batch of updates on many other files produced
>> working versions of mm for the first time on GNU/Linux on these
>> architectures:
>>
>> Alpha
>> AMD64
>> IA-32
>> IA-64
>> MIPS
>> PowerPC
>> SPARC
>>
>> Also supported for the first time are:
>>
>> FreeBSD 5.0 IA-32
>> NetBSD 1.6 IA-32
>> OpenBSD 3.2 IA-32
>> DEC OSF/1 4.0 Alpha
>> Compaq OSF/1 5.2 Alpha
>> ...
The last updates of ccmd and mm at ftp://kermit.columbia.edu/pub/mm/
are these files:
-rw-r--r-- 1 staff 584592 Oct 9 2003 mm-ccmd-0.91-20031009.tar.gz
-rw-r--r-- 1 staff 585297 Oct 17 2003 mm-ccmd-0.91-20031017.tar.gz
I am prepared to make mm-0.94 available privately on request to anyone
on this list, and could easily set up Web and FTP sites for it.
However, I'd prefer to have the new distribution available from
Columbia (Frank da Cruz, are you reading this?) so that there is one
definitive permanent source of ccmd + mm.
Web searches show that the programmers at Columbia who were involved
in the ccmd + mm effort have mostly moved on to new jobs, but Frank
and I are still around, and hope to be for many years yet.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
- 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
13-Jul-2005 16:39:07-PDT,4915;000000000000
Return-Path: <phil@ultimate.com>
Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by lingling.panda.com with TCP/SMTP; Wed, 13 Jul 2005 16:34:35 -0700 (PDT)
Received: from c-66-30-204-193.hsd1.ma.comcast.net ([66.30.204.193])
by comcast.net (rwcrmhc12) with ESMTP
id <20050713231853014003644ne>; Wed, 13 Jul 2005 23:18:53 +0000
Received: (from phil@localhost)
by ultimate.com (8.13.4/8.13.4) id j6DNIqSL019010;
Wed, 13 Jul 2005 19:18:52 -0400 (EDT)
Date: Wed, 13 Jul 2005 19:18:52 -0400 (EDT)
From: Phil Budne <phil@ultimate.com>
Message-Id: <200507132318.j6DNIqSL019010@ultimate.com>
To: beebe@math.utah.edu, tops-20@lingling.panda.com
Subject: Re: PDP-10 history, TeX, and Metafont
> and is available here in alternate formats:
>
> http://www.math.utah.edu/~beebe/talks/pt2005/pt2005.pdf
> http://www.math.utah.edu/~beebe/talks/pt2005/pt2005.ps
> http://www.math.utah.edu/~beebe/talks/pt2005/pt2005.ps.gz
Some quick comments from reading the .pdf
Page 1002, section 3;
"Berkeley's Project Genie SDS 940"
Berkeley's Project Genie was a system which ran on the modified SDS
930 (which turned into the SDS 940). It inspired TENEX. Neither the
930 nor the 940 were PDP-10's.
"Compuserve 4S72"
Compuserve's system was derived from the PDP-6/10 Timesharing system
(which was later renamed TOPS-10). 4S72 refers to a version of the
PDP-6/10 Timesharing system. I doubt the Compuserve folks thought
they were running 4S72.
Page 1004, figure 1.
The idiom you show (PUSHJ to litteral) is unfamiliar, and inefficient.
I would have written JRST to litteral, then returning with "JRST .+2"
(. retained the value from the outside of the litteral) instead of AOS
(P) + POPJ. For the second block, use JRST, then JRST .+1 to return.
But I don't think I ever saw even this construct used, I think most
people would have written:
CAIL B, FOO
JRST [ stuff here
JRST blockend ]
other stuff here
blockend:
Tho the simple case was popular. Here is code from DIRECT.MAC
(the TOPS-10 DIR command):
TXNE T2,DV.TTA ;SEE IF CONTROLLING TTY [160]
TROA F,R.OUTO ;YES--SET FLAG [160]
JRST [SKIPGE T1 ;UNLESS USER SET /SUM, FORCE SUMMARIES [160]
MOVEI T1,1 ; OK--SET SUMMARIES [160]
JRST .+1] ;PROCEED [160]
Which shows the fun of skip chains.
Remember TRCE's in tripples (last TRCE never skips) for an idiom that
reverses two bits?
However, for every example is a counter-example. Also from DIRECT.MAC:
PUSHJ P,[N$WARN (IS1,/ACCESS ignored in conjunction with /FIND)
SETOM S.ACCS ;ZAPETH THE SWITCH
POPJ P,] ;NO MORE /ACCESS
SKIPLE S.ACCT ;OR /ACCOUNT?
PUSHJ P,[N$WARN (IF2,/ACCOUNT ignored in conjunction with /FIND)
SETOM S.ACCT ;ZAPETH THE SWITCH
POPJ P,] ;NO MORE /ACCOUNT
SKIPLE S.ALC ;OR /ALLOCATE?
PUSHJ P,[N$WARN (IF3,/ALLOCATE ignored in conjunction with /FIND)
SETOM S.ALC ;ZAPETH THE SWITCH
POPJ P,] ;NO MORE /ACCOUNT
SKIPLE S.AUT ;OR /AUTHOR?
PUSHJ P,[N$WARN (IF4,/AUTHOR ignored in conjunction with /FIND)
SETOM S.AUT ;ZAPETH THE SWITCH
POPJ P,] ;NO MORE /AUTHOR
But it seems foolish to do that extra pushing an popping. The copy of
DIRECT I'm looking at has 41 JRST's to literals, and only 7 PUSHJ's.
However, The IF/THEN/ELSE construct *WAS* easy/popular when using the
TOPS-20 MACSYM.MAC IFSKP./ELSE./ENDIF. macros (also IFNSKP. ANSKP.);
This example at
www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/8601.mm.www/0217.html
CALL TTSOBF ; Is output buffer full?
IFSKP.
CALL FRCPKT ; Yes, might as well send it now
ELSE.
CAIL T4,^D8 ; Looks like echoing?
IFSKP.
LOAD T1,QNEXT,<+TCBRXQ(TCB)> ; Yes, get RXQ
CAIE T1,TCBRXQ(TCB) ; Is the retransmission queue empty?
ANSKP.
CALL FRCPKT ; Yes, queue for PZ promptly
ELSE.
MOVX T1,^D200 ; Output not full and not echoing, wait a bit
CALL ENCPKT ; for more to output
ENDIF.
ENDIF.
>;IFN PANDASW
Page 1007, figure 2. Wouldn't DEK have seen back arrow instead of _?
Page 1009, figure 4. Ditto CTRL/P and CTRL/Q
Glad to see examples of WEB source code, and weave typeset output, and
tangled PASCAL code... I remember a DEK quote "I have come up with a
name for a new language... and I am now looking for a suitable
language to use it on" referred to WEB/TANGLE/WEAVE trio!
13-Jul-2005 17:02:52-PDT,5042;000000000000
Return-Path: <beebe@math.utah.edu>
Received: from sunshine.math.utah.edu ([128.110.198.2]) by lingling.panda.com with TCP/SMTP; Wed, 13 Jul 2005 16:59:14 -0700 (PDT)
Received: from psi.math.utah.edu (IDENT:nSfOvr9ZTx6ZRNkOZrungoSW0JE1UZVD@psi.math.utah.edu [155.101.96.19])
by sunshine.math.utah.edu (8.13.4/8.13.4) with ESMTP id j6DNx8oK027353;
Wed, 13 Jul 2005 17:59:08 -0600 (MDT)
Received: from psi.math.utah.edu (IDENT:PSMfb1hMW94KsFyQooOjmrceZPe6kJRY@localhost [127.0.0.1])
by psi.math.utah.edu (8.13.4/8.13.4) with ESMTP id j6DNx8wj008844;
Wed, 13 Jul 2005 17:59:08 -0600 (MDT)
Received: (from beebe@localhost)
by psi.math.utah.edu (8.13.4/8.13.4/Submit) id j6DNx8Yw008842;
Wed, 13 Jul 2005 17:59:08 -0600 (MDT)
Date: Wed, 13 Jul 2005 17:59:08 -0600 (MDT)
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
To: Phil Budne <phil@ultimate.com>
Cc: beebe@math.utah.edu, beebe@math.utah.edu, tops-20@lingling.panda.com
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: Re: PDP-10 history: seeking TeX sources in SAIL
In-Reply-To: Your message of Wed, 13 Jul 2005 18:41:51 -0400 (EDT)
Message-ID: <CMM.0.92.0.1121299147.beebe@psi.math.utah.edu>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (sunshine.math.utah.edu [128.110.198.2]); Wed, 13 Jul 2005 17:59:08 -0600 (MDT)
Phil Budne <phil@ultimate.com> comments on Wed, 13 Jul 2005 18:41:51-0400 (EDT)
about my report of compilation failures of some of the Metafont
sources in SAIL:
>> ...
>> > @compile mfbase.sai
>> > SAIL: MFBASE.SAI.1 1
>> > START YOUR PROGRAM WITH BEGIN OR ENTRY - WILL SCAN FOR BEGIN.
>> > MFBASE.SAI.1, Page 1
>> > 01000 internaldef
>> > innput=0 # "input";
>> > ^
>>
>> I suspect the 01000 is a "line squence number" or LSN, added by some
>> line editor (e.g. SOS).
>> ...
No, none of the SAIL sources have EDIT/SOS line numbers in them,
confirmed by Emacs both on Unix and on TOPS-20. The mf*.sai files
were only transferred from Unix to TOPS-20 this afternoon.
I think the issue is macro definitions, like this line from
mfhdr.sai:94
define internaldef = comment #
That file begins
comment The following declarations are used in all of METAFONT's modules.
Only brief explanatory comments appear here -- fuller documentation appears
in each individual module.
This page lists several standard abbreviation conventions.
The next four pages include declarations of everything external that is
internal to MFSYS, MFNTRP, MFRAST, MFOUT, respectively;
Combining files doesn't help:
@append mfhdr.sai, mfbase.sai foo3.sai
MFHDR.SAI.1 [OK]
MFBASE.SAI.1 [OK]
@compile foo3.sai
SAIL: FOO3.SAI.1 1
START YOUR PROGRAM WITH BEGIN OR ENTRY - WILL SCAN FOR BEGIN.
FOO3.SAI.1, Page 1
00900 require
"^P^Q^P^Q" delimiters; "used for macros"
^
The 5 digit line numbers are being generated by SAIL: the error in
foo3.sai is at line 9 when I view that file in emacs.
It is of course possible that the SAIL compiler on WAITS would have
compiled the code, but not the one on TOPS-20, but I'm pretty sure
that we could run the SAIL versions just fine on TOPS-20. However, I
don't know whether I ever built them from source code, or just
downloaded working mf.exe and tex.exe files over the ARPANET link at
UTAH-20.ARPA (aka today cs.utah.edu).
Here is the compiler version that I have:
@get sys:sail
@i ver
Panda Distribution, PANDA TOPS-20 Monitor 7.1(21733)-4
PANDA TOPS-20 Command processor 7.1(4453)-4
Program is SAIL, version is 23(21)-1
@vdir sys:sail.exe
TOPS20:<SAIL>
SAIL.EXE.2;P777752 99 50688(36) 6-May-82 10:26:13 MRC
Total of 99 pages in 1 file
The <SAIL> directory does not have compiler sources, and a recursive
listing of <*>*.*.* turns up only 29 *.sai files and 6 sai*.* files.
In the meantime, I'm going to experiment with writing some small tests
in SAIL myself. Fortunately, I have the Newman & Sproull book
``Principles of Interactive Computer Graphics'' (1973) here on my
shelf with an appendix containing a SAIL reference manual and a
tutorial on LEAP data structures (associative arrays).
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
- 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
13-Jul-2005 17:58:09-PDT,5549;000000000000
Return-Path: <wex@changing-leaves.com>
Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by lingling.panda.com with TCP/SMTP; Wed, 13 Jul 2005 17:53:34 -0700 (PDT)
Received: from [10.0.1.2] (c-24-91-108-249.hsd1.ma.comcast.net[24.91.108.249])
by comcast.net (rwcrmhc11) with ESMTP
id <20050714005329013002t2ive>; Thu, 14 Jul 2005 00:53:30 +0000
Mime-Version: 1.0
X-Sender: pwex@mail.comcast.net
Message-Id: <p06110405befb6763d07f@[10.0.1.2]>
In-Reply-To: <200507132318.j6DNIqSL019010@ultimate.com>
References: <200507132318.j6DNIqSL019010@ultimate.com>
Date: Wed, 13 Jul 2005 20:53:23 -0400
To: Phil Budne <phil@ultimate.com>, beebe@math.utah.edu,
tops-20@lingling.panda.com
From: P&G Wexelblat <wex@changing-leaves.com>
Subject: Re: PDP-10 history, TeX, and Metafont
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Prior to being "TOPS-10" the OS was just referred to as the monitor (no caps)
As I remember, BBN got their 940 because of repeated delays on their
desired Sigma 7
At 7:18 PM -0400 7/13/05, Phil Budne wrote:
> > and is available here in alternate formats:
>>
>> http://www.math.utah.edu/~beebe/talks/pt2005/pt2005.pdf
>> http://www.math.utah.edu/~beebe/talks/pt2005/pt2005.ps
>> http://www.math.utah.edu/~beebe/talks/pt2005/pt2005.ps.gz
>
>Some quick comments from reading the .pdf
>
>Page 1002, section 3;
>
>"Berkeley's Project Genie SDS 940"
>
>Berkeley's Project Genie was a system which ran on the modified SDS
>930 (which turned into the SDS 940). It inspired TENEX. Neither the
>930 nor the 940 were PDP-10's.
>
>"Compuserve 4S72"
>
>Compuserve's system was derived from the PDP-6/10 Timesharing system
>(which was later renamed TOPS-10). 4S72 refers to a version of the
>PDP-6/10 Timesharing system. I doubt the Compuserve folks thought
>they were running 4S72.
>
>Page 1004, figure 1.
>
>The idiom you show (PUSHJ to litteral) is unfamiliar, and inefficient.
>
>I would have written JRST to litteral, then returning with "JRST .+2"
>(. retained the value from the outside of the litteral) instead of AOS
>(P) + POPJ. For the second block, use JRST, then JRST .+1 to return.
>
>But I don't think I ever saw even this construct used, I think most
>people would have written:
>
> CAIL B, FOO
> JRST [ stuff here
> JRST blockend ]
> other stuff here
>blockend:
>
>Tho the simple case was popular. Here is code from DIRECT.MAC
>(the TOPS-10 DIR command):
>
> TXNE T2,DV.TTA ;SEE IF CONTROLLING TTY [160]
> TROA F,R.OUTO ;YES--SET FLAG [160]
> JRST [SKIPGE T1 ;UNLESS USER SET /SUM, FORCE SUMMARIES [160]
> MOVEI T1,1 ; OK--SET SUMMARIES [160]
> JRST .+1] ;PROCEED [160]
>
>Which shows the fun of skip chains.
>
>Remember TRCE's in tripples (last TRCE never skips) for an idiom that
>reverses two bits?
>
>However, for every example is a counter-example. Also from DIRECT.MAC:
>
> PUSHJ P,[N$WARN (IS1,/ACCESS ignored in conjunction with /FIND)
> SETOM S.ACCS ;ZAPETH THE SWITCH
> POPJ P,] ;NO MORE /ACCESS
> SKIPLE S.ACCT ;OR /ACCOUNT?
> PUSHJ P,[N$WARN (IF2,/ACCOUNT ignored in conjunction with /FIND)
> SETOM S.ACCT ;ZAPETH THE SWITCH
> POPJ P,] ;NO MORE /ACCOUNT
> SKIPLE S.ALC ;OR /ALLOCATE?
> PUSHJ P,[N$WARN (IF3,/ALLOCATE ignored in conjunction with /FIND)
> SETOM S.ALC ;ZAPETH THE SWITCH
> POPJ P,] ;NO MORE /ACCOUNT
> SKIPLE S.AUT ;OR /AUTHOR?
> PUSHJ P,[N$WARN (IF4,/AUTHOR ignored in conjunction with /FIND)
> SETOM S.AUT ;ZAPETH THE SWITCH
> POPJ P,] ;NO MORE /AUTHOR
>
>But it seems foolish to do that extra pushing an popping. The copy of
>DIRECT I'm looking at has 41 JRST's to literals, and only 7 PUSHJ's.
>
>However, The IF/THEN/ELSE construct *WAS* easy/popular when using the
>TOPS-20 MACSYM.MAC IFSKP./ELSE./ENDIF. macros (also IFNSKP. ANSKP.);
>
>This example at
>www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/8601.mm.www/0217.html
>
> CALL TTSOBF ; Is output buffer full?
> IFSKP.
> CALL FRCPKT ; Yes, might as well send it now
> ELSE.
> CAIL T4,^D8 ; Looks like echoing?
> IFSKP.
> LOAD T1,QNEXT,<+TCBRXQ(TCB)> ; Yes, get RXQ
> CAIE T1,TCBRXQ(TCB) ; Is the retransmission queue empty?
> ANSKP.
> CALL FRCPKT ; Yes, queue for PZ promptly
> ELSE.
> MOVX T1,^D200 ; Output not full and not echoing, wait a bit
> CALL ENCPKT ; for more to output
> ENDIF.
> ENDIF.
> >;IFN PANDASW
>
>Page 1007, figure 2. Wouldn't DEK have seen back arrow instead of _?
>
>Page 1009, figure 4. Ditto CTRL/P and CTRL/Q
>
>Glad to see examples of WEB source code, and weave typeset output, and
>tangled PASCAL code... I remember a DEK quote "I have come up with a
>name for a new language... and I am now looking for a suitable
>language to use it on" referred to WEB/TANGLE/WEAVE trio!
--
P.M. Wexelblat PhD
Dept. of Computer Science
University of Massachusetts Lowell
One University Ave
Lowell, MA 01854
13-Jul-2005 18:02:21-PDT,12395;000000000000
Return-Path: <wex@cs.uml.edu>
Received: from sccrmhc13.comcast.net ([204.127.202.64]) by lingling.panda.com with TCP/SMTP; Wed, 13 Jul 2005 17:55:04 -0700 (PDT)
Received: from [10.0.1.2] (c-24-91-108-249.hsd1.ma.comcast.net[24.91.108.249])
by comcast.net (sccrmhc13) with ESMTP
id <2005071400545701300aqeo5e>; Thu, 14 Jul 2005 00:54:59 +0000
Mime-Version: 1.0
X-Sender: (Unverified)
Message-Id: <p06110406befb68510860@[10.0.1.2]>
In-Reply-To: <CMM.0.92.0.1121299147.beebe@psi.math.utah.edu>
References: <CMM.0.92.0.1121299147.beebe@psi.math.utah.edu>
Date: Wed, 13 Jul 2005 20:54:55 -0400
To: "Nelson H. F. Beebe" <beebe@math.utah.edu>,
Phil Budne <phil@ultimate.com>
From: Paul Wexelblat <wex@cs.uml.edu>
Subject: Re: PDP-10 history: seeking TeX sources in SAIL
Cc: beebe@math.utah.edu, tops-20@lingling.panda.com
Content-Type: multipart/alternative; boundary="============_-1090819997==_ma============"
--============_-1090819997==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Prior to being "TOPS-10" the OS was just referred to as the monitor (no caps)
As I remember, BBN got their 940 because of repeated delays on their
desired Sigma 7
At 5:59 PM -0600 7/13/05, Nelson H. F. Beebe wrote:
>Phil Budne <phil@ultimate.com> comments on Wed, 13 Jul 2005
>18:41:51-0400 (EDT)
>about my report of compilation failures of some of the Metafont
>sources in SAIL:
>
>>> ...
>>> > @compile mfbase.sai
>>> > SAIL: MFBASE.SAI.1 1
>>> > START YOUR PROGRAM WITH BEGIN OR ENTRY - WILL SCAN FOR BEGIN.
>>> > MFBASE.SAI.1, Page 1
>>> > 01000 internaldef
>>> > innput=0 # "input";
>>> > ^
>>>
>>> I suspect the 01000 is a "line squence number" or LSN, added by some
>>> line editor (e.g. SOS).
>>> ...
>
>No, none of the SAIL sources have EDIT/SOS line numbers in them,
>confirmed by Emacs both on Unix and on TOPS-20. The mf*.sai files
>were only transferred from Unix to TOPS-20 this afternoon.
>
>I think the issue is macro definitions, like this line from
>mfhdr.sai:94
>
> define internaldef = comment #
>
>That file begins
>
> comment The following declarations are used in all of
>METAFONT's modules.
> Only brief explanatory comments appear here -- fuller
>documentation appears
> in each individual module.
>
> This page lists several standard abbreviation conventions.
> The next four pages include declarations of everything external that is
> internal to MFSYS, MFNTRP, MFRAST, MFOUT, respectively;
>
>Combining files doesn't help:
>
> @append mfhdr.sai, mfbase.sai foo3.sai
> MFHDR.SAI.1 [OK]
> MFBASE.SAI.1 [OK]
>
> @compile foo3.sai
> SAIL: FOO3.SAI.1 1
> START YOUR PROGRAM WITH BEGIN OR ENTRY - WILL SCAN FOR BEGIN.
> FOO3.SAI.1, Page 1
> 00900 require
> "^P^Q^P^Q" delimiters; "used for macros"
>
> ^
>
>The 5 digit line numbers are being generated by SAIL: the error in
>foo3.sai is at line 9 when I view that file in emacs.
>
>It is of course possible that the SAIL compiler on WAITS would have
>compiled the code, but not the one on TOPS-20, but I'm pretty sure
>that we could run the SAIL versions just fine on TOPS-20. However, I
>don't know whether I ever built them from source code, or just
>downloaded working mf.exe and tex.exe files over the ARPANET link at
>UTAH-20.ARPA (aka today cs.utah.edu).
>
>Here is the compiler version that I have:
>
> @get sys:sail
>
> @i ver
> Panda Distribution, PANDA TOPS-20 Monitor 7.1(21733)-4
> PANDA TOPS-20 Command processor 7.1(4453)-4
> Program is SAIL, version is 23(21)-1
>
> @vdir sys:sail.exe
>
> TOPS20:<SAIL>
> SAIL.EXE.2;P777752 99 50688(36) 6-May-82 10:26:13 MRC
>
> Total of 99 pages in 1 file
>
>The <SAIL> directory does not have compiler sources, and a recursive
>listing of <*>*.*.* turns up only 29 *.sai files and 6 sai*.* files.
>
>In the meantime, I'm going to experiment with writing some small tests
>in SAIL myself. Fortunately, I have the Newman & Sproull book
>``Principles of Interactive Computer Graphics'' (1973) here on my
>shelf with an appendix containing a SAIL reference manual and a
>tutorial on LEAP data structures (associative arrays).
>
>-------------------------------------------------------------------------------
>- Nelson H. F. Beebe Tel: +1 801 581 5254
>-
>- University of Utah FAX: +1 801 581 4148
>-
>- Department of Mathematics, 110 LCB Internet e-mail:
>beebe@math.utah.edu -
>- 155 S 1400 E RM 233 beebe@acm.org
>beebe@computer.org -
>- Salt Lake City, UT 84112-0090, USA URL:
>http://www.math.utah.edu/~beebe -
>-------------------------------------------------------------------------------
--
P.M. Wexelblat PhD
Dept. of Computer Science
University of Massachusetts Lowell
One University Ave
Lowell, MA 01854
--============_-1090819997==_ma============
Content-Type: text/html; charset="us-ascii"
<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: PDP-10 history: seeking TeX sources in
SAIL</title></head><body>
<div>Prior to being "TOPS-10" the OS was just referred to as
the monitor (no caps)</div>
<div><br></div>
<div>As I remember, BBN got their 940 because of repeated delays on
their desired Sigma 7</div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
<div>At 5:59 PM -0600 7/13/05, Nelson H. F. Beebe wrote:</div>
<blockquote type="cite" cite>Phil Budne <phil@ultimate.com>
comments on Wed, 13 Jul 2005 18:41:51-0400 (EDT)<br>
about my report of compilation failures of some of the Metafont<br>
sources in SAIL:<br>
<br>
>> ...<br>
>> > @compile
mfbase.sai<br>
>> > SAIL:
MFBASE.SAI.1 1<br>
>> > START YOUR PROGRAM
WITH BEGIN OR ENTRY - WILL SCAN FOR BEGIN.<br>
>> > MFBASE.SAI.1, Page
1<br>
>> >
01000 internaldef<br>
>>
> <span
></span
> <span
></span> innput=0 #
"input";<br>
>> > ^<br>
>><br>
>> I suspect the 01000 is a "line squence number" or
LSN, added by some<br>
>> line editor (e.g. SOS).<br>
>> ...<br>
<br>
No, none of the SAIL sources have EDIT/SOS line numbers in them,<br>
confirmed by Emacs both on Unix and on TOPS-20. The mf*.sai
files<br>
were only transferred from Unix to TOPS-20 this afternoon. <br>
<br>
I think the issue is macro definitions, like this line from<br>
mfhdr.sai:94<br>
<br>
<x-tab> </x-tab>define internaldef
= comment #<br>
<br>
That file begins<br>
<br>
<x-tab> </x-tab>comment The
following declarations are used in all of METAFONT's modules.<br>
<x-tab> </x-tab>Only brief
explanatory comments appear here -- fuller documentation appears<br>
<x-tab> </x-tab>in each individual module.<br>
<br>
<x-tab> </x-tab>This page lists several
standard abbreviation conventions.<br>
<x-tab> </x-tab>The next four pages
include declarations of everything external that is<br>
<x-tab> </x-tab>internal to MFSYS, MFNTRP, MFRAST, MFOUT,
respectively;<br>
<br>
Combining files doesn't help:<br>
<br>
<x-tab> </x-tab>@append mfhdr.sai, mfbase.sai
foo3.sai<br>
<x-tab> </x-tab> MFHDR.SAI.1 [OK]<br>
<x-tab> </x-tab> MFBASE.SAI.1
[OK]<br>
<br>
<x-tab> </x-tab>@compile foo3.sai<br>
<x-tab> </x-tab>SAIL:
FOO3.SAI.1 1<br>
<x-tab> </x-tab>START YOUR PROGRAM WITH BEGIN OR
ENTRY - WILL SCAN FOR BEGIN.<br>
<x-tab> </x-tab>FOO3.SAI.1, Page 1<br>
<x-tab>
</x-tab>00900 require<br>
<x-tab>
</x-tab><x-tab>
</x-tab><x-tab>
</x-tab> "^P^Q^P^Q" delimiters; "used for
macros"<br>
<br>
<x-tab> </x-tab>^<br>
<br>
The 5 digit line numbers are being generated by SAIL: the error in<br>
foo3.sai is at line 9 when I view that file in emacs.<br>
<br>
It is of course possible that the SAIL compiler on WAITS would
have<br>
compiled the code, but not the one on TOPS-20, but I'm pretty sure<br>
that we could run the SAIL versions just fine on TOPS-20.
However, I<br>
don't know whether I ever built them from source code, or just<br>
downloaded working mf.exe and tex.exe files over the ARPANET link
at<br>
UTAH-20.ARPA (aka today cs.utah.edu).<br>
<br>
Here is the compiler version that I have:<br>
<br>
<x-tab> </x-tab>@get sys:sail<br>
<br>
<x-tab> </x-tab>@i ver<br>
<x-tab> </x-tab> Panda Distribution, PANDA TOPS-20 Monitor
7.1(21733)-4<br>
<x-tab> </x-tab>PANDA TOPS-20 Command processor 7.1(4453)-4<br>
<x-tab> </x-tab> Program is SAIL, version is
23(21)-1<br>
<br>
<x-tab> </x-tab>@vdir sys:sail.exe<br>
<br>
<x-tab> </x-tab>
TOPS20:<SAIL><br>
<x-tab> </x-tab>
SAIL.EXE.2;P777752 99
50688(36) 6-May-82 10:26:13
MRC <br>
<br>
<x-tab> </x-tab> Total of 99 pages in 1 file<br>
<br>
The <SAIL> directory does not have compiler sources, and a
recursive<br>
listing of <*>*.*.* turns up only 29 *.sai files and 6 sai*.*
files.<br>
<br>
In the meantime, I'm going to experiment with writing some small
tests<br>
in SAIL myself. Fortunately, I have the Newman & Sproull
book<br>
``Principles of Interactive Computer Graphics'' (1973) here on my<br>
shelf with an appendix containing a SAIL reference manual and a<br>
tutorial on LEAP data structures (associative arrays).<br>
<br>
---------------------------------------------------------------------<span
></span>----------<br>
- Nelson H. F.
Beebe <span
></span> Tel: +1
801 581
5254 <span
></span> -<br>
- University of
Utah <span
></span> FAX: +1
801 581
4148 <span
></span> -<br>
- Department of Mathematics, 110 LCB Internet
e-mail: beebe@math.utah.edu -<br>
- 155 S 1400 E RM
233 <span
></span>
beebe@acm.org beebe@computer.org -<br>
- Salt Lake City, UT 84112-0090, USA URL:
http://www.math.utah.edu/~beebe -<br>
---------------------------------------------------------------------<span
></span>----------</blockquote>
<div><br></div>
<div><br></div>
<x-sigsep><pre>--
</pre></x-sigsep>
<div>P.M. Wexelblat PhD<br>
Dept. of Computer Science<br>
University of Massachusetts Lowell<br>
One University Ave<br>
Lowell, MA 01854</div>
</body>
</html>
--============_-1090819997==_ma============--
14-Jul-2005 00:07:02-PDT,1450;000000000000
Return-Path: <kz@kz.kz>
Received: from YALLA.kz.kz ([82.182.137.68]) by lingling.panda.com with TCP/SMTP; Thu, 14 Jul 2005 00:02:30 -0700 (PDT)
Received: from [127.0.0.1] (DHCP-100 [192.168.0.100])
by YALLA.kz.kz (8.9.2/) with ESMTP id IAA99626;
Thu, 14 Jul 2005 08:58:44 +0200 (CEST)
(envelope-from kz@kz.kz)
Message-ID: <42D60DFB.4040901@kz.kz>
Date: Thu, 14 Jul 2005 09:02:19 +0200
From: Klaus Zeuge <kz@kz.kz>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Nelson H. F. Beebe" <beebe@math.utah.edu>
CC: tops-20@lingling.panda.com
Subject: Re: PDP-10 history: seeking TeX sources in SAIL
References: <CMM.0.92.0.1121299147.beebe@psi.math.utah.edu>
In-Reply-To: <CMM.0.92.0.1121299147.beebe@psi.math.utah.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Nelson H. F. Beebe wrote:
> In the meantime, I'm going to experiment with writing some small tests
> in SAIL myself. Fortunately, I have the Newman & Sproull book
> ``Principles of Interactive Computer Graphics'' (1973) here on my
> shelf with an appendix containing a SAIL reference manual and a
> tutorial on LEAP data structures (associative arrays).
I only have the second edition of said book, from 1981. (The eleventh
printing from 1984). Unfortunatly, those appendixes seem to have been
dropped. Bad luck for me.
Klaus Zeuge
14-Jul-2005 07:15:32-PDT,4696;000000000000
Return-Path: <fdc@columbia.edu>
Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Thu, 14 Jul 2005 07:11:35 -0700 (PDT)
Received: from sesame.cc.columbia.edu (localhost [127.0.0.1])
by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j6EEBQ1J027949;
Thu, 14 Jul 2005 10:11:26 -0400 (EDT)
Received: (from fdc@localhost)
by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id j6EEBQBl027948;
Thu, 14 Jul 2005 10:11:26 -0400 (EDT)
Date: Thu, 14 Jul 2005 10:11:26 EDT
From: Frank da Cruz <fdc@columbia.edu>
To: "Nelson H. F. Beebe" <beebe@math.utah.edu>
Cc: tops-20@lingling.panda.com, beebe@math.utah.edu
Subject: Re: News of mm
In-Reply-To: <CMM.0.92.0.1121295167.beebe@psi.math.utah.edu>
Message-ID: <CMM.0.91.0.1121350286.fdc@sesame>
> Back in 1986--1990, at Columbia University (CUCCA) Howie Kaye and
> Andrew Lowry prepared ccmd, a C implementation of the TOPS-20 COMND%
> JSYS. With this code available, Chris Maio, Fuat Baran, Howie Kaye
> and Melissa Metz translated Mark Crispin's mm from PDP-10 assembly
> code to C, and so Columbia-MM was born.
>
> We have used this code at Utah since at least 1990 on our Sun SunOS
> and Solaris systems, but it is not been buildable on most other
> flavors of Unix (we have 20+ in our software development lab).
>
As you noted further down, I use it too, and until I received this note,
thought that I was the only one touching the code any more.
On a historical note, I was the manager of the group that wrote CMM but
I didn't work on the code then because I was too busy with Kermit :-)
Ironically, although Kermit has a COMD-like interface I never picked up
CCMD because (a) it wasn't ready in time and (b) by the time it was ready
it was too big and seemed like overkill. After that I kept working on
my stuff, adding variables and whatnot, until there was no going back.
CCMD definitely is more authentic though :-)
> In October 1998, I spent time examining the ccmd and mm code to see
> whether I could make it 8-bit clean. I wrote then:
>
I went through this too a couple years ago and gave up because, as you
found, the problem is deep, deep down. In those days, it wasn't a problem.
If I'm not mistaken, they used the 8th bit as some kind of flag, so
converting to data was going to break something else. I would have kept
pursuing it but I found a workaround, which I use many times every day,
that is described here:
ftp://kermit.columbia.edu/kermit/mm/release-0.91.txt
Basically, if you always use the editor (EMACS in my case), you can compose
8-bit messages all you want. Reading them was never a problem.
> It has bothered me ever since that ccmd and/or mm would not build on
> most other flavors of Unix, and particularly, on GNU/Linux, which is
> commonly present on personal and lab computers in our academic
> computing environment.
>
Over the last few years, I've been building it on Linux, OpenBSD, and
NetBSD. I tried some other builds (HP-UX, AIX, Tru64, etc) without success
but didn't have time to pursue them.
> When ccmd/mm failed to build on Sun Solaris 10, to which we are in the
> process of migrating from Solaris 7, 8, and 9, it became urgent,
> because for several of us, handling our large mail volume without mm
> is utterly unthinkable.
>
Me too. CMM is still my one and only mail client and I hope I won't ever
have to switch.
> [Yes, we have pine, emacs rmail, and several
> others, and Mark Crispin and I had a long telephone conversation a
> couple of months ago about the merits of various mail clients.]
>
Ditto.
> The last updates of ccmd and mm at ftp://kermit.columbia.edu/pub/mm/
> are these files:
>
> -rw-r--r-- 1 staff 584592 Oct 9 2003 mm-ccmd-0.91-20031009.tar.gz
> -rw-r--r-- 1 staff 585297 Oct 17 2003 mm-ccmd-0.91-20031017.tar.gz
>
> I am prepared to make mm-0.94 available privately on request to anyone
> on this list, and could easily set up Web and FTP sites for it.
> However, I'd prefer to have the new distribution available from
> Columbia (Frank da Cruz, are you reading this?) so that there is one
> definitive permanent source of ccmd + mm.
>
Yes indeed; I'll pick it up as soon as I have a chance. (I'm doing the
work of 7 people these days, it's hard to keep up.)
> Web searches show that the programmers at Columbia who were involved
> in the ccmd + mm effort have mostly moved on to new jobs, but Frank
> and I are still around, and hope to be for many years yet.
>
Hear hear! (Besides me, another one of the original team remains, but
doesn't have time to work on MM any more.)
- Frank
14-Jul-2005 08:40:27-PDT,5080;000000000000
Return-Path: <beebe@math.utah.edu>
Received: from sunshine2.math.utah.edu ([155.101.96.3]) by lingling.panda.com with TCP/SMTP; Thu, 14 Jul 2005 08:36:11 -0700 (PDT)
Received: from psi.math.utah.edu (IDENT:tNGhBSoCsDjA0knaOkYuDznutEULN80o@psi.math.utah.edu [155.101.96.19])
by sunshine2.math.utah.edu (8.13.4/8.13.4) with ESMTP id j6EFZxvv021043;
Thu, 14 Jul 2005 09:35:59 -0600 (MDT)
Received: from psi.math.utah.edu (IDENT:++y3ILKESlEdw+0Tw3Vladq0hGuwqD19@localhost [127.0.0.1])
by psi.math.utah.edu (8.13.4/8.13.4) with ESMTP id j6EFZxhP018149;
Thu, 14 Jul 2005 09:35:59 -0600 (MDT)
Received: (from beebe@localhost)
by psi.math.utah.edu (8.13.4/8.13.4/Submit) id j6EFZxr6018148;
Thu, 14 Jul 2005 09:35:59 -0600 (MDT)
Date: Thu, 14 Jul 2005 09:35:59 -0600 (MDT)
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
To: Klaus Zeuge <kz@kz.kz>, tops-20@lingling.panda.com
Cc: beebe@math.utah.edu
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: Re: PDP-10 history: seeking TeX sources in SAIL [+ remarks on Algol
60, SAIL, and Bliss]
In-Reply-To: Your message of Thu, 14 Jul 2005 09:02:19 +0200
Message-ID: <CMM.0.92.0.1121355359.beebe@psi.math.utah.edu>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (sunshine2.math.utah.edu [155.101.96.3]); Thu, 14 Jul 2005 09:35:59 -0600 (MDT)
Klaus Zeuge <kz@kz.kz> comments on my posting yesterday mentioning a
SAIL description in a book:
>> I only have the second edition of said book, from 1981. [Newman & Sproull]
>> ... Unfortunately, those appendixes seem to have been dropped. Bad luck for me.
Yes, the two editions are very different books. Page xv of the
preface of the second edition says
... program examples are now written in \textsc{Pascal}, a
somewhat better-known language than \textsc{Sail}, whose use
in the first edition necessitated the inclusion of a 20-page
user's manual!
Since my posting yesterday, I've successfully written some short
(approx. 20 lines) programs in Algol 60 and SAIL on TOPS-20 to compute
the machine epsilon, underflow and overflow behavior, and Fibonacci
sequences.
In Algol 60, underflow wraps to overflow and the program is terminated
with a message and a transfer to a debugger:
@execute ufl.alg
ALGOL: UFL
LINK: Loading
[LNKXCT UFL execution]
-1 5.0000000& -1
-2 2.5000000& -1
-3 1.2500000& -1
...
-127 5.8774718&-39
-128 2.9387359&-39
-129 1.4693679&-39
?Run-time error at address 000156
FLOATING POINT OVERFLOW
On line 7 in module UFL
in main program, level 0.1
>> ^C
Notice that the overflow detection happened AFTER the underflow
wrapped around, so the trap message is misleading until you understand
what happened.
The overflow test program also reported "FLOATING POINT OVERFLOW",
although based on previous experience, one might have expected an
underflow report instead
Interestingly, Algol 60 is one of the few languages that detected
integer overflow in the Fibonacci test: see
http://www.math.utah.edu/~beebe/software/java/fibonacci/
In SAIL, I discovered by experiment that double precision support in
the form of LONG REAL declarations was added to the language after the
Newman & Sproull book was published.
Unlike in Algol 60 on TOPS-20, in SAIL, floating-point underflow and
overflow silently wrap around without being caught (just as I reported
on this list in January for kcc-20). This behavior makes
floating-point arithmetic unsafe in both SAIL and C. I have not
abandoned my floating-point work in C on TOPS-20, but have been
working on a broad range of infrastructure issues that affect multiple
platforms in my software projects.
I attempted to do similar tests with Bliss, but even a simple "hello,
world" program is currently beyond me. I've skimmed about 1000 pages
of two DEC Bliss manuals, and found that the tutio package should
provide the needed I/O library support:
@type hello.bli
MODULE main=
BEGIN
REQUIRE 'TUTIO'; ! Missing on KLH10
TTY_PUT_QUO('Hello world from Bliss.');
END
ELUDOM
While our PANDA distribution has TOPS20:<DOCUMENTATION>TUTIO.HLP,
there are no other tutio.* files anywhere in the filesystem. A google
search to find tutio.bli was unsuccessful.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
- 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
16-Jul-2005 18:41:22-PDT,3319;000000000000
Return-Path: <beebe@math.utah.edu>
Received: from sunshine2.math.utah.edu ([155.101.96.3]) by lingling.panda.com with TCP/SMTP; Sat, 16 Jul 2005 18:37:15 -0700 (PDT)
Received: from psi.math.utah.edu (IDENT:gyfaYynHcMBQYMBGAsDqxM1UzAtbGDKd@psi.math.utah.edu [155.101.96.19])
by sunshine2.math.utah.edu (8.13.4/8.13.4) with ESMTP id j6H1b1ER010083;
Sat, 16 Jul 2005 19:37:01 -0600 (MDT)
Received: from psi.math.utah.edu (IDENT:VtobDWjElHzH6kRtTfqMd8SqpiIp9J8/@localhost [127.0.0.1])
by psi.math.utah.edu (8.13.4/8.13.4) with ESMTP id j6H1b0WU004341;
Sat, 16 Jul 2005 19:37:01 -0600 (MDT)
Received: (from beebe@localhost)
by psi.math.utah.edu (8.13.4/8.13.4/Submit) id j6H1b0LG004340;
Sat, 16 Jul 2005 19:37:00 -0600 (MDT)
Date: Sat, 16 Jul 2005 19:37:00 -0600 (MDT)
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
To: tops-20@lingling.panda.com
Cc: beebe@math.utah.edu
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: Re: PDP-10 history, TeX, and Metafont
Message-ID: <CMM.0.92.0.1121564220.beebe@psi.math.utah.edu>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (sunshine2.math.utah.edu [155.101.96.3]); Sat, 16 Jul 2005 19:37:01 -0600 (MDT)
Thanks to everyone who responded, both on-list and off-list, to my
posting of Wed, 13 Jul 2005 15:23:18 -0600 (MDT) about my keynote
address at the Practical TeX 2005 conference in Chapel Hill, NC, June
14--17, 2005.
I've made a few tweaks to correct errors and clarify the Ctl-P/Ctl-Q
delimiters, and shortened a couple of bibliography item notes to keep
the document on exactly 19 pages. The Wednesday version is already in
the google database.
The updated PDF file is at the same location as before:
http://www.math.utah.edu/~beebe/talks/pt2005/pt2005.pdf
I have not yet begun to edit the slides to repair errors and update
them for my talk next month in Wuhan, China, so the pt2005-slides.pdf
file has not yet been updated.
I elected not to change the PDP-10 assembly code example, because it
is reproduced verbatim from the cited source. Ralph Gorin kindly
supplied some comments which have not yet been addressed; I'll see
whether the editors will let me make another small update on Monday.
There is still uncertainty about "Online Services" vs. "On-Line
Systems"; I was told the former by an Irish friend who actually worked
on OLS-10 in London in the 1970s. However, I cannot confirm from
google searches which company OLS-10 belonged to. If anyone can shed
some light on this point, I would be grateful.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
- 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
17-Jul-2005 23:20:44-PDT,2793;000000000000
Mail-From: MRC created at 17-Jul-2005 23:16:52
Date: Sun, 17 Jul 2005 23:16:52 -0700 (PDT)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: new version of MAISER (TOPS-20 SMTP server)
To: TOPS-20@lingling.panda.com
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14042860541.16.MRC@lingling.panda.com>
I got fed up with receiving EBay phish spams on my TOPS-20 system
(curse the cretin who thought that it was "alright" to forward
TOPS-20 mail to netnews!) and so I decided it was time to make
MAISER's anti-spam features a bit stronger.
As of today, the following anti-spam features are in MAISER,
along with the following defaults set in the BUILD-MM.CTL file
(so the <MM.BINARIES>MAISER.EXE and SYSTEM:MAISER.EXE files no
longer are set differently).
$ASRES when set non-zero, MAISER will reject any SMTP client
whose IP address does not resolve with a PTR record to
a name. Defaults to 1 (set).
$ASRCP when set non-zero, MAISER will not verify a name in RCPT,
thus foiling dictionary attacks. This is usually a bad
idea because it will cause a bounce, possibly to some
other address, and thus can be used to spam. Defaults
to 0 (NOT set).
$ASVFY when set non-zero, disables the VRFY command. VRFY, once
a useful tool, is sometimes used by spammers doing
dictionary attacks to get a directory of valid email
addresses. Defaults to 1 (set).
$ASEXP when set non-zero, disables the EXPN command. EXPN, once
a useful tool, is frequently used by spammers especially
on mailing list names to collect valid email addresses.
Defaults to 1 (set).
$ASGRP when set non-zero, sets a delay in milliseconds before
the initial greeting banner is sent. Any client SMTP
commands sent before the banner is discards. This
stymies spam engines that blast a sequence of commands
without looking at the responses. Defaults to 5000. (5
seconds of delay).
$ASHLO when set non-zero, rejects SMTP clients which send a HELO
or EHLO name of mail.local, localhost, of
localhost.localdomain. This prevents poorly-configured
UNIX machines from connecting, as well as styming spam
engines that send such things to get around simple
relay filters. Defaults to 1 (set).
$ASCBI when set non-zero, clears the input buffer before sending
the terminating CRLF from an SMTP response line. This
stymies spam engines that blast commands without looking
at responses. Note that this precludes implementing the
ESMTP PIPELINING extension in the future. Defaults to 1
(set).
I've opened up Lingling's ANONYMOUS FTP server so you can FTP
these files from MM:BUILD-MM.CTL and MM:MAISER.MAC. Please don't
abuse my FTP server by doing wholesale wildcard transfers.
-- Mark --
-------
18-Jul-2005 08:19:50-PDT,4830;000000000000
Return-Path: <len00001@mc.duke.edu>
Received: from porthos.duhs.duke.edu ([152.16.199.201]) by lingling.panda.com with TCP/SMTP; Mon, 18 Jul 2005 08:15:17 -0700 (PDT)
Received: from notesgv.notes.duke.edu (notesgv.notes.duke.edu [152.16.18.54])
by porthos.duhs.duke.edu (8.12.11/8.12.11) with ESMTP id j6IFF8U21143330
(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
Mon, 18 Jul 2005 11:15:08 -0400
In-Reply-To: <CMM.0.92.0.1121564220.beebe@psi.math.utah.edu>
Subject: Re: PDP-10 history, TeX, and Metafont
To: tops-20@lingling.panda.com, "Nelson H. F. Beebe" <beebe@math.utah.edu>
X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003
Message-ID: <OF59EF2E5E.D21AB479-ON85257042.005068A8-85257042.0053F707@notes.duke.edu>
From: David M Len <len00001@mc.duke.edu>
Date: Mon, 18 Jul 2005 11:15:05 -0400
X-MIMETrack: Serialize by Router on notesgv.notes.duke.edu/DUMC_Services/mc/Duke(Release
6.5.4|March 27, 2005) at 07/18/2005 11:11:55 AM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.39
In the 1970's there was a Pittsburgh, PA based company named On-Line
Systems.
They were a time-sharing vendor using DECsystem-10s. Like CompuServe,
TymeShare and ADP the OS they used was significanty modified from some
version released from DEC.
I was a user of their service in 1977 while I was working for Mellon Bank.
I doubt if their modified OS was ever used anywhere other than On-Line
Systems.
David M. Len
I got my BS in Computer Science from the University of Pittsburgh in 1975,
while they were using DECsystem-10s.
I then spent 18 years working for Digital going from TOPS-10 to TOPS-20 to
VMS.
I still miss TOPS-20.
"Nelson H. F.
Beebe" To: tops-20@lingling.panda.com
<beebe@math.utah. cc: beebe@math.utah.edu
edu> Subject: Re: PDP-10 history, TeX, and Metafont
07/16/2005 09:37
PM
Thanks to everyone who responded, both on-list and off-list, to my
posting of Wed, 13 Jul 2005 15:23:18 -0600 (MDT) about my keynote
address at the Practical TeX 2005 conference in Chapel Hill, NC, June
14--17, 2005.
I've made a few tweaks to correct errors and clarify the Ctl-P/Ctl-Q
delimiters, and shortened a couple of bibliography item notes to keep
the document on exactly 19 pages. The Wednesday version is already in
the google database.
The updated PDF file is at the same location as before:
http://www.math.utah.edu/~beebe/talks/pt2005/pt2005.pdf
I have not yet begun to edit the slides to repair errors and update
them for my talk next month in Wuhan, China, so the pt2005-slides.pdf
file has not yet been updated.
I elected not to change the PDP-10 assembly code example, because it
is reproduced verbatim from the cited source. Ralph Gorin kindly
supplied some comments which have not yet been addressed; I'll see
whether the editors will let me make another small update on Monday.
There is still uncertainty about "Online Services" vs. "On-Line
Systems"; I was told the former by an Irish friend who actually worked
on OLS-10 in London in the 1970s. However, I cannot confirm from
google searches which company OLS-10 belonged to. If anyone can shed
some light on this point, I would be grateful.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254
-
- University of Utah FAX: +1 801 581 4148
-
- Department of Mathematics, 110 LCB Internet e-mail:
beebe@math.utah.edu -
- 155 S 1400 E RM 233 beebe@acm.org
beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA URL:
http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
1-Aug-2005 21:58:32-PDT,1688;000000000000
Return-Path: <billw@cisco.com>
Received: from sj-iport-3.cisco.com ([171.71.176.72]) by lingling.panda.com with TCP/SMTP; Mon, 1 Aug 2005 21:53:57 -0700 (PDT)
Received: from sj-core-5.cisco.com (171.71.177.238)
by sj-iport-3.cisco.com with ESMTP; 01 Aug 2005 21:53:51 -0700
X-IronPort-AV: i="3.95,160,1120460400";
d="scan'208"; a="328094918:sNHT26276552"
Received: from cisco.com (cypher.cisco.com [171.69.11.142])
by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j724rlJL007055;
Mon, 1 Aug 2005 21:53:47 -0700 (PDT)
Received: (from billw@localhost)
by cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA18718;
Mon, 1 Aug 2005 21:53:47 -0700 (PDT)
Sender: Bill Westfield <billw@cisco.com>
Date: Mon, 1 Aug 2005 21:53:47 PDT
From: William "Chops" Westfield <billw@cisco.com>
To: Phil Budne <phil@ultimate.com>
Cc: beebe@math.utah.edu, tops-20@lingling.panda.com
Subject: Re: PDP-10 history, TeX, and Metafont
In-Reply-To: Your message of Wed, 13 Jul 2005 19:18:52 -0400 (EDT)
Message-ID: <CMM.0.90.4.1122958427.billw@cypher>
>> The idiom you show (PUSHJ to litteral) is unfamiliar, and inefficient.
I seem to recall seeing it fairly often. Probably useful if your literal
uses the macros for local variables on the stack (as used in monitor and/or
exec sources, IIRC.) Perhaps the N$WARN macro in your counterexample does
so...
However, The IF/THEN/ELSE construct *WAS* easy/popular when using the
TOPS-20 MACSYM.MAC IFSKP./ELSE./ENDIF. macros (also IFNSKP. ANSKP.);
There were some other similar macros floating around. I had some
that implemented %IF/etc from some published source (can't remember
where, though.)
BillW
1-Aug-2005 22:05:24-PDT,2000;000000000000
Return-Path: <billw@cisco.com>
Received: from sj-iport-3.cisco.com ([171.71.176.72]) by lingling.panda.com with TCP/SMTP; Mon, 1 Aug 2005 22:01:11 -0700 (PDT)
Received: from sj-core-1.cisco.com (171.71.177.237)
by sj-iport-3.cisco.com with ESMTP; 01 Aug 2005 21:59:05 -0700
X-IronPort-AV: i="3.95,160,1120460400";
d="scan'208"; a="328095814:sNHT30386440"
Received: from cisco.com (cypher.cisco.com [171.69.11.142])
by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j724wxIs028548;
Mon, 1 Aug 2005 21:58:59 -0700 (PDT)
Received: (from billw@localhost)
by cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA19053;
Mon, 1 Aug 2005 21:59:00 -0700 (PDT)
Sender: Bill Westfield <billw@cisco.com>
Date: Mon, 1 Aug 2005 21:59:00 PDT
From: William "Chops" Westfield <billw@cisco.com>
To: Frank da Cruz <fdc@columbia.edu>
Cc: "Nelson H. F. Beebe" <beebe@math.utah.edu>, tops-20@lingling.panda.com,
beebe@math.utah.edu
Subject: Re: News of mm
In-Reply-To: Your message of Thu, 14 Jul 2005 10:11:26 EDT
Message-ID: <CMM.0.90.4.1122958740.billw@cypher>
[CCMD / MM]
> We have used this code at Utah since at least 1990 on our Sun SunOS
> and Solaris systems, but it is not been buildable on most other
> flavors of Unix (we have 20+ in our software development lab).
>
As you noted further down, I use it too, and until I received this note,
thought that I was the only one touching the code any more.
Hmm. I've been touching it too, although I thought I was pretty much alone
and haven't been very careful about revision control. Sigh. Now it'll bite
me. Let's see. There was the y2k fix attempts, the "mimetype" command, the
"howmany" that wasn't really needed... Sigh.
Did you do other cleanups? I keep looking at it (in light of 'modern'
styles of C programming) and getting very depressed about the prospects of
doing significant work, even though the list of desirable features keeps
getting longer...
BillW
1-Aug-2005 22:16:43-PDT,539;000000000000
Mail-From: MRC created at 1-Aug-2005 22:13:07
Date: Mon, 1 Aug 2005 22:13:07 -0700 (PDT)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: Re: News of mm
To: TOPS-20@lingling.panda.com
In-Reply-To: <CMM.0.90.4.1122958740.billw@cypher>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14046781098.10.MRC@lingling.panda.com>
Is anyone interested in an effort to port Pine to TOPS-20?
The c-client library already is ported to TOPS-20, but we need to get Pine
and Pico ported too...
-------
2-Aug-2005 06:41:38-PDT,4930;000000000000
Return-Path: <beebe@math.utah.edu>
Received: from sunshine2.math.utah.edu ([155.101.96.3]) by lingling.panda.com with TCP/SMTP; Tue, 2 Aug 2005 06:37:49 -0700 (PDT)
Received: from psi.math.utah.edu (IDENT:VqfqOwGvTH+RJPFTFZnZlegJntH+Sy31@psi.math.utah.edu [155.101.96.19])
by sunshine2.math.utah.edu (8.13.4/8.13.4) with ESMTP id j72DbMgl001379;
Tue, 2 Aug 2005 07:37:22 -0600 (MDT)
Received: from psi.math.utah.edu (IDENT:c2kqazKBbNJjJVxt7AxDRkSWhBrNop7+@localhost [127.0.0.1])
by psi.math.utah.edu (8.13.4/8.13.4) with ESMTP id j72DbMKE004710;
Tue, 2 Aug 2005 07:37:22 -0600 (MDT)
Received: (from beebe@localhost)
by psi.math.utah.edu (8.13.4/8.13.4/Submit) id j72DbL9D004708;
Tue, 2 Aug 2005 07:37:22 -0600 (MDT)
Date: Tue, 2 Aug 2005 07:37:22 -0600 (MDT)
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
To: William "Chops" Westfield <billw@cisco.com>
Cc: beebe@math.utah.edu, Frank da Cruz <fdc@columbia.edu>,
"Nelson H. F. Beebe" <beebe@math.utah.edu>, tops-20@lingling.panda.com,
beebe@math.utah.edu
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: Re: News of mm
In-Reply-To: Your message of Mon, 1 Aug 2005 21:59:00 PDT
Message-ID: <CMM.0.94.0.1122989841.beebe@psi.math.utah.edu>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (sunshine2.math.utah.edu [155.101.96.3]); Tue, 02 Aug 2005 07:37:22 -0600 (MDT)
William "Chops" Westfield <billw@cisco.com> asks on Mon, 1 Aug 2005
21:59:00 PDT about my changes to the C version of mm:
>> I've been touching it too ... Did you do other cleanups?
>> I keep looking at it (in light of 'modern' styles of C programming) and
>> getting very depressed about the prospects of doing significant work, ...
Our work at Utah on mm has not added any new commands, but instead has
been directed at enhancing portability, and trying to make it 8-bit
clean. We also disabled the mail file locking, since it doesn't work
reliably in an NFS environment: we simply warn our mm users that they
must avoid running multiple instances of mm, just as they already know
they must also avoid running multiple Web browsers.
All changes in both the ccmd and mm directories are under RCS control,
and the mm-0.94/mm/CHANGELOG file summarizes the changes.
We have succeeded in improving portability, since mm-0.94 now builds
on all of our 20+ flavors of Unix, but we failed in the 8-bit cleanup.
I found that there are pervasive assumptions in the ccmd
command-parser library that the high-order bit of each 8-bit character
can be used as a flag, and concluded long ago that the only solution
was a complete redesign and rewrite of the parsing package, possibly
in C++ or Java, with elimination of the TOPS-20 data structures in
favor of a much cleaner interface. Inasmuch as there are 21,187 lines
of code in ccmd, and 36,088 lines of code in mm, any such project is
destined to take many months in the hands of skilled programmer, and
since we are all getting old and gray, that is hard to justify. There
are lots of other programming projects that I want to work on.
As long as you keep the parser's hands off your text, you can use
8-bit characters in mm. The header lines, like Subject:, gets parsed,
so they are stuck with 7-bit characters unless you edit them.
What I generally do is have a permanently-running emacs session with
the mail-server library preloaded, and then when I ask mm to get me to
an editor, it hands what I've typed so far off to emacs. I can then
edit the entire message, using 8-bit characters as needed, even
putting those characters into mail headers. For example, here is a
snippet of a Danish rhyme in ISO 8859-1 encoding:
Subject: Danske bxrnerim og engelsk oversfttelse
Xen i sxen har kun in barber, The island in the lake has only one barber,
men tilgengfld se klipper han but then he clips
alt hvad han ser. everything he sees.
When I end the emacs message editing with C-x ! (server-edit), control
returns to mm, which is then happy to send my 8-bit characters, as
long as I don't try to edit them further by, for example, typing in a
new subject line.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
- 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
2-Aug-2005 08:16:08-PDT,6780;000000000000
Return-Path: <fdc@columbia.edu>
Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Tue, 2 Aug 2005 08:12:17 -0700 (PDT)
Received: from sesame.cc.columbia.edu (localhost [127.0.0.1])
by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j72FCAtl012877;
Tue, 2 Aug 2005 11:12:10 -0400 (EDT)
Received: (from fdc@localhost)
by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id j72FC5b7012858;
Tue, 2 Aug 2005 11:12:05 -0400 (EDT)
Date: Tue, 2 Aug 2005 11:12:05 EDT
From: Frank da Cruz <fdc@columbia.edu>
To: "Nelson H. F. Beebe" <beebe@math.utah.edu>
Cc: tops-20@lingling.panda.com
Subject: Re: News of mm
In-Reply-To: <CMM.0.94.0.1122989841.beebe@psi.math.utah.edu>
Message-ID: <CMM.0.91.0.1122995525.fdc@sesame>
Nelson Wrote...
> William "Chops" Westfield <billw@cisco.com> asks on Mon, 1 Aug 2005
> 21:59:00 PDT about my changes to the C version of mm:
>
> >> I've been touching it too ... Did you do other cleanups?
> >> I keep looking at it (in light of 'modern' styles of C programming) and
> >> getting very depressed about the prospects of doing significant work, ...
>
> Our work at Utah on mm has not added any new commands, but instead has
> been directed at enhancing portability, and trying to make it 8-bit
> clean. We also disabled the mail file locking, since it doesn't work
> reliably in an NFS environment: we simply warn our mm users that they
> must avoid running multiple instances of mm, just as they already know
> they must also avoid running multiple Web browsers.
>
This is the major reason MM fell out of favor at Columbia, where we have a
big (Solaris) host pool. With tens of thousands of users, it's just too
easy for somebody to get disconnected and leave behind an mm zombie, and
then not be able to get back to the same host to kill it, even if they knew
how to do that, so our help desk was always swamped with "my mailbox is
locked" calls. Now the only people who use mm any more are the ones who
know how to take care of themselves. It never occurred to me to just remove
the locking, but maybe at this point it's safe.
> All changes in both the ccmd and mm directories are under RCS control,
> and the mm-0.94/mm/CHANGELOG file summarizes the changes.
>
> We have succeeded in improving portability, since mm-0.94 now builds
> on all of our 20+ flavors of Unix...
>
That's a big and badly needed step.
> ... but we failed in the 8-bit cleanup.
> I found that there are pervasive assumptions in the ccmd
> command-parser library that the high-order bit of each 8-bit character
> can be used as a flag, and concluded long ago that the only solution
> was a complete redesign and rewrite of the parsing package, possibly
> in C++ or Java, with elimination of the TOPS-20 data structures in
> favor of a much cleaner interface. Inasmuch as there are 21,187 lines
> of code in ccmd, and 36,088 lines of code in mm, any such project is
> destined to take many months in the hands of skilled programmer, and
> since we are all getting old and gray, that is hard to justify. There
> are lots of other programming projects that I want to work on.
>
Right, this will probably never happen. Anyway I like leaving CCMD as a
kind of memorial to how it was. The DEC-20 was pretty much hardwired 7-bit
ASCII, despite its variable-length bytes (although I did hear rumors at the
time of installations in Japan that bought them for exactly that reason, and
used larger bytesizes for some combination of Roman, Kana, and Kanji -- I
visited the NTT lab in 1987 and didn't see any evidence of this, but maybe
Mark knows more).
Given the number of Scandinavians at Marlboro you'd think there would have
been some interest in at least Latin-1, but with them I think it was a
matter of pride to speak better English than Americans -- facilitating the
use of other languages would have been sign of weakness :-)
> As long as you keep the parser's hands off your text, you can use
> 8-bit characters in mm. The header lines, like Subject:, gets parsed,
> so they are stuck with 7-bit characters unless you edit them.
>
> What I generally do is have a permanently-running emacs session with
> the mail-server library preloaded, and then when I ask mm to get me to
> an editor, it hands what I've typed so far off to emacs. I can then
> edit the entire message, using 8-bit characters as needed, even
> putting those characters into mail headers. For example, here is a
> snippet of a Danish rhyme in ISO 8859-1 encoding:
>
> Subject: Danske bxrnerim og engelsk oversfttelse
>
> Xen i sxen har kun in barber, The island in the lake has only one barber,
> men tilgengfld se klipper han but then he clips
> alt hvad han ser. everything he sees.
>
> When I end the emacs message editing with C-x ! (server-edit), control
> returns to mm, which is then happy to send my 8-bit characters, as
> long as I don't try to edit them further by, for example, typing in a
> new subject line.
>
I just "set use-editor-always true". I send tons Latin-1 mail every day,
sometimes also UTF-8. Now that we have relatively fast computers, the
penalty of starting EMACS on each messages is hardly noticeable.
BillW said:
> There was the y2k fix attempts, the "mimetype" command, the
> "howmany" that wasn't really needed... Sigh.
>
I should hope the current Columbia version (and therefore Nelson's) obviates
the need for any y2k fixes. It also has a MIME-VERSION command. One thing
I'm not happy about is the CONTENT-TYPE command that I added. I assumed the
only thing I would ever use MM for was plain text, so this command only
fills in the character-set part of the Content-Type header, keeping
"text/plain" hardwired. Now it seems I need to send HTML from time to time,
so this command should be changed to do what you'd expect -- specify the
content type! I also have a few other items on my list.
I guess the ball is in my court. I haven't had a chance to look at Nelson's
stuff yet. The main thing that worries me is the 8-bit changes. Since you
say they didn't work, I assume that you backed them out?
> -----------------------------------------------------------------------------
> - Nelson H. F. Beebe Tel: +1 801 581 5254 -
> - University of Utah FAX: +1 801 581 4148 -
> - Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
> - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
> - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
> -----------------------------------------------------------------------------
- Frank
2-Aug-2005 08:38:33-PDT,2334;000000000000
Return-Path: <beebe@math.utah.edu>
Received: from sunshine2.math.utah.edu ([155.101.96.3]) by lingling.panda.com with TCP/SMTP; Tue, 2 Aug 2005 08:34:58 -0700 (PDT)
Received: from psi.math.utah.edu (IDENT:Md8MPe2TFhnzFSM5vV2wheXTik9963Vy@psi.math.utah.edu [155.101.96.19])
by sunshine2.math.utah.edu (8.13.4/8.13.4) with ESMTP id j72FYlSA005156;
Tue, 2 Aug 2005 09:34:47 -0600 (MDT)
Received: from psi.math.utah.edu (IDENT:BgZGZHCBkW3jm8ORK8L78Bp7UIZD9ycf@localhost [127.0.0.1])
by psi.math.utah.edu (8.13.4/8.13.4) with ESMTP id j72FYkAo006395;
Tue, 2 Aug 2005 09:34:46 -0600 (MDT)
Received: (from beebe@localhost)
by psi.math.utah.edu (8.13.4/8.13.4/Submit) id j72FYkdL006394;
Tue, 2 Aug 2005 09:34:46 -0600 (MDT)
Date: Tue, 2 Aug 2005 09:34:46 -0600 (MDT)
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
To: Frank da Cruz <fdc@columbia.edu>, tops-20@lingling.panda.com
Cc: beebe@math.utah.edu
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: Re: News of mm
In-Reply-To: Your message of Tue, 2 Aug 2005 11:12:05 EDT
Message-ID: <CMM.0.94.0.1122996886.beebe@psi.math.utah.edu>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (sunshine2.math.utah.edu [155.101.96.3]); Tue, 02 Aug 2005 09:34:47 -0600 (MDT)
Frank da Cruz asks:
>> The main thing that worries me is the 8-bit changes. Since you
>> say they didn't work, I assume that you backed them out?
They were all in a separate development branch that I versioned mm-0.93,
and then abandoned. The mm-0.94 version is derived from the mm-0.92 one.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
- 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
2-Aug-2005 11:28:50-PDT,2106;000000000000
Mail-From: MRC created at 2-Aug-2005 11:25:02
Date: Tue, 2 Aug 2005 11:25:02 -0700 (PDT)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: Re: News of mm
To: fdc@columbia.edu
cc: beebe@math.utah.edu, tops-20@lingling.panda.com
In-Reply-To: <CMM.0.91.0.1122995525.fdc@sesame>
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14046925261.16.MRC@lingling.panda.com>
> This is the major reason MM fell out of favor at Columbia, where we have a
> big (Solaris) host pool. With tens of thousands of users, it's just too
> easy for somebody to get disconnected and leave behind an mm zombie, and
> then not be able to get back to the same host to kill it, even if they knew
> how to do that, so our help desk was always swamped with "my mailbox is
> locked" calls.
This was something that I addressed in the course of
c-client/IMAP development. There is, by the way, a baby version
of UNIX MM that is built upon c-client (and thus is IMAP capable)
and ccmd called...of course...MS. I used it quite extensively
until I switched to Pine (which is also based upon c-client but
not ccmd).
> The DEC-20 was pretty much hardwired 7-bit
> ASCII, despite its variable-length bytes (although I did hear rumors at the
> time of installations in Japan that bought them for exactly that reason, and
> used larger bytesizes for some combination of Roman, Kana, and Kanji -- I
> visited the NTT lab in 1987 and didn't see any evidence of this, but maybe
> Mark knows more).
The PDP-10 systems in Japan all used ISO 2022 encoded JIS, which
is the standard way of sending Japanese email today.
By the way,...
I assume that everybody has read my UTF-9 and UTF-18 document
(RFC 4042) for how to do Unicode on PDP-10s. I am quite serious
about this, and am thinking about how to handle 9-bit text files
seamlessly e.g., making 7-bit open mode truncate bits from a
9-bit file rather than bit-shifting, so that legacy 7-bit
applications can handle ASCII content 9-bit files.
So, after 35 years, IO.MAC may finally realize its promise.
-------
2-Aug-2005 12:22:11-PDT,2393;000000000000
Return-Path: <billw@cisco.com>
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by lingling.panda.com with TCP/SMTP; Tue, 2 Aug 2005 12:17:45 -0700 (PDT)
Received: from sj-core-3.cisco.com (171.68.223.137)
by sj-iport-4.cisco.com with ESMTP; 02 Aug 2005 12:17:38 -0700
Received: from cisco.com (cypher.cisco.com [171.69.11.142])
by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j72JHaqK021109;
Tue, 2 Aug 2005 12:17:36 -0700 (PDT)
Received: (from billw@localhost)
by cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA26533;
Tue, 2 Aug 2005 12:17:36 -0700 (PDT)
Sender: Bill Westfield <billw@cisco.com>
Date: Tue, 2 Aug 2005 12:17:35 PDT
From: William "Chops" Westfield <billw@cisco.com>
To: Frank da Cruz <fdc@columbia.edu>
Cc: "Nelson H. F. Beebe" <beebe@math.utah.edu>, tops-20@lingling.panda.com
Subject: Re: News of mm
In-Reply-To: Your message of Tue, 2 Aug 2005 11:12:05 EDT 2 Aug 2005 09:34:46
-0600 (MDT)
Message-ID: <CMM.0.90.4.1123010255.billw@cypher>
> ... but we failed in the 8-bit cleanup.
> I found that there are pervasive assumptions in the ccmd
> command-parser library that the high-order bit of each 8-bit character
> can be used as a flag, and concluded long ago that the only solution
> was a complete redesign and rewrite of the parsing package...
Couldn't you add 8-bit CMTXT style parsing without needing to make
ccmd completely "8bit clean"? I wouldn't think that mm needs 8 bit
keywords and tokens and so on. (This is more or less what I did at
cisco for international character support; a couple spots just pass on
the 8th bit when they didn't in the past, but the parser itself isn't
'8bit' by any means. Never did get a good feel for how well that
worked in the field...)
> There was the y2k fix attempts, the "mimetype" command...
>
I should hope the current Columbia version obviates the need for any
y2k fixes. It also has a MIME-VERSION command.
Probably. I think I got to a point where I couldn't (or believed I
couldn't) download new columbia code and still have it compile in our
solaris environment. I'm still running 0.90.4... "mimetype" is a
display command; simply a version of the "type" command with a
different output filter, so that you can pipe a message though mh's
(?) metamail. Cheap, easy, and pretty useful...
BillW
2-Aug-2005 13:12:29-PDT,3410;000000000000
Return-Path: <beebe@math.utah.edu>
Received: from sunshine2.math.utah.edu ([155.101.96.3]) by lingling.panda.com with TCP/SMTP; Tue, 2 Aug 2005 13:08:47 -0700 (PDT)
Received: from psi.math.utah.edu (IDENT:IeWExoBTYLmnLCYe5s+PjcrmvkyfPFdR@psi.math.utah.edu [155.101.96.19])
by sunshine2.math.utah.edu (8.13.4/8.13.4) with ESMTP id j72K7UX8014852;
Tue, 2 Aug 2005 14:07:30 -0600 (MDT)
Received: from psi.math.utah.edu (IDENT:1YX/VcE1wM2hHZ+Ucd90y1J3oqoz9MES@localhost [127.0.0.1])
by psi.math.utah.edu (8.13.4/8.13.4) with ESMTP id j72K7Tbc007492;
Tue, 2 Aug 2005 14:07:29 -0600 (MDT)
Received: (from beebe@localhost)
by psi.math.utah.edu (8.13.4/8.13.4/Submit) id j72K7TM5007491;
Tue, 2 Aug 2005 14:07:29 -0600 (MDT)
Date: Tue, 2 Aug 2005 14:07:29 -0600 (MDT)
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
To: William "Chops" Westfield <billw@cisco.com>
Cc: beebe@math.utah.edu, Frank da Cruz <fdc@columbia.edu>,
"Nelson H. F. Beebe" <beebe@math.utah.edu>, tops-20@lingling.panda.com
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: Re: News of mm
In-Reply-To: Your message of Tue, 2 Aug 2005 12:17:35 PDT
Message-ID: <CMM.0.94.0.1123013249.beebe@psi.math.utah.edu>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (sunshine2.math.utah.edu [155.101.96.3]); Tue, 02 Aug 2005 14:07:30 -0600 (MDT)
William "Chops" Westfield <billw@cisco.com> writes on Tue, 2 Aug 2005
12:17:35 PDT about the 8-bit limitation of the ccmd parsing package:
>> Couldn't you add 8-bit CMTXT style parsing without needing to make
>> ccmd completely "8bit clean"?
That is definitely an idea worth investigating: we could certainly
live without 8-bit characters in mm prompts and commands, since they
are in English to begin with, and are not easily internationalized
(although that should be a fundamental design point in any new
software).
More critical, however, is the issue of attachments. Bill goes on to write:
>> ...
>> "mimetype" is a display command; simply a version of the "type"
>> command with a different output filter, so that you can pipe a message
>> though mh's (?) metamail. Cheap, easy, and pretty useful...
>> ...
Another good idea. Bill, do think you might have the time to run
diffs of your mimetype additions against the mm-0.90 base and email
them to me offlist? If they are not extensive and conflicting with
what I've done, I'll be happy to take a stab at merging them into the
mm-0.94 code. I leave for China in two weeks, so nothing is likely to
happen to mm at my end before late September, at the earliest, so
there is no great rush.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
- 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
2-Aug-2005 13:37:01-PDT,2416;000000000000
Return-Path: <rossman@columbia.edu>
Received: from serrano.cc.columbia.edu ([128.59.29.6]) by lingling.panda.com with TCP/SMTP; Tue, 2 Aug 2005 13:33:23 -0700 (PDT)
Received: from [192.168.0.103] (pool-138-89-140-119.mad.east.verizon.net [138.89.140.119])
(user=rossman mech=PLAIN bits=0)
by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j72KXFEi019351
(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT)
for <tops-20@lingling.panda.com>; Tue, 2 Aug 2005 16:33:16 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v733)
In-Reply-To: <CMM.0.94.0.1123013249.beebe@psi.math.utah.edu>
References: <CMM.0.94.0.1123013249.beebe@psi.math.utah.edu>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <2B717863-45EB-4FE5-B815-26D3C7F95C08@columbia.edu>
Content-Transfer-Encoding: 7bit
From: Ken Rossman <rossman@columbia.edu>
Subject: Re: News of mm
Date: Tue, 2 Aug 2005 16:33:13 -0400
To: tops-20@lingling.panda.com
X-Mailer: Apple Mail (2.733)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6
I think some work on ccmd and mm is well merited. I'd love to get my
hands
on at least some of the modules and do some work, time permitting.
I would advocate the following strategy for proceeding, for those who
are
interested (and forgive me if some of this is naive - I have not
looked at
a lot of this code in some time, much of it at all):
1) Lets come up with a specific list of modifications that ought to
be made
to the code, and prioritize the list.
2) Analyze the existing code to determine just how modular and "object
oriented" it already is (not specifically strictly object oriented,
of course, but lets determine how "insular" each individual routine
is from everything else. Likewise, lets flag the global data
structures
and see what can be done to modularize those in some way. The
idea here
is how easily can each module be worked on independently from
the rest
of the code?...
3) Assuming a reasonable level of insular modularity, lets divvy up
the
routines amongst interested parties, and go to work on it. But
we'd
need to all agree on what the next general, global mod to ccmd & mm
should be and move in that direction.
Just tossing in my two-cents...
:-)
Ken Rossman
rossman@columbia.edu
3-Aug-2005 17:59:51-PDT,4037;000000000000
Return-Path: <billw@cisco.com>
Received: from sj-iport-1.cisco.com ([171.71.176.70]) by lingling.panda.com with TCP/SMTP; Wed, 3 Aug 2005 17:55:06 -0700 (PDT)
Received: from sj-core-5.cisco.com (171.71.177.238)
by sj-iport-1.cisco.com with ESMTP; 03 Aug 2005 17:55:00 -0700
X-IronPort-AV: i="3.95,165,1120460400";
d="scan'208"; a="652840151:sNHT27499944"
Received: from cisco.com (cypher.cisco.com [171.69.11.142])
by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j740svoo005834;
Wed, 3 Aug 2005 17:54:58 -0700 (PDT)
Received: (from billw@localhost)
by cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA26063;
Wed, 3 Aug 2005 17:54:57 -0700 (PDT)
Sender: Bill Westfield <billw@cisco.com>
Date: Wed, 3 Aug 2005 17:54:57 PDT
From: William "Chops" Westfield <billw@cisco.com>
To: Ken Rossman <rossman@columbia.edu>
Cc: tops-20@lingling.panda.com
Subject: Re: News of mm
In-Reply-To: Your message of Tue, 2 Aug 2005 16:33:13 -0400
Message-ID: <CMM.0.90.4.1123116897.billw@cypher>
>> I think some work on ccmd and mm is well merited.
>>
>> 1) Lets come up with a specific list of modifications that ought to
>> be made to the code, and prioritize the list.
>>
>> 2) Analyze the existing code to determine just how modular and "object
>> oriented" it already is (not specifically strictly object oriented,
Alas, the code is pretty sucky by modern C standards. For instance, there
are no function prototypes. Merely compiling with a modern compiler
requires things like --traditional, and there are still lots of warnings
generated :-( Whenever I contemplate touching it (ie for something like a
linux port), I keep running up agains the idea is that "first, I oughta
modernize it and get rid of the existing compiler-found bugs.") Which
would be a moderate sized project in itself :-(
Things I've done anyway:
Mime output via existing external mime filters. Sorta.
Add "fix-dates" commands to make the internal dates match the Date: fields
in the message. One of the y2k-related (?) bugs caused the internal date
to "drift" a day at a time, causing "before" and similar search keywords to
fail miserably. (a hack, in case you had any doubts!)
Fix (maybe, sorta) incorrect parsing of lines beginning with "From " that
caused mm to think this meant the beginning of a new message. (perhaps only
in some formats of mail files?)
Do automatic "take newmail.rc" whenever mm detects new incoming mail (for
spam removal.) It would be REALLY nice if the newmail.rc file only had to
operate on the new messages, rather than the whole file. I didn't look at
doing that...
Be less anal about adding reply-to: fields if the From: field contains a
reasonable-looking address. (it was NOT helpful that mm kept adding
"Reply-to: billw@internal-mail-host.cisco.com" when my From field already
had "billw@cisco.com")
Add "unto" search keyword ("head unseen unto billw"; very useful!)
increase string sizes.
Things I want:
Wildcards of at least a primitive kind for "dont-type-headers"
flush useless headers (on request, and/or automatically) in the mail
file. By the time a message has been kept after reading for a month or
so, I surely no longer need a couple Kbytes of "received" lines, right?
Read ("examine") compressed mail files.
Better spam filtering capabilities.
Color output, especially in some form of "Headers" ?
multi-file search. It is MM's search capabilities, more than any other
feature, that keeps me using it. I can type a complex search like
read to billw before 1-jun-2005 sub "CSCd" text "tty_printf"
and get results faster than I can wade through the first level of "easy
to use" search menus on a modern GUI mail reader. But I want more.
Check optimization for typical modern-sized emails and mail files.
A one-year archive for me seems to run about 200Mbytes these days,
with "many" messages exceeding 50kbytes
BillW
4-Aug-2005 01:28:40-PDT,1478;000000000000
Return-Path: <sra@hactrn.net>
Received: from cyteen.hactrn.net ([66.92.66.68]) by lingling.panda.com with TCP/SMTP; Thu, 4 Aug 2005 01:24:10 -0700 (PDT)
Received: from thangorodrim.hactrn.net (open-24-185.ietf63.ietf.org [86.255.24.185])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client CN "thangorodrim.hactrn.net", Issuer "Grunchweather Associates" (verified OK))
by cyteen.hactrn.net (Postfix) with ESMTP id C0D6E72
for <tops-20@lingling.panda.com>; Thu, 4 Aug 2005 04:24:02 -0400 (EDT)
Received: from thangorodrim.hactrn.net (localhost [127.0.0.1])
by thangorodrim.hactrn.net (Postfix) with ESMTP id AC61939
for <tops-20@lingling.panda.com>; Thu, 4 Aug 2005 08:23:56 +0000 (UTC)
Date: Thu, 04 Aug 2005 10:23:55 +0200
From: Rob Austein <sra@hactrn.net>
To: tops-20@lingling.panda.com
Subject: Re: News of mm
In-Reply-To: <CMM.0.90.4.1123116897.billw@cypher>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20050804082356.AC61939@thangorodrim.hactrn.net>
At Wed, 3 Aug 2005 17:54:57 PDT, William Chops Westfield wrote:
>
> Alas, the code is pretty sucky by modern C standards. For instance, there
> are no function prototypes.
gcc's "protoize" command, while quirky and imperfect, does still do
about 80% of the job of fixing this sort of problem. Might be worth a
try.
4-Aug-2005 04:29:37-PDT,2984;000000000000
Return-Path: <beebe@math.utah.edu>
Received: from sunshine2.math.utah.edu ([155.101.96.3]) by lingling.panda.com with TCP/SMTP; Thu, 4 Aug 2005 04:25:42 -0700 (PDT)
Received: from psi.math.utah.edu (IDENT:/MVrHjqMHwQce2dC7dWyHXdu4Z8kqluh@psi.math.utah.edu [155.101.96.19])
by sunshine2.math.utah.edu (8.13.4/8.13.4) with ESMTP id j74BPTcU017098;
Thu, 4 Aug 2005 05:25:29 -0600 (MDT)
Received: from psi.math.utah.edu (IDENT:AIf39PLnc267MpyWxmGvR/qtvTK6nS5q@localhost [127.0.0.1])
by psi.math.utah.edu (8.13.4/8.13.4) with ESMTP id j74BPTQf003491;
Thu, 4 Aug 2005 05:25:29 -0600 (MDT)
Received: (from beebe@localhost)
by psi.math.utah.edu (8.13.4/8.13.4/Submit) id j74BPSVw003490;
Thu, 4 Aug 2005 05:25:28 -0600 (MDT)
Date: Thu, 4 Aug 2005 05:25:28 -0600 (MDT)
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
To: William "Chops" Westfield <billw@cisco.com>
Cc: beebe@math.utah.edu, Ken Rossman <rossman@columbia.edu>,
tops-20@lingling.panda.com
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: Re: News of mm
In-Reply-To: Your message of Wed, 3 Aug 2005 17:54:57 PDT
Message-ID: <CMM.0.94.0.1123154728.beebe@psi.math.utah.edu>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (sunshine2.math.utah.edu [155.101.96.3]); Thu, 04 Aug 2005 05:25:29 -0600 (MDT)
William "Chops" Westfield <billw@cisco.com> writes on Wed, 3 Aug 2005
17:54:57 PDT about mm:
>> ... the code is pretty sucky by modern C standards. For instance, there
>> are no function prototypes.
That is fixed in the mm-0.94 distribution. I'm a fanatic about having
function prototypes: in my experience, adding them to older programs
has invariably turned up several bugs of incorrect argument types or
numbers of arguments. That is why I routinely build by own C code
with C++ compilers, because they are even more picky about argument
matching and type coercions.
Almost all of mm-0.94/ccmd can be successfully compiled with C++. On
the mm-0.94/mm side, there is a type conflict in a header file used by
most of the code that makes C++ choke. I could probably fix the
remaining C++ problems in an hour or two, and will likely do so when I
merge Bill's changes in.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
- 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
4-Aug-2005 14:53:13-PDT,1303;000000000000
Return-Path: <billw@cisco.com>
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by lingling.panda.com with TCP/SMTP; Thu, 4 Aug 2005 14:48:33 -0700 (PDT)
Received: from sj-core-3.cisco.com (171.68.223.137)
by sj-iport-4.cisco.com with ESMTP; 04 Aug 2005 14:48:18 -0700
Received: from cisco.com (cypher.cisco.com [171.69.11.142])
by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j74LmFZ1029583;
Thu, 4 Aug 2005 14:48:16 -0700 (PDT)
Received: (from billw@localhost)
by cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA08005;
Thu, 4 Aug 2005 14:48:15 -0700 (PDT)
Sender: Bill Westfield <billw@cisco.com>
Date: Thu, 4 Aug 2005 14:48:15 PDT
From: William "Chops" Westfield <billw@cisco.com>
To: "Nelson H. F. Beebe" <beebe@math.utah.edu>
Cc: beebe@math.utah.edu, Ken Rossman <rossman@columbia.edu>,
tops-20@lingling.panda.com
Subject: Re: News of mm
In-Reply-To: Your message of Thu, 4 Aug 2005 05:25:28 -0600 (MDT)
Message-ID: <CMM.0.90.4.1123192095.billw@cypher>
Did anyone fix the bug where text being composed in emacs dissappears on the
way back to MM, if the tmp file size is between 800 and 1200 bytes or so?
Unfortunately, the version I'm using now has a bunch of tmp files made
permanent in efforts to track and work around that problem...
BillW
4-Aug-2005 15:53:10-PDT,3694;000000000000
Return-Path: <beebe@math.utah.edu>
Received: from sunshine2.math.utah.edu ([155.101.96.3]) by lingling.panda.com with TCP/SMTP; Thu, 4 Aug 2005 15:49:23 -0700 (PDT)
Received: from psi.math.utah.edu (IDENT:X24Rk7yW3KaY2Z9S//Y5+DtCQ++Hd6VB@psi.math.utah.edu [155.101.96.19])
by sunshine2.math.utah.edu (8.13.4/8.13.4) with ESMTP id j74MnGFW005848;
Thu, 4 Aug 2005 16:49:16 -0600 (MDT)
Received: from psi.math.utah.edu (IDENT:k9FuJnnkytS4ta8Kuu9TT4Wbpfhqqczu@localhost [127.0.0.1])
by psi.math.utah.edu (8.13.4/8.13.4) with ESMTP id j74MnGJ5008188;
Thu, 4 Aug 2005 16:49:16 -0600 (MDT)
Received: (from beebe@localhost)
by psi.math.utah.edu (8.13.4/8.13.4/Submit) id j74MnFat008187;
Thu, 4 Aug 2005 16:49:15 -0600 (MDT)
Date: Thu, 4 Aug 2005 16:49:15 -0600 (MDT)
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
To: William "Chops" Westfield <billw@cisco.com>, tops-20@lingling.panda.com
Cc: beebe@math.utah.edu
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: Re: News of mm
In-Reply-To: Your message of Thu, 4 Aug 2005 14:48:15 PDT
Message-ID: <CMM.0.94.0.1123195755.beebe@psi.math.utah.edu>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (sunshine2.math.utah.edu [155.101.96.3]); Thu, 04 Aug 2005 16:49:16 -0600 (MDT)
William "Chops" Westfield <billw@cisco.com> asks on Thu, 4 Aug 2005 14:48:15 PDT:
>> ...
>> Did anyone fix the bug where text being composed in emacs dissappears on the
>> way back to MM, if the tmp file size is between 800 and 1200 bytes or so?
>> Unfortunately, the version I'm using now has a bunch of tmp files made
>> permanent in efforts to track and work around that problem...
>> ...
We used to see that a fair amount, and for that reason, I disabled the
deletion of the temporary files to allow recovery:
% ls -l ~/.mm*
-rw------- 1 beebe wheel 1241 Aug 1 18:52 /u/sy/beebe/.mm-outgoing.22323.~1~
-rw------- 1 beebe wheel 501 Jul 27 15:34 /u/sy/beebe/.mm-outgoing.22323.~2~
...
I clean them up manually now and then.
However, I've been running on Solaris 9 for many months now, sending
100--300 messages a day in mm-0.94, and have not had a single message
lost between mm and emacs (21.3.1). Pieter also uses mm heavily, but
is away on vacation just now, so I cannot ask him whether he has seen
any message loss in recent months.
Pieter and I spent quite some time trying to track down the loss, and
decided that it looked much like a race condition in a signal handler.
An rcsdiff of exit.c against the original 1.1 version shows that there
are a fair number of macroized debug print statements that I inserted
to try to track down the problem, but no substantive code changes.
Thus, it is possible that Solaris 9, or the rebuild of mm under that
system, fixed the problem. We have just three systems left running
Solaris 8, most of the rest are at Solaris 9, and a few are at
Solaris 10.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
- 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
4-Aug-2005 17:07:07-PDT,3963;000000000000
Return-Path: <beebe@math.utah.edu>
Received: from sunshine2.math.utah.edu ([155.101.96.3]) by lingling.panda.com with TCP/SMTP; Thu, 4 Aug 2005 17:03:06 -0700 (PDT)
Received: from psi.math.utah.edu (IDENT:ekiokozpPLeG9KWrvwz5mSz3h/IGQmJs@psi.math.utah.edu [155.101.96.19])
by sunshine2.math.utah.edu (8.13.4/8.13.4) with ESMTP id j7502wYY007504;
Thu, 4 Aug 2005 18:02:58 -0600 (MDT)
Received: from psi.math.utah.edu (IDENT:5/29X4tpc91cmwSDugvI879kWS2+IHYi@localhost [127.0.0.1])
by psi.math.utah.edu (8.13.4/8.13.4) with ESMTP id j7502wQ6008739;
Thu, 4 Aug 2005 18:02:58 -0600 (MDT)
Received: (from beebe@localhost)
by psi.math.utah.edu (8.13.4/8.13.4/Submit) id j7502vW7008737;
Thu, 4 Aug 2005 18:02:57 -0600 (MDT)
Date: Thu, 4 Aug 2005 18:02:57 -0600 (MDT)
From: "Nelson H. F. Beebe" <beebe@math.utah.edu>
To: tops-20@lingling.panda.com
Cc: beebe@math.utah.edu
X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S
1400 E RM 233, Salt Lake City, UT 84112-0090, USA"
X-Telephone: +1 801 581 5254
X-FAX: +1 801 585 1640, +1 801 581 4148
X-URL: http://www.math.utah.edu/~beebe
Subject: Revisiting old languages: BCPL
Message-ID: <CMM.0.94.0.1123200177.beebe@psi.math.utah.edu>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (sunshine2.math.utah.edu [155.101.96.3]); Thu, 04 Aug 2005 18:02:58 -0600 (MDT)
I have a Web page at
http://www.math.utah.edu/~beebe/software/java/
that leads to hello-world programs in about 60 languages, and to the
next step up in complexity, generation and printing of the Fibonacci
sequence, in 41 languages.
A question came in this afternoon in private email to me about the
status of BCPL on the PDP-10, since it was a language that my
correspondent thought was available on that system, but I had not
discussed it in my article at
http://www.math.utah.edu/~beebe/talks/pt2005/pt2005.pdf
I thought it might be interesting to add a BCPL program for the
Fibonacci problem.
I hunted around, and found a language reference manual that Dennis
Ritchie put up at
http://cm.bell-labs.com/cm/cs/who/dmr/bcpl.pdf
and since BCPL is among the hello-world samples, I attempted to
compile and run it on TOPS-20:
@type hello.bcp
// From http://www.cuillin.demon.co.uk/nazz/trivia/hw/hw_bcpl.html
// BCPL 'Hello World' program
GET "LIBHDR"
LET START () BE
$(
WRITES ("Hello World!*N")
$)
@bcpl
BCPL 3.3.3 1/6/78
Inline JSYS
=> ?
[<rel name>[,<listing name>]_]<source name>[(<switches>)]<cr>
(Type HELP<cr> for more help)
=> help
GTJFN error - No such directory name
<bcpl>BCPL.HELP
Can't help=>
^Z
@bcpl
BCPL 3.3.3 1/6/78
Inline JSYS
=> hello.rel_hello.bcp
Help called ...
BCPL: can't find file bcpl.dictionary.
I tracked down the missing file and copied it into the current
directory:
@copy sys:bcpl.dictionary dsk:
<UNSUPPORTED>BCPL.DICTIONARY.1 => BCPL.DICTIONARY.1 [OK]
@bcpl
BCPL 3.3.3 1/6/78
Inline JSYS
=> hello.rel_hello.bcp
[BCPL: hello.bcp]
GTJFN error -
?Illegal memory WRITE at 13203
@ddt
DDT
13203/ MOVEM 5,0(2)
13204/ MOVEI JSETUP+14(16)
13205/ PUSH GL1003+172
13206/ PUSH GL105
13207/ JSP 1,@GL8030 ^C
Has anyone on this list ever used BCPL on the PDP-10? Does the above
compilation attempt work on your system?
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
- 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
4-Aug-2005 17:38:46-PDT,1440;000000000000
Return-Path: <billw@cisco.com>
Received: from sj-iport-2.cisco.com ([171.71.176.71]) by lingling.panda.com with TCP/SMTP; Thu, 4 Aug 2005 17:34:26 -0700 (PDT)
Received: from sj-core-5.cisco.com (171.71.177.238)
by sj-iport-2.cisco.com with ESMTP; 04 Aug 2005 17:34:19 -0700
Received: from cisco.com (cypher.cisco.com [171.69.11.142])
by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j750YDoo009064;
Thu, 4 Aug 2005 17:34:13 -0700 (PDT)
Received: (from billw@localhost)
by cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA09523;
Thu, 4 Aug 2005 17:34:13 -0700 (PDT)
Sender: Bill Westfield <billw@cisco.com>
Date: Thu, 4 Aug 2005 17:34:13 PDT
From: William "Chops" Westfield <billw@cisco.com>
To: "Nelson H. F. Beebe" <beebe@math.utah.edu>
Cc: tops-20@lingling.panda.com, beebe@math.utah.edu
Subject: Re: Revisiting old languages: BCPL
In-Reply-To: Your message of Thu, 4 Aug 2005 18:02:57 -0600 (MDT)
Message-ID: <CMM.0.90.4.1123202053.billw@cypher>
A question came in this afternoon in private email to me about the
status of BCPL on the PDP-10, since it was a language that my
correspondent thought was available on that system, but I had not
discussed it in my article
BBN's "Hermes" was my preferred mail reader when there were actual
dec20s around, and it was supposed to have been written in BCPL...
(anybody got hermes sources? I still miss some of its features.)
BillW
7-Aug-2005 07:19:13-PDT,1737;000000000000
Return-Path: <fdc@columbia.edu>
Received: from sesame.cc.columbia.edu ([128.59.59.56]) by lingling.panda.com with TCP/SMTP; Sun, 7 Aug 2005 07:14:20 -0700 (PDT)
Received: from sesame.cc.columbia.edu (localhost [127.0.0.1])
by sesame.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j77EDxQr015480;
Sun, 7 Aug 2005 10:13:59 -0400 (EDT)
Received: (from fdc@localhost)
by sesame.cc.columbia.edu (8.13.0/8.12.8/Submit) id j77EDwB6015479;
Sun, 7 Aug 2005 10:13:58 -0400 (EDT)
Date: Sun, 7 Aug 2005 10:13:58 EDT
From: Frank da Cruz <fdc@columbia.edu>
To: William "Chops" Westfield <billw@cisco.com>
Cc: "Nelson H. F. Beebe" <beebe@math.utah.edu>, beebe@math.utah.edu,
Ken Rossman <rossman@columbia.edu>, tops-20@lingling.panda.com
Subject: Re: News of mm
In-Reply-To: <CMM.0.90.4.1123192095.billw@cypher>
Message-ID: <CMM.0.91.0.1123424038.fdc@sesame>
> Did anyone fix the bug where text being composed in emacs dissappears on the
> way back to MM, if the tmp file size is between 800 and 1200 bytes or so?
> Unfortunately, the version I'm using now has a bunch of tmp files made
> permanent in efforts to track and work around that problem...
>
I meant to answer this earlier. This was my primary reason for attacking
the code a few years ago. My messages were being truncated more and more
often upon return from EMACS (on Solaris 2.5.1, over NFS). It was not a
problem with EMACS or MM, but with NFS. I added debugging, delays, the
retention of temp files, and all kinds of heuristics until finally it
stopped happening. It isn't pretty but I haven't lost a message since
then. What I did is described in the 0.91 edit history.
ftp://kermit.columbia.edu/kermit/mm/notes-fdc.txt
- Frank
8-Aug-2005 14:00:37-PDT,1942;000000000000
Mail-From: MRC created at 8-Aug-2005 13:56:33
Date: Mon, 8 Aug 2005 13:56:33 -0700 (PDT)
From: Mark Crispin <MRC@lingling.panda.com>
Subject: DST rule update to DATIME.MAC for 2005 Energy Bill
To: TOPS-20@lingling.panda.com
Pithy-Thought: TOPS-20 was a great improvement over its successors
Message-ID: <14048525708.13.MRC@lingling.panda.com>
After 18 years of leaving bad enough alone, our Congresscritters have
succumbed once again to the temptation of tinkering with the daylight
savings time rules.
Fortunately, 18 years ago, I created a table-based mechanism in
TOPS-20 to allow the entry of new rules and convinced DEC to
adopt it in TOPS-20 7.0. OK, it's hopelessly US-centric and you
have to rebuild the monitor, but it's better than what was there
before. [Anyone gonna say "thank you, Mark"??]
Here's the necessary change to DATIME.MAC in TOPS-20 7.0 to get your
monitor ready for 2007. This patch doesn't apply to TOPS-20 4.1, which
has been broken since 1987.
File 1) BACKUP:DATIME.MAC[4,31] created: 2216 16-May-2002
File 2) MON:DATIME.MAC[4,31] created: 1740 05-Aug-2005
1) ; Edit= 9148 to DATIME.MAC on 21-Feb-90 by GSCOTT
****
2)1 ;<MONITOR-SOURCES>DATIME.MAC.9149, 5-Aug-2005 17:40:27, Edit by MRC
2) ; Congress tinkered with DST rules again!
1) ; Edit= 9148 to DATIME.MAC on 21-Feb-90 by GSCOTT
**************
1)4 LSTMAR==31+29+31-1 ;[9098] Last Sunday in March
****
2) SNDMAR==31+29+14-1 ;[9149] Second Sunday in March
2) LSTMAR==31+29+31-1 ;[9098] Last Sunday in March
**************
1)4 DWFUDG==2 ;Constant to normalize day of week
****
2) FSTNOV==31+29+31+30+31+30+31+31+30+31+7-1 ;[9149] First Sunday in November
2) DWFUDG==2 ;Constant to normalize day of week
**************
1)5 DST 1987,FSTAPR,LSTOCT ;[9098] Changed again
****
2) DST 2007,SNDMAR,FSTNOV ;[9149] 2005 Energy bill
2) DST 1987,FSTAPR,LSTOCT ;[9098] Changed again
**************
-------
17-Aug-2005 21:06:51-PDT,9951;000000000000
Return-Path: <slogin@optonline.net>
Received: from mta9.srv.hcvlny.cv.net ([167.206.4.204]) by lingling.panda.com with TCP/SMTP; Wed, 17 Aug 2005 21:00:17 -0700 (PDT)
Received: from optonline.net (hamstr3.srv.hcvlny.cv.net [167.206.5.10])
by mta9.srv.hcvlny.cv.net
(Sun Java System Messaging Server 6.2-2.06 (built May 11 2005))
with ESMTP id <0ILE00GMDGGARI0Q@mta9.srv.hcvlny.cv.net> for
TOPS-20@lingling.panda.com; Thu, 18 Aug 2005 00:00:10 -0400 (EDT)
Received: from [10.240.3.38] (Forwarded-For: [216.179.91.114])
by mstr3.srv.hcvlny.cv.net (mshttpd); Thu, 18 Aug 2005 00:00:10 -0400
Date: Thu, 18 Aug 2005 00:00:10 -0400
From: slogin@optonline.net
Subject: Multiple section program behavior with the mini-exec and EXEC DDT
In-reply-to: <14048525708.13.MRC@lingling.panda.com>
To: TOPS-20@lingling.panda.com
Message-id: <e38fdd25bcef.4303cf8a@optonline.net>
MIME-version: 1.0
X-Mailer: Sun Java(tm) System Messenger Express 6.2-2.06 (built May 11 2005)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
References: <14048525708.13.MRC@lingling.panda.com>
I found some unexpected behavior in the mini-exec and the EXEC EDDT
command which may be of interest. The mini-exec RESET command does
not work for multiple section programs: it only resets the page map
for section zero. In addition, replacing a multiple section program
with the EXEC can then cause problems with EXEC DDT. Here are the
details:
The new FTP server runs in section 1 of the top level fork of the FTP
job. While debugging some code, I have occasionally gronked the
server and wound up in the mini-exec. No big deal if you've got wheel
enabled ... However, I attempted to replicate some behavior in a
regular job by replacing the top-level EXEC with EFTPSR. Everything
worked fine and when I was done, I did a RESET and EXEC and got back
to regular debugging. Later, I noticed the following:
MX>rESET
MX>eXEC
PANDA TOPS-20 Command processor 7.1(4454)-5
End of TOPS20:<SLOGIN>COMAND.CMD.42
@i fil
Connected to STAR:<FTP>. JFNS:
2 TOPS20:<SYSTEM>EXEC.EXE.2 Read, Execute
1 EFTPSR.EXE.1405 Read, Execute
Devices assigned to/opened by this job: TTY47
@close 1
1 EFTPSR.EXE.1405 Can't close file - File still mapped
@ena
!for 0
!i mem
280. pages, Entry vector loc EXEC len 3
Section 0 R, W, E, Private
0-12 Private R, W, E
15-173 TOPS20:<SYSTEM>EXEC.EXE.2 2-160 R, E
200-273 TOPS20:<SYSTEM>EXEC.EXE.2 161-254 R, E
400-402 Private R, W, E
440 Private R, W, E
534 Private R, W, E
545-547 Private R, W, E
554-555 Private R, W, E
644 Private R, W, E
762-763 Private R, W, E
Section 1 R, W, E, Private
1001 EFTPSR.EXE.1405 1 R, CW, E
1010-1014 EFTPSR.EXE.1405 2-6 R, E
1015 Private R, E
1016-1043 EFTPSR.EXE.1405 10-35 R, E
1100-1103 Private R, W, E
1104-1106 Private R, CW, E
1107 Private R, W, E
1777 Private R, W, E
Section 2 R, W, E, Private
2000-2056 EFTPSR.EXE.1405 36-114 R, E
Section 37 R, W, E, Private
!
!unmap (CORE PAGES FROM) 1001 (TO) 2056
?Illegal to UNMAP EXEC
!
As can be seen, the mini-exec reset command didn't get rid of sections
1, 2 and 37. Some investigation in MEXEC.MAC shows that RESET calls
DRESET, viz:
DRESET: MOVEI 1,-4
KFORK ;KILL ALL FORKS
MOVNI 1,1
MOVSI 2,400000
MOVE 3,[1B0+1000] ;CLEAR ALL PAGES FROM USER MAP
PMAP
MOVNI 1,1 ;CLOSE ALL FILES
CLOSF
JFCL
RET
As expected from the behavior above, the code only gets rid of pages
in section zero (which I wasn't using). The problem is that I can't
use the EXEC to unmap the rest of the FTP server because the UNMAP
command thinks that I am trying to punt part of the EXEC itself! I
then went into EXEC DDT and tried doing an SMAP% to get rid of the
sections, viz:
!^Eeddt
DDT
1[ 457045,,430000 -1
B[ 3 .fhslf,,1
C[ 15000 37
D[ 0 jsys 767$x
Interrupt at 155276
MX>sTART
!for 0
!i mem
206. pages, Entry vector loc EXEC len 3
Section 0 R, W, E, Private
0-12 Private R, W, E
15-173 TOPS20:<SYSTEM>EXEC.EXE.2 2-160 R, E
200-273 TOPS20:<SYSTEM>EXEC.EXE.2 161-254 R, E
400-402 Private R, W, E
440 Private R, W, E
534 Private R, W, E
535-544 Fork 0 263-272 R, E
545-547 Private R, W, E
554-555 Private R, W, E
644 Private R, W, E
762-763 Private R, W, E
770 TOPS20:<SUBSYS>UDDT.EXE.1 1 R, E
771 Private R, W, E
777 Private R, W, E
So far, so good, but at this point, EXEC DDT broke, viz:
!^Equit
Interrupt at 155276
MX>rESET
MX>eXEC
PANDA TOPS-20 Command processor 7.1(4454)-5
End of TOPS20:<SLOGIN>COMAND.CMD.42
@ena
!^Eeddt
SYS:XDDT.EXE does not have proper PDV
? Error encountered while attempting to load XDDT
Interrupt at 770233
MX>rESET
MX>eXEC
PANDA TOPS-20 Command processor 7.1(4454)-5
End of TOPS20:<SLOGIN>COMAND.CMD.42
@ena
!for 0
!i mem
235. pages, Entry vector loc EXEC len 3
Section 0 R, W, E, Private
0-12 Private R, W, E
15-173 TOPS20:<SYSTEM>EXEC.EXE.2 2-160 R, E
200-273 TOPS20:<SYSTEM>EXEC.EXE.2 161-254 R, E
400-402 Private R, W, E
440 Private R, W, E
534 Private R, W, E
545-547 Private R, W, E
554-555 Private R, W, E
644 Private R, W, E
762-763 Private R, W, E
Section 37 R, W, E, Private
37700-37701 TOPS20:<SUBSYS>XDDT.EXE.1 1-2 R, CW, E
37703-37732 TOPS20:<SUBSYS>XDDT.EXE.1 3-32 R, CW, E
37735-37736 TOPS20:<SUBSYS>XDDT.EXE.1 33-34 R, CW, E
37740-37753 TOPS20:<SUBSYS>XDDT.EXE.1 35-50 R, E
!^Eed
SYS:XDDT.EXE does not have proper PDV
? Error encountered while attempting to load XDDT
Interrupt at 770233