The history of the MONITOR tops-10)

[Stephen M. Jones]

Has anyone created a definitive timeline for the PDP-6 monitor that
became TOPS-10 as well as showing modifications that Tymshare, SAIl,
Compuserve and others made to the code?

Does version 2.18 exist? Is 4.5 sources the earliest out there at the
moment?
--
..!sdf.org!martians / SDF Public Access UNIX System / http://sdf.org

[ma...@mail.com]

On 2018-07-13, Stephen M. Jones <mart...@sdf.lonestar.org> wrote:
> Has anyone created a definitive timeline for the PDP-6 monitor that
> became TOPS-10 as well as showing modifications that Tymshare, SAIl,
> Compuserve and others made to the code?
>
> Does version 2.18 exist? Is 4.5 sources the earliest out there at the
> moment?

Earth calling /BAH


--
greymaus.ireland.ie
Will Rant for Food.

[Gareth's Downstairs Computer]

On 14/07/2018 07:51, ma...@mail.com wrote:
> On 2018-07-13, Stephen M. Jones <mart...@sdf.lonestar.org> wrote:
>> Has anyone created a definitive timeline for the PDP-6 monitor that
>> became TOPS-10 as well as showing modifications that Tymshare, SAIl,
>> Compuserve and others made to the code?
>>
>> Does version 2.18 exist? Is 4.5 sources the earliest out there at the
>> moment?
>
> Earth calling /BAH
>
>

One tended to be overawed by the PDP10 series, but I wonder if
its operating systems would seem rather infra dig compared to Linux
today?

[John Levine]

In article <picc8e$360$2...@dont-email.me> you write:
>One tended to be overawed by the PDP10 series, but I wonder if
>its operating systems would seem rather infra dig compared to Linux
>today?

In terms of number of features, linux wins by a parsec.

In terms of getting useful work out of a computer that ran at about
5MHz (yes, I know the KA was async) and had 1MB of core, TOPS-10 wins
just as much. It had features that mattered then but don't any more
like doing disk I/O directly in and out of buffers in user space
without an extra copy. I could have done without the sequence numbers
with the flag in the low bit of the word, though.

Of course, even TOPS-10 was a pig compared to DTSS which ran on a GE
635, about the same speed as a KA-10, with a very slow front end
terminal mux (sort of like a 680) and provided good performance to 100
users.




--
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

[Johnny Billquist]

On 2018-07-14 16:45, John Levine wrote:
> In article <picc8e$360$2...@dont-email.me> you write:
>> One tended to be overawed by the PDP10 series, but I wonder if
>> its operating systems would seem rather infra dig compared to Linux
>> today?
>
> In terms of number of features, linux wins by a parsec.

Not so sure. If we talk about the OS as such, there are a couple of
things Linux has that TOPS-20 don't. But that is true in the other
direction as well.

Now, if you instead were to talk about useful applications, then sure,
Linux have way more of that.

> In terms of getting useful work out of a computer that ran at about
> 5MHz (yes, I know the KA was async) and had 1MB of core, TOPS-10 wins
> just as much. It had features that mattered then but don't any more
> like doing disk I/O directly in and out of buffers in user space
> without an extra copy. I could have done without the sequence numbers
> with the flag in the low bit of the word, though.

Disk directly to buffers in user space in Linux? Sure, it's called mmap.
Which, by the way, is more or less a direct ripoff from TOPS-20.

> Of course, even TOPS-10 was a pig compared to DTSS which ran on a GE
> 635, about the same speed as a KA-10, with a very slow front end
> terminal mux (sort of like a 680) and provided good performance to 100
> users.

One of the more interesting features I remember from Tops-10 was that
you could have a daemon that kicked in when files were accessed that you
did not have access rights to. And that went though a script, which
could modify the rules for access to the file arbitrarily. I remember it
being very cool, and I don't know of anything similar today.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Sarr Blumson]

John Levine <jo...@taugh.com> Wrote in message:

>
> I could have done without the sequence numbers
> with the flag in the low bit of the word, though.

That was a convention of some apps, eg BASIC and the line editor
whose name I can't remember. TOPS-10 neither new or
cared.

> Of course, even TOPS-10 was a pig compared to DTSS which ran on a GE
> 635, about the same speed as a KA-10, with a very slow front end
> terminal mux (sort of like a 680) and provided good performance to 100
> users.

The 635 was a piece of junk, but it was much faster than the KA.
And the campus environment was very forgiving. We got good
performance with 40 users on the 265; twice what it could manage
in commercial environments. Dartmouth users were doing simpler
things. And they could sit and think because they didn't get
bills.

Comparing the Datanet 30 to a 680 is an arcane argument that I'm
not qualified to get into.


Sarr

--


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

[fishtoprecords]

On Saturday, July 14, 2018 at 3:21:52 PM UTC-4, Johnny Billquist wrote:
> On 2018-07-14 16:45, John Levine wrote:
> > In terms of number of features, linux wins by a parsec.
>
> Not so sure. If we talk about the OS as such, there are a couple of
> things Linux has that TOPS-20 don't. But that is true in the other
> direction as well.
>
> Now, if you instead were to talk about useful applications, then sure,
> Linux have way more of that.

One of the fundamental design differences with Unix was that since it was started on a PDP-7 (or was it an 11?), they had to engineer a "micro-kernal" way before the concept was invented. There simply wasn't space for much in the OS itself.

Somewhere they invented the concepts of pipes and STDIN and STDOUT, which was simply brilliant.

This let the unix that most folks saw be mostly what LCG folks would call CUSPs, commonly used system programs.

This makes it very hard to be precise about what was "OS" or operating system, and what were simply user programs.

Tops-20 then split out things more clearly than TOPS-10 did, with 'exec' handling all of the user command stuff.

[Johnny Billquist]

On 2018-07-14 21:45, Sarr Blumson wrote:
> John Levine <jo...@taugh.com> Wrote in message:
>>
>> I could have done without the sequence numbers
>> with the flag in the low bit of the word, though.
>
> That was a convention of some apps, eg BASIC and the line editor
> whose name I can't remember. TOPS-10 neither new or
> cared.

The line numbers in BASIC I think was separate from this, but I might be
mistaken.
The editor was most certainly SOS.

[John Levine]

In article <pidjtj$mh2$1...@dont-email.me>,

Sarr Blumson <sarr.b...@alum.dartmouth.orgq> wrote:
>The 635 was a piece of junk, but it was much faster than the KA.

Really? They were both 36 bit machines with memory with about a 1us
cycle time. For most instructions the memory was the limiting thing.

> And the campus environment was very forgiving.

Partly that, partly DTSS was designed more like a transaction monitor
than a timesharing system. User input was buffered in a the
transaction monitor which I think was called SIMON until the user
typed a command (as opposed to a program line that started with a
digit), then it started whatever program handled the input and ran it.

>Comparing the Datanet 30 to a 680 is an arcane argument that I'm
> not qualified to get into.

They did the same thing, sweep a lot of one-bit tty interfaces and
assemble and disassemble characters in real time.

[fishtoprecords]

On Saturday, July 14, 2018 at 6:19:16 PM UTC-4, Johnny Billquist wrote:
> The line numbers in BASIC I think was separate from this, but I might be
> mistaken.
> The editor was most certainly SOS.

Basic started the idea. Line numbers were not always a bad idea. Sure, for editing a program, the line numbers are dumb. But for other documents, it can be handy to be able to remove lines and still refer to a printout. There was also a convention for page/section numbers, so you could refer to lines 450 to 600 on section 42, which was very handy.

There was 'lined' pronounced line-ed, before SOS. SOS was son of stopgap. I never say "stopgap" the father of sos.

Real men used teco, and later 'tv' (teco for video), but the learning curve for teco (like vi/vim today) is pretty steep. Teco had a lot more power than vi/vim do. The unix world would use grep/awk/sed/... for what we would do in just teco.

[Grant Taylor]

On 07/14/2018 05:02 PM, fishtoprecords wrote:
> Teco had a lot more power than vi/vim do.

Can I ask that you defend that statement? What is something that you
could do in Teco that you can't do in vi or (specifically) vim?

I'm asking out of curiosity.

> The unix world would use grep/awk/sed/... for what we would do in
> just teco.

Many of the things that I do with grep / awk / sed can also be done
within ed / vi / vim. I'm just usually not in ed / vi / vim when I need
to do them, and launching an editor just to do the same functions that
can be done with grep / awk / sed seems somewhat backwards to me.



--
Grant. . . .
unix || die

[Bob Eager]

On Sat, 14 Jul 2018 21:22:17 +0200, Johnny Billquist wrote:

> Disk directly to buffers in user space in Linux? Sure, it's called mmap.
> Which, by the way, is more or less a direct ripoff from TOPS-20.

Which was a ripoff from MULTICS and EMAS.

--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org

[Rob Warnock]

Grant Taylor <gta...@tnetconsulting.net> wrote:
+---------------

| On 07/14/2018 05:02 PM, fishtoprecords wrote:
| > Teco had a lot more power than vi/vim do.
|
| Can I ask that you defend that statement? What is something that you
| could do in Teco that you can't do in vi or (specifically) vim?
| I'm asking out of curiosity.

+---------------

Teco commands include conditional (and unconditional) branching,
forwards & backwards, so you can easily write long-running programs
that process massive amounts of data. Remember, the first Emacs
was written *in* Teco!

I myself wrote a form letter processing program in Teco that
ran on a PDP-8 circa 1972 or so [while working at DCA in
Atlanta]. You pointed it at a file with a form letter in it
with keyword variables in various places and another file
containing paragraphs of variable values, one paragraph per
customer, and the Teco program would print out [on a physical
printer] copies of the form letter customized for each customer.
Simple enough that the office secretary could use it...

+---------------

| > The unix world would use grep/awk/sed/... for what we would
| > do in just teco.
|
| Many of the things that I do with grep / awk / sed can also
| be done within ed / vi / vim.

+---------------

Yes, yes, but try doing them in an automated fashion to
100 different files!


-Rob

-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <http://rpw3.org/>
San Mateo, CA 94403

[Rob Warnock]

Johnny Billquist <b...@softjar.se> wrote:
+---------------

| John Levine wrote:
| > In terms of getting useful work out of a computer that ran at about
| > 5MHz (yes, I know the KA was async) and had 1MB of core, TOPS-10 wins
| > just as much. It had features that mattered then but don't any more
| > like doing disk I/O directly in and out of buffers in user space
| > without an extra copy. I could have done without the sequence numbers
| > with the flag in the low bit of the word, though.
|
| Disk directly to buffers in user space in Linux? Sure, it's called mmap.
| Which, by the way, is more or less a direct ripoff from TOPS-20.

+---------------

Actually, TOPS-10 user-space buffered I/O was closer to Linux/Unix's
DIRECT_IO mode than to mmap(), except it was naturally multi-buffered.

That is, you had a *ring* of user-space buffers, with ownership flags
so both the kernel and the user program could see who was working
on a given buffer. This quite naturally allowed kernel I/O and the
user program to work asynchronously, as long as neither side caught
up to the portion of the ring owned by the other side. [And if that
happens, the faster side simply stopped until there was a free (or full)
buffer available for it.]

Plus, you could have *multiple* devices sharing the same user-space
buffer ring, such as disk I/O and magtape I/O, allowing the data to
be streamed continuously from one device through the buffers to the
other device. [In this case the ring was paritioned into *four* areas:
device #1, user area #1, device #2, user area #2.] This is how the
BACKUP program managed to keep the magtapes writing at full speed
[if you had fast-enough disks].

[Johnny Billquist]

On 2018-07-15 01:59, Bob Eager wrote:
> On Sat, 14 Jul 2018 21:22:17 +0200, Johnny Billquist wrote:
>
>> Disk directly to buffers in user space in Linux? Sure, it's called mmap.
>> Which, by the way, is more or less a direct ripoff from TOPS-20.
>
> Which was a ripoff from MULTICS and EMAS.

I'm not sure about that. Multics, from what I read, considered memory
and files to be the same thing. This is sort of a different idea than
saying that you can map a file into a specific part of your memory. I
have no idea how or what EMAS is. :-)

But the comment about the ripoff goes as far as the Unix mmap API being
pretty much a copy of TOPS-20.

[Johnny Billquist]

On 2018-07-15 08:37, Rob Warnock wrote:
> Johnny Billquist <b...@softjar.se> wrote:
> +---------------
> | John Levine wrote:
> | > In terms of getting useful work out of a computer that ran at about
> | > 5MHz (yes, I know the KA was async) and had 1MB of core, TOPS-10 wins
> | > just as much. It had features that mattered then but don't any more
> | > like doing disk I/O directly in and out of buffers in user space
> | > without an extra copy. I could have done without the sequence numbers
> | > with the flag in the low bit of the word, though.
> |
> | Disk directly to buffers in user space in Linux? Sure, it's called mmap.
> | Which, by the way, is more or less a direct ripoff from TOPS-20.
> +---------------
>
> Actually, TOPS-10 user-space buffered I/O was closer to Linux/Unix's
> DIRECT_IO mode than to mmap(), except it was naturally multi-buffered.

You are most probably absolutely right. But I talked about Tops-20, not
TOPS-10. :-)

[Johnny Billquist]

On 2018-07-15 12:03, Huge wrote:

> On 2018-07-15, Johnny Billquist <b...@softjar.se> wrote:
>> On 2018-07-15 01:59, Bob Eager wrote:
>>> On Sat, 14 Jul 2018 21:22:17 +0200, Johnny Billquist wrote:
>>>
>>>> Disk directly to buffers in user space in Linux? Sure, it's called mmap.
>>>> Which, by the way, is more or less a direct ripoff from TOPS-20.
>>>
>>> Which was a ripoff from MULTICS and EMAS.
>>
>> I'm not sure about that. Multics, from what I read, considered memory
>> and files to be the same thing. This is sort of a different idea than
>> saying that you can map a file into a specific part of your memory. I
>> have no idea how or what EMAS is. :-)
>>
>> But the comment about the ripoff goes as far as the Unix mmap API being
>> pretty much a copy of TOPS-20.
>

> I find the word "ripoff" problematical. Virtually everything in computer
> science is based on something else. Thinking "that's a good idea" and
> re-using it in a new and interesting way is hardly "ripping off".

If you take the concept *and* API and copy it verbatim, I think calling
it a ripoff is not so wrong.
Had they just taken the concept, then I'd say inspired by, or something
similar. But this one goes a bit further. I remember back when Sun
introduced mmap, that I heard (don't remember from where), that they had
looked at TOPS-20 when they did the implementation for SunOS.

[Johnny Billquist]

On 2018-07-15 12:17, Johnny Billquist wrote:
> On 2018-07-15 12:03, Huge wrote:
>> On 2018-07-15, Johnny Billquist <b...@softjar.se> wrote:
>>> On 2018-07-15 01:59, Bob Eager wrote:
>>>> On Sat, 14 Jul 2018 21:22:17 +0200, Johnny Billquist wrote:
>>>>
>>>>> Disk directly to buffers in user space in Linux? Sure, it's called
>>>>> mmap.
>>>>> Which, by the way, is more or less a direct ripoff from TOPS-20.
>>>>
>>>> Which was a ripoff from MULTICS and EMAS.
>>>
>>> I'm not sure about that. Multics, from what I read, considered memory
>>> and files to be the same thing. This is sort of a different idea than
>>> saying that you can map a file into a specific part of your memory. I
>>> have no idea how or what EMAS is. :-)
>>>
>>> But the comment about the ripoff goes as far as the Unix mmap API being
>>> pretty much a copy of TOPS-20.
>>
>> I find the word "ripoff" problematical. Virtually everything in computer
>> science is based on something else. Thinking "that's a good idea" and
>> re-using it in a new and interesting way is hardly "ripping off".
>
> If you take the concept *and* API and copy it verbatim, I think calling
> it a ripoff is not so wrong.
> Had they just taken the concept, then I'd say inspired by, or something
> similar. But this one goes a bit further. I remember back when Sun
> introduced mmap, that I heard (don't remember from where), that they had
> looked at TOPS-20 when they did the implementation for SunOS.

I should probably modify my language.
For many, "verbatim" is probably hard to justify here. After all, the
TOPS-20 PMAP% system call is an API from assembly language, while the
Unix mmap() system call is an API from C.

Also, PMAP% have some additional features and functions that mmap() does
not.
mmap() is maybe more properly described as a subset of PMAP% in one way.

But mmap() is essentially exactly the same as PMAP%.

[John Levine]

In article <pieq2s$ctl$1...@dont-email.me>, Rob Warnock <rp...@rpw3.org> wrote:
>Actually, TOPS-10 user-space buffered I/O was closer to Linux/Unix's
>DIRECT_IO mode than to mmap(), except it was naturally multi-buffered.
>
>That is, you had a *ring* of user-space buffers, with ownership flags
>so both the kernel and the user program could see who was working
>on a given buffer. This quite naturally allowed kernel I/O and the
>user program to work asynchronously, as long as neither side caught
>up to the portion of the ring owned by the other side. [And if that
>happens, the faster side simply stopped until there was a free (or full)
>buffer available for it.]

OS/360 QSAM worked pretty much the same way, device I/O in and out of
a ring of user space buffers. This shows up in the PL/I LOCATE mode
for file I/O, where it gives you a pointer to the record it just read
or that you are about to write.

I suppose it still does in z/OS although these days it's likely all
faked with copies from memory mapped buffers since modern disks don't
have variable sized records like CKD disks did.

R's,
John

[John Levine]

In article <pif63v$4av$2...@Iltempo.Update.UU.SE>,

>You are most probably absolutely right. But I talked about Tops-20, not
>TOPS-10. :-)

How many ways can there be to say that this block of memory corresponds to
that file, and use the pager to move it back and forth?

[Andy Valencia]

Grant Taylor <gta...@tnetconsulting.net> writes:
> > Teco had a lot more power than vi/vim do.

> Can I ask that you defend that statement? What is something that you
> could do in Teco that you can't do in vi or (specifically) vim?

I usually break out teco when I need to do adjustments which span
line boundaries. I've run into files where name is on one line and
value on the next:

Joe
100
Sue
123
Sam
777

And I really want them CSV-ish:
(zj)
<0l$i"$l2r$i"$2d$i,$l$.-z;>$$
ht
"Joe",100
"Sue",123
"Sam",777

Dollars are escapes, I err on the side of breaking up my commands'
values.

Andy

[fishtoprecords]

On Sunday, July 15, 2018 at 7:38:25 AM UTC-4, Johnny Billquist wrote:
> I should probably modify my language.
> For many, "verbatim" is probably hard to justify here. After all, the
> TOPS-20 PMAP% system call is an API from assembly language, while the
> Unix mmap() system call is an API from C.

True, but C was simply a semi-high-level language that mapped nearly perfectly to PDP-11 assembly code
*p = *s;
sure looks like one PDP-11 instruction.

[fishtoprecords]

On Saturday, July 14, 2018 at 7:16:01 PM UTC-4, Grant Taylor wrote:
> On 07/14/2018 05:02 PM, fishtoprecords wrote:
> > Teco had a lot more power than vi/vim do.
>
> Can I ask that you defend that statement? What is something that you
> could do in Teco that you can't do in vi or (specifically) vim?
>
> I'm asking out of curiosity.

teco has real if/then tests (the syntax was very weird) with forward and backward jumps. You could do things like:
1) find a line starting with "if", if the next identifer is 'foo' then skip two lines, s/baz/mumble/
and then delete until the next ';'

Which was very handy when doing serious hacking in Macro-10 or Macro-20.
(we never programmed in assembly language, at least on 10s and 20s, we programmed in "marco" which was a pretty powerful macro). Much more capable than the macro-preprocessor in 'c' for unix. Of course, since Macro was so powerful, it was complex and there were bugs in it. These bugs were expected features for a lot of critical monitor and CUSP programs, so the bugs could never be fixed.

[Sam Weiner]

In article <pidigf$p59$1...@Iltempo.Update.UU.SE>,

[smw] You are talking about FILDAE (file daemon.) See the TOPS-10
Operating System Commands manual for more information.

Sam

[Gareth's Downstairs Computer]

On 15/07/2018 11:03, Huge wrote:
>
> I find the word "ripoff" problematical. Virtually everything in computer
> science is based on something else. Thinking "that's a good idea" and
> re-using it in a new and interesting way is hardly "ripping off".
>

ISTR that it was Isaac Newton who said that we stand on the shoulders
of giants.

[Peter Flass]

Which, I believe, is just a wrapper for the corresponding Linux SYSCALL.


--
Pete

[Peter Flass]

Gareth's Downstairs Computer

Or, midgets are standing on my shoulders.

--
Pete

[Johnny Billquist]

Oh, sure. But I guess it does appear different in the details from the
TOPS-20 system call, so "verbatim" can be viewed as incorrect.
After all, the system calls in TOPS-20 places the arguments in AC1-AC4,
while I think Linux places them on the stack, for example. But it's
essentially only different at that level.

[Johnny Billquist]

On 2018-07-15 14:58, John Levine wrote:
> In article <pif63v$4av$2...@Iltempo.Update.UU.SE>,
>> You are most probably absolutely right. But I talked about Tops-20, not
>> TOPS-10. :-)
>
> How many ways can there be to say that this block of memory corresponds to
> that file, and use the pager to move it back and forth?

Not sure. But I know many systems don't even have the concept. And on
some systems transfers to/from files are done through system calls with
DMA running directly to user buffers without going through the whole VM
system, which might be argued is even more efficient.
So, even the idea to use the VM subsystem for file access is not
something that is that universal.

And then you have the question of details of implementation and API. I
bet there might be some creative solutions out there, if you start
searching.

[Johnny Billquist]

Right! The name was escaping me. Thanks for reminding. It was a very
cool feature, me brain keeps telling me. But oh so long ago now since I
even touched Tops-10.

[Gareth's Downstairs Computer]

Larger fleas have smaller fleas
Upon their backs to bite 'em.
Smaller fleas have lesser fleas,
And so ad infinitum.

[Anne & Lynn Wheeler]

John Levine <jo...@taugh.com> writes:
> OS/360 QSAM worked pretty much the same way, device I/O in and out of
> a ring of user space buffers. This shows up in the PL/I LOCATE mode
> for file I/O, where it gives you a pointer to the record it just read
> or that you are about to write.
>
> I suppose it still does in z/OS although these days it's likely all
> faked with copies from memory mapped buffers since modern disks don't
> have variable sized records like CKD disks did.

z/OS still requires CKD disks ... even tho they haven't been made for
decades, emulated (out in the hardware, not back in the system software)
on industry standard fixed block disks. Array/disk controllers have CKD
configuration setups as to simulated disks specified as some variation
on 3380CKD and/or 3390CKD ... simulate 3380 or 3390 track size, simulate
3380 or 3390 tracks per cylinder ... but are allowed to specify number
of cylinders (from much less than any real 3380/3390 to significantly
more than any real 3380/3390).

Even when there were real disks that claimed to be CKD ... there were
already moving to fixed-sized cells (as part of CRC) and number of
records/track calculations included rouding record size up to cell size.

significantly cutting storage requirements, os/360 i/o applications
libraries included building channel programs in user space ... and then
passing pointer to the (application built) channel program via
EXCP/SVC0. when os/360 moved to virtual memory, EXCP processing faced
the same problem that virtual machine cp67/vm370 faced ... channel
programs required real addresses ... and the application channel
programs were all virtual addresses. The initial OS360 EXCP
implementation for virtual memory borrowed CP67's CCWTRANS which builds
copy of the passed channel program, substituting real addresses for the
virtaul (and some fiddling when buffer crosses non-contiguous page
boundary).

--
virtualization experience starting Jan1968, online at home since Mar1970

[fishtoprecords]

On Sunday, July 15, 2018 at 3:08:55 PM UTC-4, Johnny Billquist wrote:
> After all, the system calls in TOPS-20 places the arguments in AC1-AC4,
> while I think Linux places them on the stack, for example. But it's
> essentially only different at that level.

I claim that is isomorphic. Stacks on 10s and 20s were fairly small, programs were small. The Sparc chips were designed around the stack, so its a very natural thing to do.

[Questor]

On Sun, 15 Jul 2018 06:23:50 -0000 (UTC), rp...@rpw3.org (Rob Warnock) wrote:
>Grant Taylor <gta...@tnetconsulting.net> wrote:
>+---------------
>| On 07/14/2018 05:02 PM, fishtoprecords wrote:
>| > Teco had a lot more power than vi/vim do.
>|
>| Can I ask that you defend that statement? What is something that you
>| could do in Teco that you can't do in vi or (specifically) vim?
>| I'm asking out of curiosity.
>+---------------
>
>Teco commands include conditional (and unconditional) branching,
>forwards & backwards, so you can easily write long-running programs
>that process massive amounts of data. Remember, the first Emacs
>was written *in* Teco!

Conditionals, branching, and memory locations ("q-registers") that could store
either numbers or blocks of text. I knew of someone who wrote a primitive BASIC
interpreter in TECO.

Here's a cheat sheet of TECO commands by character that should stir some
memories in the greybeards:

============================================================
NULL ignored
^A output message to terminal
^B current date
^C interrupt
^D set radix to decimal
^E form feed flag
^E<n> (match char) match ASCII code n
^E[] (match char) match one of list
^EA (match char) match alphabetics
^EB (match char) match separator character
^EC (match char) match symbol constituent
^ED (match char) match digit
^EGq (match char) match contents of q-register
^EL (match char) match line terminators
^EMx (match char) match any number of x
^EQq (string build char) use contents of q-register q
^ER (match char) match alphanumerics
^ES (match char) match spaces and/or tabs
^EUq (string build char) use ASCII code in q-register
^EV (match char) match lowercase
^EW (match char) match uppercase
^EX (match char) match anything
^F not implemented
^G^G kill command string
^G<SP> retype current command line
^G* retype entire current command line
^H current time
BS immediate mode: back up one line and type one line
TAB insert tab and text
LF ignored in commands
LF immediate mode: advance one line and type one line
VT not a TECO command
FF output a form feed to terminal
CR ignored
^N end of file flag
^Nx (match char) match any character but x
^O set radix to octal
^P not a TECO command
n^Q convert line offset to character offset
^Qx (string char) use x literally
^R value of current radix
n^R set radix to n
^Rx (string char) use x literally
^S -(length of last inserted string or found search string)
^S immediate mode: not yet implemented
^S (match char) match any separator character
^T ASCII value of next character typed in
n^T output character whose ASCII value is n to the terminal screen
^U (command line) erase current command line
^Uq put string into q-register
:^Uq append string to q-register
n^Uq put ASCII character "n" into q-register
n:^Uq append ASCII "n" to q-register
^V convert search strings to lowercase
^Vx (string char) convert x to lowercase
^W convert search strings to uppercase
^Wx (string char) convert x to uppercase
^X search mode flag
^X (match char) match any character
^Y equivalent to ".+^S,."
^Z size of text in all q-registers, plus command line
^Z^Z^Z quit TECO, leave everything as it was before TECO was entered
ESC command and string terminator
^[ like ESC
^\ not a TECO command
^] not a TECO command
^^x ASCII value of x
n^_ ones complement of n
SP ignored
! define tag
n"< test for less than zero
n"= test for equal to zero
n"> test for greater than zero
n"A test for alphabetic
n"C test for symbol constituent
n"D test for digit
n"E test for equal to zero
n"F test for false
n"G test for greater than zero
n"L test for less than zero
n"N test for not equal to zero
n"R test for alphanumeric
n"S test for successful
n"T test for true
n"U test for unsuccessful
n"V test for lowercase
n"W test for uppercase
# logical OR
$ separate TECO commands
n%q add n to q-register q, return the result
& logical AND
' end of conditional
( numeric expression grouping
) numeric expression grouping
* multiplication
*q immediate mode: save last command string in q-register q
+ addition
, numeric argument separator
- subtraction or negation
. current pointer position
/ division
/ immediate mode: type detailed explanation of error
0-9 numeric argument constructors
: modify next command
n; exit iteration of n is greater than or equal to zero
n:; exit iteration if n is less than or equal to zero
n< iterate n times
n= type n in decimal
n== type n in octal
n=== type n in hexadecimal
n:= type n in decimal, no carriage return
n:== type n in octal, no carriage return
n:=== type n in hexadecimal, no carriage return
> end iteration
? toggle trace mode
? immediate mode: type out erroneous command string
@ modify next text argument
A append next input page to edit buffer
nA ASCII value of character at .+n
n:A append n lines to input buffer
B always zero. represents beginning of edit buffer
nC advance n characters
nD delete n characters
m,nD delete between m and n (same as m,nK)
E%q write q-register to file
nE_ destructive search without page protection
EA select secondary output stream
EB open input and output files
EC copy input file to output file and close files
nEC not yet implemented
ED edit mode flag
EF close output file
EH help level flag
EI open indirect command file
EK kill output file
EL open log file
EN wildcard lookup
EO return version number of TECO
EP select secondary input stream
EQq read from file into q-register
ER open input file
ES search verification flag
ET type out control flag
EU case flagging flag
EV edit verify flag
EW open output file
EX close files and exit
EY read without yank protection
nF_ destructive search and replace
F' flow to end of conditional
F< flow to start of iteration
F> flow to end of iteration
F| flow to ELSE part of conditional
m,nFB search between locations m and n
nFB search, bounded by n lines
m,nFC search and replace between m and n
nFC search and replace over n lines
nFD search for and delete string
nFK search for string and delete intervening text
nFN paged search and replace
FR replace last string
nFS search and replace
Gq get string from q-register into edit buffer
G* get string from filespec buffer into edit buffer
G_ get string from search buffer into edit buffer
:Gq type text in q-register q
:G* type filespec
:G_ type search string
H equivalent to B,Z
I insert text
nI insert character whose ASCII value is n
nJ move pointer to J
nK kill n lines
m,nK delete between m and n (same as m,nD)
nL advance n lines
Mq execute commands in q-register
nN paged search
O go to label
nO goto selected label in list
nP advance n pages
m,nP write out characters m to n
nPW write edit buffer n times
m,nPW write out characters m to n
Qq number in q-register q
:Qq size of text in q-register q
nR back up n characters
nS search for nth occurrence of a string
::S compare string
nT type n lines
m,nT type characters between m and n
nUq put n into q-register q
nV view n lines
m,nV view m lines before, n lines after pointer
W not yet implemented
nXq put n lines into q-register q
m,nXq put character m through n into q-register q
n:Xq append n lines to q-register q
m,n:Xq append characters m through n to q-register q
Y yank a page into the edit buffer
Z end of buffer (number of characters in the edit buffer)
[q push q-register q onto q-register stack
\ value of string in edit buffer
n\ convert n to digits in edit buffer
]q pop q-register stack into q-register q
n_ destructive paged search
` not a TECO command
a-z treated as uppercase equivalents
{ not a TECO command
| start of ELSE part of conditional
} not a TECO command
~ not a TECO command
DEL not a TECO command
============================================================

[Questor]

On Fri, 13 Jul 2018 21:32:56 +0000 (UTC), mart...@sdf.lonestar.org (Stephen M.
Jones) wrote:
>Has anyone created a definitive timeline for the PDP-6 monitor that
>became TOPS-10 as well as showing modifications that Tymshare, SAIl,
>Compuserve and others made to the code?

You might want to narrow your target. TOPS-10 was shipped with complete
sources, and nearly every site, including inside DEC, made modifications -- some
minor, some major. You'd have to start a separate code fork for nearly every
TOPS-10 machine ever sold. Most, if not all of those changes were probably lost
when the machines were scrapped, as they were the property of the companies
that bought those systems.


>Does version 2.18 exist? Is 4.5 sources the earliest out there at the
>moment?

[Questor]

On 14 Jul 2018 06:51:12 GMT, ma...@mail.com wrote:

>On 2018-07-13, Stephen M. Jones <mart...@sdf.lonestar.org> wrote:
>> Has anyone created a definitive timeline for the PDP-6 monitor that
>> became TOPS-10 as well as showing modifications that Tymshare, SAIl,
>> Compuserve and others made to the code?
>>

>> Does version 2.18 exist? Is 4.5 sources the earliest out there at the
>> moment?
>

>Earth calling /BAH

Don't overestimate her knowledge. She wasn't around for the first few years of
TOPS-10, and she would know little or nothing about the changes customers made
to their systems.

[Questor]

On Sat, 14 Jul 2018 21:22:17 +0200, Johnny Billquist <b...@softjar.se> wrote:
>One of the more interesting features I remember from Tops-10 was that
>you could have a daemon that kicked in when files were accessed that you
>did not have access rights to. And that went though a script, which
>could modify the rules for access to the file arbitrarily. I remember it
>being very cool, and I don't know of anything similar today.

The file daemon (FILDAE). That was an add-on that was bolted onto TOPS-10
later. It was possible, through injudicious settings in the control file
(ACCESS.USR?), to deny even a privileged user access to a file, including
ACCESS.USR. If you painted yourself into that corner, the only way out was to
either kill FILDAE or directly edit the file protection codes on disk.

[Joe Pfeiffer]

This may be due to my lack of experience (pretty much all I've ever
programmed for once past toy student projects has been either Unix
derivatives or bare metal) and imagination, but I'm having a hard time
imagining an API for an mmap()-like function that looks substantially
different from mmap().

[fishtoprecords]

On Sunday, July 15, 2018 at 7:37:35 PM UTC-4, Questor wrote:
> Conditionals, branching, and memory locations ("q-registers") that could store
> either numbers or blocks of text. I knew of someone who wrote a primitive BASIC
> interpreter in TECO.
>
> Here's a cheat sheet of TECO commands by character that should stir some
> memories in the greybeards:
>

> :^Uq append string to q-register

> n^_ ones complement of n

> ' end of conditional
> : modify next command

> @ modify next text argument

Wow that brings back memories.
serious teco hacks were really ugly, when you would see a bunch of test and colons, you know it was moving into strange mode.

Why would a text editor need a ones complement of a number?

[fishtoprecords]

Every customer made non-trivial changes to the monitor. Well, i can't prove that every site, but every site that I knew of sure did. Larger sites had 3 or 4 serious monitor/cusp engineers, and a large number of apprentice wizards.

First Data and CompuServ made totally different front-end, networking machines by the early 1970s. I expect that ADP/Cyphernet did as well.

[Sam Weiner]

In article <fc8635f4-4dc4-4ba4...@googlegroups.com>,

[smw] As did Rapidata. They even built their own concentrators, originally
for the GE-400s but also used on the KL-10 until they switched the network
to PDP-11s. Most of the monitor changes were to make the system look like
a Dartmouth style system taking line numbered entries at command level. We
had the normal TOPS-10 interface on internal lines but on trips where I had
to call in through the network, I had to make do with the line oriented
stuff. Painful.

Sam

[Peter Flass]

Wouldn't many of these made it onto the DECUS tape?

--
Pete

[Rob Warnock]

fishtoprecords <pat2...@gmail.com> wrote:
+---------------
| ...but C was simply a semi-high-level language that

| mapped nearly perfectly to PDP-11 assembly code
| *p = *s;
| sure looks like one PDP-11 instruction.

+---------------

That's nothing. *This*:

*p++ = *s++;

is also just one PDP-11 instruction. ;-}


-Rob

-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <http://rpw3.org/>
San Mateo, CA 94403

[fishtoprecords]

On Monday, July 16, 2018 at 6:44:07 AM UTC-4, Rob Warnock wrote:
> That's nothing. *This*:
>
> *p++ = *s++;
>
> is also just one PDP-11 instruction. ;-}

Yes, that was what I was thinking of, but its been way too long.

I will argue, with no real proof, that this PDP-11 instruction is why C was cursed with null delimited strings for decades.

[Scott Lurndal]

John Levine <jo...@taugh.com> writes:
>In article <pieq2s$ctl$1...@dont-email.me>, Rob Warnock <rp...@rpw3.org> wrote:
>>Actually, TOPS-10 user-space buffered I/O was closer to Linux/Unix's
>>DIRECT_IO mode than to mmap(), except it was naturally multi-buffered.
>>
>>That is, you had a *ring* of user-space buffers, with ownership flags
>>so both the kernel and the user program could see who was working
>>on a given buffer. This quite naturally allowed kernel I/O and the
>>user program to work asynchronously, as long as neither side caught
>>up to the portion of the ring owned by the other side. [And if that
>>happens, the faster side simply stopped until there was a free (or full)
>>buffer available for it.]

>
>OS/360 QSAM worked pretty much the same way, device I/O in and out of
>a ring of user space buffers.

Burroughs MCP I/O worked the same way, where the user-space buffers were
sized for one block (record size * records-per-block). The application
code (generated by the compiler) handled the unblocking/blocking.

[Questor]

On Sun, 15 Jul 2018 18:37:35 -0700 (PDT), fishtoprecords <pat2...@gmail.com>
wrote:

In my haste to post that, I neglected to mention it is from the documents
included in a port of TECO for MS-DOS for the PC. There may be some extensions
and small differences from "classic" TOPS-10 TECO such as that one's compliment
modifier, but I'm not sure either way.

MIT's ITSTECO had a command to insert random characters at the pointer.

[Questor]

On Sun, 15 Jul 2018 18:43:58 -0700 (PDT), fishtoprecords <pat2...@gmail.com>
wrote:

>On Sunday, July 15, 2018 at 7:38:44 PM UTC-4, Questor wrote:
>> On 14 Jul 2018 06:51:12 GMT, ma...@mail.com wrote:
>> >Earth calling /BAH
>>
>> Don't overestimate her knowledge. She wasn't around for the first
>> few years of TOPS-10, and she would know little or nothing about
>> the changes customers made to their systems.
>
>Every customer made non-trivial changes to the monitor. Well, i can't prove that
>every site, but every site that I knew of sure did. Larger sites had 3 or 4
>serious monitor/cusp engineers, and a large number of apprentice wizards.

Not every site made non-trivial changes. A big part of the issue was having to
re-integrate any modifications into new releases. A small site with limited
staff was likely to hew closely to the supported version.

As an example, I knew a couple of people who worked at ADP Networks when DEC
made a major change from their MPB batch system to the new Galaxy software (both
controlled batch jobs and unit record equipment input/output queues). ADP had
made many changes that served their needs as a timesharing business, and all
those modifications had to be implemented into a completely different code base.
It was a major effort that took a couple of man-years.

>First Data and CompuServ made totally different front-end, networking machines
>by the early 1970s. I expect that ADP/Cyphernet did as well.

ADP eventually acquired First Data, and yes, they had their own proprietary
network with front-ends in major cities across the country that connected to
their PDP-10 data centers in Ann Arbor and Waltham. Significant changes were
required to TOPS-10 to accomodate their network.

[Questor]

On Mon, 16 Jul 2018 02:35:26 +0000 (UTC), wei...@TheWorld.com (Sam Weiner)
wrote:

Didn't Rapidata have a bespoke network, purportedly written over a weekend by
one of their engineers (a WPI graduate, if memory serves)? This would have been
in the late '70s.

[Questor]

I think you mean "a" DECUS tape, since AFAIK there isn't "the" DECUS tape.

I can't speak authoritatively on every turn in DECUS history, but generally it
was a way for customers to share software/tools with each other, and perhaps for
DEC to give away some unsupported extras. The official, supported release
software, even for older superceded versions, would not have been distributed
through DECUS.

[John Levine]

In article <522cb55e-4eae-4dbd...@googlegroups.com>,

fishtoprecords <pat2...@gmail.com> wrote:
>I will argue, with no real proof, that this PDP-11 instruction is why C was cursed with null delimited strings for decades.

It's well documented that is not the case. C does map pretty well
onto the PDP-11 but the language was already largely complete on a GE 635
before it ever was implemented on the -11.

--
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

[John Levine]

In article <5b4ce8ed...@news.dslextreme.com>,

Questor <use...@only.tnx> wrote:
>Not every site made non-trivial changes. A big part of the issue was having to
>re-integrate any modifications into new releases. A small site with limited
>staff was likely to hew closely to the supported version.

At the Yale CS department I don't think we customized TOPS-10 at all.

[fishtoprecords]

On Monday, July 16, 2018 at 2:50:54 PM UTC-4, Questor wrote:
> >Every customer made non-trivial changes to the monitor. Well, i can't prove that
> >every site, but every site that I knew of sure did. Larger sites had 3 or 4
> >serious monitor/cusp engineers, and a large number of apprentice wizards.
>
> Not every site made non-trivial changes. A big part of the issue was having to
> re-integrate any modifications into new releases. A small site with limited
> staff was likely to hew closely to the supported version.

That has always been THE big issue. Was then, is today.

And there were some very small PDP-10 (and later Tops-20) sites and machines out there. But I always hung around at DECUS with guys who hacked the hell out of each release.

There was a fundamental theological question about how "supported" the versions were from LCG. If you were small, you had to tolerate what they claimed was support. But those of us in commercial sites had a business to run, and the business was not selling hardware, which was LCG's business.



> As an example, I knew a couple of people who worked at ADP Networks...
> the new Galaxy software.... ADP had

> made many changes that served their needs as a timesharing business, and all
> those modifications had to be implemented into a completely different
> code base. It was a major effort that took a couple of man-years.

Yes, it was unclear if Galaxy was that good of an "improvement" to justify that cost, but it was a cost of doing business.

>
> ADP eventually acquired First Data,

Yes, I worked at First Data and worked cleaning up after the fire that cost First Data its independence. I stayed at ADP post-acquisition for maybe six months. As usual, there was at least 150% turn-over of staff when ADP came in and improved things.

[Sam Weiner]

In article <5b4ce90a...@news.dslextreme.com>,

[smw2] There are/were a number of Rapidatas. The one I'm talking about
started around 1968 in a basement level at the Empire State building. By
the time I joined in 1973, they had moved most if not all the 400s out to
NJ, brought in a KI10 while waiting for the KLs which were still being broken
in. We had several folks from NJIT, Stevens, and Rutgers. I don't recall
anyone from WPI (which is down the road from me now) but I don't have the
details for everyone who passed through. The late '70s sounds like when
they started phasing in PDP-11s to replace the GTE Tempos used for the
network but I'm pretty sure it took more than a weekend to get the first -11
running. I wasn't in the systems group so don't have a lot of the details.

[smw2] Good memories.

Sam

[Questor]

On Tue, 17 Jul 2018 02:05:14 +0000 (UTC), wei...@TheWorld.com (Sam Weiner)

The one I thought I was remembering was on Route 128, a few miles
south of First Data/ADP. It's possible I don't even have the company's name
correct.

[Sarr Blumson]

John Levine <jo...@taugh.com> Wrote in message:
> In article <pidjtj$mh2$1...@dont-email.me>,
> Sarr Blumson <sarr.b...@alum.dartmouth.orgq> wrote:
>>The 635 was a piece of junk, but it was much faster than the KA.

Well the 635 had 72 bit internal data paths and could actually
overlap pairs of instructions. Which is why "repeat double"
worked. But the main difference was that it had a real mainframe
IO structure. The KAs was cheap and made it easy to attach home
built stuff. Which was the market DEC was in before they got the
idea they were competing with IBM.

sarr


--


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

[Rich Alderson]

John Levine <jo...@taugh.com> writes:

> In article <522cb55e-4eae-4dbd...@googlegroups.com>,
> fishtoprecords <pat2...@gmail.com> wrote:

>> I will argue, with no real proof, that this PDP-11 instruction is why C was
>> cursed with null delimited strings for decades.

> It's well documented that is not the case. C does map pretty well
> onto the PDP-11 but the language was already largely complete on a GE 635
> before it ever was implemented on the -11.

Sorry, that's incorrect.

Development of Unix moved off the GE-635 during the PDP-7 phase of Unix
development, where the B language was created. The C language was a follow-on
to B once Unix and the B compiler had been moved to the PDP-11 (in assembler).
Using C for the Unix kernel was a rewrite from the PDP-11 assembler version.

--
Rich Alderson ne...@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

[Rich Alderson]

Gareth's Downstairs Computer <headstone255.but.n...@yahoo.com> writes:

> On 15/07/2018 20:00, Peter Flass wrote:
>> Gareth's Downstairs Computer
>> <headstone255.but.n...@yahoo.com> wrote:

>>> On 15/07/2018 11:03, Huge wrote:

>>>> I find the word "ripoff" problematical. Virtually everything in computer
>>>> science is based on something else. Thinking "that's a good idea" and
>>>> re-using it in a new and interesting way is hardly "ripping off".

>>> ISTR that it was Isaac Newton who said that we stand on the shoulders
>>> of giants.

>> Or, midgets are standing on my shoulders.

> Larger fleas have smaller fleas
> Upon their backs to bite 'em.
> Smaller fleas have lesser fleas,
> And so ad infinitum.

Swift.

IIRC.

[Rich Alderson]

Bob Clements <fake_a...@k1bc.com> writes:

> Best to all of us old-guys.

> /Rcc
> MIT 60-64
> DEC 64-71
> BBN 71-02

Hey, Bob! Good to see you!

[Ahem A Rivet's Shot]

On 17 Jul 2018 16:11:11 -0400

Rich Alderson <ne...@alderson.users.panix.com> wrote:

> Gareth's Downstairs Computer
> <headstone255.but.n...@yahoo.com> writes:
>
> > On 15/07/2018 20:00, Peter Flass wrote:
> >> Gareth's Downstairs Computer
> >> <headstone255.but.n...@yahoo.com> wrote:
> >>> On 15/07/2018 11:03, Huge wrote:
>
> >>>> I find the word "ripoff" problematical. Virtually everything in
> >>>> computer science is based on something else. Thinking "that's a good
> >>>> idea" and re-using it in a new and interesting way is hardly
> >>>> "ripping off".
>
> >>> ISTR that it was Isaac Newton who said that we stand on the shoulders
> >>> of giants.
>
> >> Or, midgets are standing on my shoulders.
>
> > Larger fleas have smaller fleas
> > Upon their backs to bite 'em.
> > Smaller fleas have lesser fleas,
> > And so ad infinitum.
>
> Swift.

That they are, and they jump a lot.


--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/

[fishtoprecords]

On Tuesday, July 17, 2018 at 4:08:45 PM UTC-4, Rich Alderson wrote:

> John Levine <jo...@taugh.com> writes:
> > It's well documented that is not the case. C does map pretty well
> > onto the PDP-11 but the language was already largely complete on a GE 635
> > before it ever was implemented on the -11.
>
> Sorry, that's incorrect.
>
> Development of Unix moved off the GE-635 during the PDP-7 phase of Unix
> development, where the B language was created. The C language was a follow-on
> to B once Unix and the B compiler had been moved to the PDP-11 (in assembler).
> Using C for the Unix kernel was a rewrite from the PDP-11 assembler version.

The mapping of C from PDP-11 machine instructions is pretty obvious if you look at the early PDP-11 hardware documentation and your basic K&R

I am pretty sure that one of the early papers also mentions it.

The B to C development path was well known, done at Bell Labs. At the same time, Bliss was being developed for same purpose: writing operating systems and cusps in a higher level language. I don't know if Bliss was just out of CMU or if MIT and the other usual PDP-10 schools were doing the research as well.

[Grant Taylor]

On 07/15/2018 12:23 AM, Rob Warnock wrote:
> Teco commands include conditional (and unconditional) branching, forwards
> & backwards, so you can easily write long-running programs that process
> massive amounts of data.

Impressive.

I know of Vimscript. I've never written anything. So I can't speak to
what it can and can't do. Though it sounds like Teco might best it.

> Remember, the first Emacs was written *in* Teco!

So I've read. Which is impressive to me.

> I myself wrote a form letter processing program in Teco that ran on a
> PDP-8 circa 1972 or so [while working at DCA in Atlanta]. You pointed it
> at a file with a form letter in it with keyword variables in various
> places and another file containing paragraphs of variable values,
> one paragraph per customer, and the Teco program would print out [on a
> physical printer] copies of the form letter customized for each customer.
> Simple enough that the office secretary could use it...

Interesting.

I think I'd reach for a macro package to do something like that. But,
that being said, I think that it would be possible to load the
paragraphs into macros (as long as there were less than 27 of them) and
do substitution across files in vim. But that would likely be difficult
to set up and be fragile.

I'd likely look at m4 myself.

> Yes, yes, but try doing them in an automated fashion to 100 different
> files!

I think vim could be coaxed into doing it. But that's not the tool that
I'd likely reach for in this use case.

Thank you for the example.



--
Grant. . . .
unix || die

[Grant Taylor]

On 07/15/2018 11:10 AM, fishtoprecords wrote:
> teco has real if/then tests (the syntax was very weird) with forward
> and backward jumps. You could do things like:

I'm guessing that "real if/then tests" is significantly more than
pattern matching. It does look to me like vimscript does have if /
elseif / else statements.

> 1) find a line starting with "if", if the next identifer is 'foo' then
> skip two lines, s/baz/mumble/ and then delete until the next ';'

/if\( 'foo'\)\@=
2j
:s/baz/mumble/
j
d/;

I'm brain dead and completely speculating. Typing the commands in vim
isn't quite the same. Though I suspect that an editor script for ed /
ex might do the trick.

> Which was very handy when doing serious hacking in Macro-10 or Macro-20.

Restructuring programs can be something between challenging and
annoying. But quite rewarding when it works.

> (we never programmed in assembly language, at least on 10s and 20s,
> we programmed in "marco" which was a pretty powerful macro). Much more
> capable than the macro-preprocessor in 'c' for unix. Of course, since
> Macro was so powerful, it was complex and there were bugs in it. These
> bugs were expected features for a lot of critical monitor and CUSP
> programs, so the bugs could never be fixed.

*chuckle*

[Grant Taylor]

On 07/15/2018 07:48 AM, Andy Valencia wrote:
> I usually break out teco when I need to do adjustments which span
> line boundaries. I've run into files where name is on one line and
> value on the next:
>
> Joe
> 100
> Sue
> 123
> Sam
> 777

Yep. Been there, done that. I typically end up brute forcing if it's <
10 lines, or recording a macro and replaying the macro. I've not needed
to do it often enough to streamline the process.

There's something to be said for being able to remember how to do
something. ;-)

> And I really want them CSV-ish:
> (zj)
> <0l$i"$l2r$i"$2d$i,$l$.-z;>$$
> ht
> "Joe",100
> "Sue",123
> "Sam",777
>
> Dollars are escapes, I err on the side of breaking up my commands'
> values.

Um… my brain can't unpack that at the moment.

Can I ask for a high level of what each (escaped) command does?

[Grant Taylor]

On 07/14/2018 05:17 PM, Grant Taylor wrote:
> Can I ask that you defend that statement?  What is something that you
> could do in Teco that you can't do in vi or (specifically) vim?

Thank you to everybody that explained and expanded what could be done in
Teco. I've found it quite interesting.

> Many of the things that I do with grep / awk / sed can also be done
> within ed / vi / vim.  I'm just usually not in ed / vi / vim when I need
> to do them, and launching an editor just to do the same functions that
> can be done with grep / awk / sed seems somewhat backwards to me.

Please understand that I'm not trying to push ed / ex / vi / vim. I'm
using / referencing them as the basis of my knowledge of semi-automated
text manipulation.

Thank you again.

[Andy Valencia]

Grant Taylor <gta...@tnetconsulting.net> writes:
> > Joe
> > 100
> > ...

> Can I ask for a high level of what each (escaped) command does?

Jump to top (my bad, dropped a 'z' in there), remember the $'s
are escapes:
j$$


Repeat (forever):
<

Beginning of line:
0l$

Insert opening quote:
i"$

Go to next line, back up two chars (remember, CR-LF line endings),
insert closing quote:
l2r$i"$

Delete that CR-LF (join lines), insert separating ',':
2d$i,$

Go to next line:
l$

By subtracting current position ('.') from last position in file
(well, buffer, handwave), you get a value which will cause ';' to
break the loop once you've reached the final char position, because
';' breaks out of the innermost loop when passed a value >= 0:
.-z;

Until then, the closing '>' causes you to loop again:
>$$

After it runs, you can type the whole buffer (h == 0,z):

ht

"Joe",100
"Sue",123
"Sam",777

Andy

[John Levine]

In article <9776793f-9ef9-4448...@googlegroups.com>,

fishtoprecords <pat2...@gmail.com> wrote:
>The mapping of C from PDP-11 machine instructions is pretty obvious if you look at the early PDP-11
>hardware documentation and your basic K&R
>
>I am pretty sure that one of the early papers also mentions it.

Indeed it does. From Dennis Ritchie's paper "The Development of the C Language"

Thompson went a step further by inventing the ++ and -- operators,
which increment or decrement; their prefix or postfix position
determines whether the alteration occurs before or after noting the
value of the operand. They were not in the earliest versions of B, but
appeared along the way. People often guess that they were created to
use the auto-increment and auto-decrement address modes provided by
the DEC PDP-11 on which C and Unix first became popular. This is
historically impossible, since there was no PDP-11 when B was
developed. The PDP-7, however, did have a few "auto-increment" memory
cells, with the property that an indirect memory reference through
them incremented the cell. This feature probably suggested such
operators to Thompson; the generalization to make them both prefix and
postfix was his own. Indeed, the auto-increment cells were not used
directly in implementation of the operators, and a stronger motivation
for the innovation was probably his observation that the translation
of ++x was smaller than that of x=x+1.

https://www.bell-labs.com/usr/dmr/www/chist.pdf

The myth that the PDP-11 inspired the C ++ and -- operators is
completely false. Can we put it to bed now, please?

[Rich Alderson]

Grant Taylor <gta...@tnetconsulting.net> writes: > On 07/15/2018 12:23 AM, Rob Warnock wrote: >> Remember, the first Emacs was written *in* Teco! > So I've read. Which is impressive to me. As an example, here's the top-level function from the library EINIT which builds a new EMACS from source: !? Generate EMACS:! !? Create EMACS :EJ file from sources. Compresses the source files that need compression, then concatenates the COMPRS files and purifies, writing the result out as EMACS;[PURE] > (on ITS) or EMACS:EMACS.ELIB (on Tops-20).! 1,m.m &_File_PURIFY_Loaded +1"G !* Load PURIFY if not loaded already.! m(m.m Load_Library )EMACS;PURIFY fs osteco m(m.mGenerate_Library ) EMACS;DSK:[PURE]_> EMACS1;DOC USRCOM ! ^R BASE WRDLST INDENT SEARCH FILES ! SUPPRT ISEARC WINDOW BUFFER CRL VARS m(m.mGenerate_Library ) EMACS;DSK:[PRFY]_> EMACS1;PURIFY CCL m(m.m Generate_Library ) EMACS;DSK:EINIT EMACS1;EINIT "# m(m.mGenerate_Library ) EMACS;DSK:EMACS DOC USRCOM ! ^R BASE WRDLST INDENT SEARCH FILES ! SUPPRT ISEARC WINDOW BUFFER CRL VARS m(m.mGenerate_Library ) EMACS;PURIFY PURIFY CCL m(m.m Generate_Library ) EMACS;DSK:EINIT EINIT I don't know why people claim that TECO code is hard to read. Rich Alderson ne...@alderson.users.panix.com Audendum est, et veritas investiganda; quam etiamsi non assequamur, omnino tamen proprius, quam nunc sumus, ad eam perveniemus. --Galen

[Sam Weiner]

In article <5b4e122...@news.dslextreme.com>,

[smw3] National Data Corp bought up a bunch of TOPS-10/20 outfits in
the early 1980s including a couple in the Boston area. After buying
Rapidata, the other systems were moved down to NJ in 1982 to form the
Rapidata division of NDC. In 1986, the whole division was sold to EDS
which moved what remained to Michigan a year or two later but that was
after my time.

[smw3] I don't remember all the outfits but one was Applied Logic
which I think was in Braintree which is a bit more than a few miles
southbound of Waltham. Perhaps that is what you were thinking of?

[smw3] Unless they only had local dialins or used a vendor like
Telenet or Tymnet, most timesharing places created some sort of network.

Sam

[Questor]

On Tue, 17 Jul 2018 21:08:07 -0600, Grant Taylor <gta...@tnetconsulting.net>
wrote:

>On 07/15/2018 12:23 AM, Rob Warnock wrote:
>> Teco commands include conditional (and unconditional) branching, forwards
>> & backwards, so you can easily write long-running programs that process
>> massive amounts of data.
>
>Impressive.
>
>I know of Vimscript. I've never written anything. So I can't speak to
>what it can and can't do. Though it sounds like Teco might best it.
>
>> Remember, the first Emacs was written *in* Teco!
>
>So I've read. Which is impressive to me.

It should be noted that Emacs was written in MIT's ITSTECO, which by that time
was substantially expanded and very different from DEC standard TECO. It's been
a long time since I've looked at the ITSTECO reference; my recollection is that
it had a lot more hooks for error trapping and handling, and many more function
calls for interfacing with the operating system.

Emacs is short for "editing macros," and began as collection of ITSTECO macros
that made editing files easier and more natural, particularly on video displays.
It soon inspired simplified versions at DEC installations written in DEC
standard TECO. Invoking these macros would display the current line while
leaving the cursor at the end of the line. Pressing return would step to the
next line and display it. If you wanted to edit a line, you could use backspace
to delete one character at a time, or control-U to delete the entire line.
Control-O would insert a new blank line. There were some other commands as
well. The effect was to create a kind of WYSIWYG text editor.

[Questor]

On Thu, 19 Jul 2018 02:02:11 +0000 (UTC), wei...@TheWorld.com (Sam Weiner)

wrote:
>In article <5b4e122...@news.dslextreme.com>,
>Questor <use...@only.tnx> wrote:
>>On Tue, 17 Jul 2018 02:05:14 +0000 (UTC), wei...@TheWorld.com (Sam Weiner)
>>wrote:
>>>In article <5b4ce90a...@news.dslextreme.com>,
>>>Questor <use...@only.tnx> wrote:
>>>>On Mon, 16 Jul 2018 02:35:26 +0000 (UTC), wei...@TheWorld.com (Sam Weiner)
>>>>wrote:

No, it was on 128 just south of the Mass Pike, so it was probably in Needham.
Most certainly not as far as Braintree.

[Grant Taylor]

Thank you Andy.

That makes sense as I read along. Though there's no way that I could
currently do that in Teco. I do think that I know just enough to be
able to pull something like that off in vim.

[Grant Taylor]

On 07/19/2018 11:00 AM, Questor wrote:
> Emacs is short for "editing macros," and began as collection of ITSTECO
> macros that made editing files easier and more natural, particularly on
> video displays.

Interesting.

I assume "editing macros" was more a description of what that specific
set of (ITS)TECO macros was used for, namely "editing".

> It soon inspired simplified versions at DEC installations written in
> DEC standard TECO.

That's something between (somewhat) unsurprising and expected to me.

> Invoking these macros would display the current line while leaving
> the cursor at the end of the line. Pressing return would step to the
> next line and display it. If you wanted to edit a line, you could use
> backspace to delete one character at a time, or control-U to delete the
> entire line. Control-O would insert a new blank line. There were some
> other commands as well. The effect was to create a kind of WYSIWYG
> text editor.

Why did you need to press return to display the next line? That almost
sounds like a hold over from print TTYs.

(I briefly tried searching for a video demonstrating TECO on YouTube but
didn't have any luck.)

I feel like WYSIWYG has a bit of a different meaning on fixed character
terminals compared to modern graphical WYSIWYG editors.

[Questor]

On Fri, 20 Jul 2018 17:14:24 -0600, Grant Taylor <gta...@tnetconsulting.net>
wrote:

>On 07/19/2018 11:00 AM, Questor wrote:
>> Emacs is short for "editing macros," and began as collection of ITSTECO
>> macros that made editing files easier and more natural, particularly on
>> video displays.
>
>Interesting.
>
>I assume "editing macros" was more a description of what that specific
>set of (ITS)TECO macros was used for, namely "editing".

Of course TECO was used for editing files, but the macros were meant to make
routine editing easier, as I try to explain below.

>> It soon inspired simplified versions at DEC installations written in
>> DEC standard TECO.
>
>That's something between (somewhat) unsurprising and expected to me.
>
>> Invoking these macros would display the current line while leaving
>> the cursor at the end of the line. Pressing return would step to the
>> next line and display it. If you wanted to edit a line, you could use
>> backspace to delete one character at a time, or control-U to delete the
>> entire line. Control-O would insert a new blank line. There were some
>> other commands as well. The effect was to create a kind of WYSIWYG
>> text editor.
>
>Why did you need to press return to display the next line? That almost
>sounds like a hold over from print TTYs.

Because you might want to edit the current line. Using these macros you would
step through the file line by line by pressing return, and edit lines that
needed to be changed.

Today we're used to seeing the entire file (or at least what fits on the screen)
when we edit with Emacs, Notepad, or even the EDIT program from MS-DOS.
We're also used to simply typing and having any printing characters inserted
into the file at the cursor -- what was once known as "self-inserting."

But that wasn't the case with TECO. It was like the MS-DOS program EDLIN in
that regard. Explicit commands had to be issued to insert, delete, or change
text. Other commands were needed to display the file if you wanted to check
your work.

Emacs, and the other simpler macros it inspired, were the early attempts to make
TECO behave more like today's text editors.

>(I briefly tried searching for a video demonstrating TECO on YouTube but
>didn't have any luck.)

That's an excellent idea. It would be great to have a collection of videos
demonstrating everyday tasks being performed under TOPS-10 and other classic
systems, either on restored hardware or emulators.

>I feel like WYSIWYG has a bit of a different meaning on fixed character
>terminals compared to modern graphical WYSIWYG editors.

I may have stretched the meaning of the term a bit when I used it.

[Stuart Barkley]

On Sun, 15 Jul 2018 at 19:35 -0000, fishtoprecords wrote:

> Stacks on 10s and 20s were fairly small, programs were small. The
> Sparc chips were designed around the stack, so its a very natural
> thing to do.

At least stacks on the PDP-10 knew when they overflowed.

For some reason stacks on Intel based Unix/Linux don't seem to be able
to fully detect overflow in current memory models. Earlier Intel
segment based memory models could detect overflow but those don't play
well with the Unix flat memory model.

The solutions for last years CVE-2017-1000364 seem to just improve
the overflow detection by increasing the size of the unmapped memory
(guard page) from 4KB to 1MB and making stack allocations jump
through other hoops (touching memory at least every 4KB).

See: https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt

Maybe Intel should patch their firmware, like they are doing in
response to Spectre/Meltdown, to implement PDP-10 style stack
registers which can always detect overflow conditions.

Stuart Barkley
--
I've never been lost; I was once bewildered for three days, but never lost!
-- Daniel Boone

[phil....@gmail.com]

On Friday, July 13, 2018 at 5:40:11 PM UTC-4, Stephen M. Jones wrote:
> Has anyone created a definitive timeline for the PDP-6 monitor that
> became TOPS-10...

I just posted this link on another thread:
http://www.ultimate.com/phil/pdp10/tops-10

I'd hardly call it "definitive", I certainly didn't take notes on where the data came from!!

> Does version 2.18 exist? Is 4.5 sources the earliest out there at the
> moment?

The earliest complete version I'm aware of is 3.19, I preserved copies of file from the DECtapes that (I think) Don Mastrovito found at one point when we were at DEC Marlborough in the 80's. ISTR there are separate source directories for full and half-duplex?!!!

Phil