On 2023-07-05 21:21, Rich Alderson wrote:
> gah4 <gah4@u.washington.edu> writes:
>
>> On Monday, July 3, 2023 at 11:35:04=E2=80=AFAM UTC-7, Bill E wrote:
>
>> (snip)
>> So, my questions, what is your favorite text editor and your favorite
>> programming lang for the 10?=20
>> (snip)
>
>> For TOPS-10 in 1976, the choice was TECO or SOS.
>
> When did AMIS come along?

The sources seems to suggest around 1980. I know I started using it in
1983, on a PDP-11, followed by on a -10 later that same year.

> I mention AMIS above. When I began working on Tops-10 systems, I installed
> AMIS, an EMACS clone written in (IIRC) Algol, and not extensible like EMACS.
> After a while, I got comfortable enough with DEC's TECO that I stopped using
> AMIS.

AMIS is written in Pascal. And no, not extensible. But it's still pretty
nice.

> I considered installing FINE ("FINE Is Not EMACS") as well as AMIS, but never
> got around to doing that. My friend Joe Smith was a FINE user.

And Amis stands for "anti-misär", which translated becomes "anti-misery".

Johnny

cross@spitfire.i.gajendra.net (Dan Cross) writes:
> I'd never heard anyone serious refer to `vi` as "vie"
> so I checked in with Mary Ann Horton. She was quite
> explicit that Bill Joy was quite explicit, and that it
> is pronounced "vee eye", not "vye", or "six" (!!), and
> that those pronunciations are wrong.

This certainly matches my experiences in the UC Berkeley backwaters of UC
Santa Cruz (on both PDP-11 and Vaxen). When "vim" appeared its documentation
made it clear that its name was pronounced like "Jim".

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

When I started using 10s in 72 or so, the two choices were teco and sos.
all the serious programmers used teco, but casual users used sos.
By 75 or so, we (First Data) needed something that was easy to use for non-technical people.
We picked up "update" from U Pittsburgh. It was used fairly heavily by our users who were preparing
files for packages like SPSS (also ported by U Pitt), TSP, etc.

At AMS on 20s in 78, 'tv' became popular for folks with VT52 and VT100 terminals. It was just teco with
a pointer /\ where teco's normal pointer was. It was fast enough if you had a 1200 or 2400 baud line.
in the early 80s, we used DEC's LSE (language sensitive editor) that knew about Bliss-36's syntax. But the guys
working in Macro-10 still used teco.

I first ran into vi in 1987 when I was working on an image processing system built on Unix System 7
I still use it, or vim or kvim today.

On Monday, July 3, 2023 at 1:43:43 PM UTC-7, David Bridgham wrote:

(snip)

> One of the things I've long wondered about is if Thompson, Ritchie, and
> the gang had been gotten a PDP-10 like they'd asked for, what would C
> have looked like?

As I understand it, the whole reason for C was the byte addressable PDP-11.

Previous languages, such as B and BCPL, expected word addresses.
Pointer arithmetic was just regular arithmetic.

With a PDP-10, there would be no reason for the C definition of
pointer, and so no need for C.

According to gah4 <gah4@u.washington.edu>:
>As I understand it, the whole reason for C was the byte addressable PDP-11.
>
>Previous languages, such as B and BCPL, expected word addresses.
>Pointer arithmetic was just regular arithmetic.
>
>With a PDP-10, there would be no reason for the C definition of
>pointer, and so no need for C.

Maybe. On a PDP-10, word addresses were just 18 bit halfwords, while byte pointers
were a 36-bit thing with the byte size and offset in the high bits, the address
in the low 18 bits, and rarely used index register and indirect bit in between.

Character handling in B was usually by unpacking characters into a
word array, doing something, and repacking the changes. While you
could do that on a PDP-10, it would be a lot worse than using the
native byte instructions to load and store characters and step through
a character array. The GE 635 also had byte pointers although only for
6 and 9 bits and in a format totally unlike the -10.

He also mentioned floating point, which on the PDP-11 were 32 bits
while ints were 16. B hacked in floats using different operators for
float ops but even on a PDP-10 there are single and double word floats
and handling doubles without double type pointers would be miserable.

So I don't think it would have been all that different.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Thursday, July 6, 2023 at 6:29:07 PM UTC-7, John Levine wrote:
> According to gah4 <ga...@u.washington.edu>:
> >As I understand it, the whole reason for C was the byte addressable PDP-11.
> >
> >Previous languages, such as B and BCPL, expected word addresses.
> >Pointer arithmetic was just regular arithmetic.
> >
> >With a PDP-10, there would be no reason for the C definition of
> >pointer, and so no need for C.

> Maybe. On a PDP-10, word addresses were just 18 bit halfwords, while byte pointers
> were a 36-bit thing with the byte size and offset in the high bits, the address
> in the low 18 bits, and rarely used index register and indirect bit in between.
> Character handling in B was usually by unpacking characters into a
> word array, doing something, and repacking the changes. While you
> could do that on a PDP-10, it would be a lot worse than using the
> native byte instructions to load and store characters and step through
> a character array. The GE 635 also had byte pointers although only for
> 6 and 9 bits and in a format totally unlike the -10.

Reminds me of the IBM 704 (also 36 bits) which reads in cards one row
at a time, into two 36 bit words (ignore columns 73-80).
Then software has to convert that to six bit BCD characters, six
per word.

I suspect, though, that once written and hidden away in a subroutine
somewhere no-one has to look at it again.

Also reminds me of the original DEC Alpha, where memory load/store
are only whole 32 or 64 bit words. Load/store instructions ignore the
low bits, so no need to mask them off. Then byte moving instructions
ignore the high bits, to make that easier.

> He also mentioned floating point, which on the PDP-11 were 32 bits
> while ints were 16. B hacked in floats using different operators for
> float ops but even on a PDP-10 there are single and double word floats
> and handling doubles without double type pointers would be miserable.
> So I don't think it would have been all that different.

I suspect those writing double precision software would be able
to get by with word pointers. Reminds me of what many Fortran programs
did, and probably still do, with EQUIVALENCE and arrays.

But okay, maybe just a little longer.

According to gah4 <gah4@u.washington.edu>:
>Reminds me of the IBM 704 (also 36 bits) which reads in cards one row
>at a time, into two 36 bit words (ignore columns 73-80).
>Then software has to convert that to six bit BCD characters, six
>per word.
>
>I suspect, though, that once written and hidden away in a subroutine
>somewhere no-one has to look at it again.

On the 70x, sure. But the PDP-10 had instructions to do each of these:

r = *p
*p = r
r = *++p
*++p = r

where r was a register and p was a byte pointer that could be either in
memory or a register. (The registers were the first 16 words of memory.)
I wrote a lot of PDP-10 code and I don't ever recall unpacking a string into
an array of words before doing something with it. You used the byte instructions
to process the string in place.

>Also reminds me of the original DEC Alpha, where memory load/store
>are only whole 32 or 64 bit words. Load/store instructions ignore the
>low bits, so no need to mask them off. Then byte moving instructions
>ignore the high bits, to make that easier.

A current thread in comp.arch comments on what a short sighted mistake that was.

>I suspect those writing double precision software would be able
>to get by with word pointers. Reminds me of what many Fortran programs
>did, and probably still do, with EQUIVALENCE and arrays.

The pointers are fine, but the subscript arithmetic, ugh.

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

On 2023-07-07 04:39, gah4 wrote:
> On Thursday, July 6, 2023 at 6:29:07 PM UTC-7, John Levine wrote:
>> According to gah4 <ga...@u.washington.edu>:
>>> As I understand it, the whole reason for C was the byte addressable PDP-11.
>>>
>>> Previous languages, such as B and BCPL, expected word addresses.
>>> Pointer arithmetic was just regular arithmetic.
>>>
>>> With a PDP-10, there would be no reason for the C definition of
>>> pointer, and so no need for C.
>
>> Maybe. On a PDP-10, word addresses were just 18 bit halfwords, while byte pointers
>> were a 36-bit thing with the byte size and offset in the high bits, the address
>> in the low 18 bits, and rarely used index register and indirect bit in between.
>
>> Character handling in B was usually by unpacking characters into a
>> word array, doing something, and repacking the changes. While you
>> could do that on a PDP-10, it would be a lot worse than using the
>> native byte instructions to load and store characters and step through
>> a character array. The GE 635 also had byte pointers although only for
>> 6 and 9 bits and in a format totally unlike the -10.
>
> Reminds me of the IBM 704 (also 36 bits) which reads in cards one row
> at a time, into two 36 bit words (ignore columns 73-80).
> Then software has to convert that to six bit BCD characters, six
> per word.

That don't make sense. A card with 72 colums have 72 characters, not 72
bits.

>> He also mentioned floating point, which on the PDP-11 were 32 bits
>> while ints were 16. B hacked in floats using different operators for
>> float ops but even on a PDP-10 there are single and double word floats
>> and handling doubles without double type pointers would be miserable.
>
>> So I don't think it would have been all that different.
>
>
> I suspect those writing double precision software would be able
> to get by with word pointers. Reminds me of what many Fortran programs
> did, and probably still do, with EQUIVALENCE and arrays.
>
> But okay, maybe just a little longer.

C is more than just B with byte pointers. And dealing with individual
characters in an easy way, including via pointers, is desireable also on
a PDP-10. Look at the C compilers that exist for the PDP-10. They treat
char as 9 bits, and pointers are for that.

Johnny

On Friday, July 7, 2023 at 4:34:12 AM UTC-4, Johnny Billquist wrote:
> On 2023-07-07 04:39, gah4 wrote:
....
> > Reminds me of the IBM 704 (also 36 bits) which reads in cards one row
> > at a time, into two 36 bit words (ignore columns 73-80).
> > Then software has to convert that to six bit BCD characters, six
> > per word.
> That don't make sense. A card with 72 colums have 72 characters, not 72
> bits.

It's an odd reading technique, but a row-at-a-time is handed to the CPU, so it's received as a series of bit arrays.

On Friday, July 7, 2023 at 1:34:12 AM UTC-7, Johnny Billquist wrote:
> On 2023-07-07 04:39, gah4 wrote:

(snip, I wrote)

> > Reminds me of the IBM 704 (also 36 bits) which reads in cards one row
> > at a time, into two 36 bit words (ignore columns 73-80).
> > Then software has to convert that to six bit BCD characters, six
> > per word.

> That don't make sense. A card with 72 colums have 72 characters, not 72
> bits.

I didn't explain it very well.

A card has 12 rows of 80 character positions.
The 704 card reader reads each row into two 36 bit words, ignoring 73-80.
(I believe one can select the actual columns to ignore, but usually 73-80.)

So, the program gets 24 words row-wise, and needs to convert to
characters column-wise. (Six 6-bit BCD characters per word.)

Since the reader didn't read 73-80, the Fortran language, developed
on the 704, was designed to ignore them. A feature that is still in the
standard today, though an alternate input form is available.

Even though the S/360 card readers read all the columns, the IBM utilities,
assemblers, and JCL also ignore 73-80.

I don't know at all how PDP-10 card readers work.

On 2023-07-07 10:54, pbi...@gmail.com wrote:
> On Friday, July 7, 2023 at 4:34:12 AM UTC-4, Johnny Billquist wrote:
>> On 2023-07-07 04:39, gah4 wrote:
> ...
>>> Reminds me of the IBM 704 (also 36 bits) which reads in cards one row
>>> at a time, into two 36 bit words (ignore columns 73-80).
>>> Then software has to convert that to six bit BCD characters, six
>>> per word.
>> That don't make sense. A card with 72 colums have 72 characters, not 72
>> bits.
>
> It's an odd reading technique, but a row-at-a-time is handed to the CPU, so it's received as a series of bit arrays.

Oh! Yuck. That's messy. So the whole decoding is in software, and only
after reading all 10 (12) lines of holes...?

Guess it might have saved a bit on the hardware side...

Johnny

Johnny Billquist <bqt@softjar.se> writes:
>On 2023-07-07 04:39, gah4 wrote:
>> On Thursday, July 6, 2023 at 6:29:07 PM UTC-7, John Levine wrote:
>>> According to gah4 <ga...@u.washington.edu>:
>>>> As I understand it, the whole reason for C was the byte addressable PDP-11.
>>>>
>>>> Previous languages, such as B and BCPL, expected word addresses.
>>>> Pointer arithmetic was just regular arithmetic.
>>>>
>>>> With a PDP-10, there would be no reason for the C definition of
>>>> pointer, and so no need for C.
>>
>>> Maybe. On a PDP-10, word addresses were just 18 bit halfwords, while byte pointers
>>> were a 36-bit thing with the byte size and offset in the high bits, the address
>>> in the low 18 bits, and rarely used index register and indirect bit in between.
>>
>>> Character handling in B was usually by unpacking characters into a
>>> word array, doing something, and repacking the changes. While you
>>> could do that on a PDP-10, it would be a lot worse than using the
>>> native byte instructions to load and store characters and step through
>>> a character array. The GE 635 also had byte pointers although only for
>>> 6 and 9 bits and in a format totally unlike the -10.
>>
>> Reminds me of the IBM 704 (also 36 bits) which reads in cards one row
>> at a time, into two 36 bit words (ignore columns 73-80).
>> Then software has to convert that to six bit BCD characters, six
>> per word.
>
>That don't make sense. A card with 72 colums have 72 characters, not 72
>bits.

Indeed. As each column encodes 12 bits, three columns would be sufficient
for a 36-bit word.

The Burroughs systems used 6-bit characters originally and could encode two
characters per hollerith card column; and later when supporting 8-bit bytes,
could support three bytes using two columns (with the hardware controller
doing the conversion).

According to gah4 <gah4@u.washington.edu>:
>A card has 12 rows of 80 character positions. ...
>The 704 card reader reads each row into two 36 bit words, ignoring 73-80.
>(I believe one can select the actual columns to ignore, but usually 73-80.)

There was an accounting machine plugboard that let you do considerable
rearrangement on the way in although I gather the usual plugboard did what
you said, ignore the last 8 columns. They were usually used for sequence
numbers so if you dropped the deck, you could put it back into order with
a card sorter.

>Even though the S/360 card readers read all the columns, the IBM utilities,
>assemblers, and JCL also ignore 73-80.

The slower S/360 card readers read a column at a time, the fast ones
read rows. They all turned the card code into 80 bytes of EBCDIC in
the controller, presumably with microcode.

>I don't know at all how PDP-10 card readers work.

I never saw a card reader or punch attached to a PDP-10 but the manual at
bitsavers says they worked a column at a time, sending or receivng 12 bit
data. The monitor translated between card code and ASCII.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

While at DEC (first with VAX DEBUG, then VAX FORTRAN, DEC FORTRAN, FORTRAN for RISC, C), I learned emacs. I've been using emacs or an [un]reasonable proximity since. Now that I'm occasionally working on a '10, I'm still using emacs.

On Friday, July 7, 2023 at 4:11:04 AM UTC-7, Johnny Billquist wrote:
> On 2023-07-07 10:54, pbi...@gmail.com wrote:

(snip)
> > It's an odd reading technique, but a row-at-a-time is handed to the CPU,
> > so it's received as a series of bit arrays.

> Oh! Yuck. That's messy. So the whole decoding is in software, and only
> after reading all 10 (12) lines of holes...?
> Guess it might have saved a bit on the hardware side...

IBM is good at reusing things. I suspect they took some existing card
device and converted it.

There is, for example, a duplicating punch that will make a copy of a whole
deck, and that goes a row at a time. (And also has the plugboard, so you
can move columns around.)

As I understand it for the 7090, and maybe the 704, it was more usual to
copy the cards to tape somewhere else, and then carry the tape over.

That avoids the problem.

It appears that gah4 <gah4@u.washington.edu> said:
>As I understand it for the 7090, and maybe the 704, it was more usual to
>copy the cards to tape somewhere else, and then carry the tape over.
>
>That avoids the problem.

Well, it moves it around. Now the card reader and the plugboard are
attached to a 1401 or the like.

I once heard an anecdote about the IBM 7094/7044 DCS, two systems with
a high performance interconnect. The idea was that the slower 7044 did
the spooling and the scheduling while the faster 7094 ran the jobs.
One day they swapped them and the system ran faster.

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

On Friday, July 7, 2023 at 3:20:48 PM UTC-7, John Levine wrote:

(snip)

> I once heard an anecdote about the IBM 7094/7044 DCS, two systems with
> a high performance interconnect. The idea was that the slower 7044 did
> the spooling and the scheduling while the faster 7094 ran the jobs.
> One day they swapped them and the system ran faster.

It seems that floating point, and some other features, are optional on the 7044.

I suppose I would not be surprised if the 7044 was faster for fixed point.

Benchmarking is always strange, and surprises not so rare.

According to gah4 <gah4@u.washington.edu>:
>On Friday, July 7, 2023 at 3:20:48 PM UTC-7, John Levine wrote:
>
>(snip)
>
>> I once heard an anecdote about the IBM 7094/7044 DCS, two systems with
>> a high performance interconnect. The idea was that the slower 7044 did
>> the spooling and the scheduling while the faster 7094 ran the jobs.
>> One day they swapped them and the system ran faster.
>
>It seems that floating point, and some other features, are optional on the 7044.
>
>I suppose I would not be surprised if the 7044 was faster for fixed point.

No, the 7094 was faster than the 7044. But the system was doing more
work scheduling and spooling than it was running "real" programs.

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

On Friday, July 7, 2023 at 7:17:12 PM UTC-7, John Levine wrote:
> According to gah4 <ga...@u.washington.edu>:
> >On Friday, July 7, 2023 at 3:20:48 PM UTC-7, John Levine wrote:
> >
> >(snip)
> >
> >> I once heard an anecdote about the IBM 7094/7044 DCS, two systems with
> >> a high performance interconnect. The idea was that the slower 7044 did
> >> the spooling and the scheduling while the faster 7094 ran the jobs.
> >> One day they swapped them and the system ran faster.
> >
> >It seems that floating point, and some other features, are optional on the 7044.
> >
> >I suppose I would not be surprised if the 7044 was faster for fixed point.
> No, the 7094 was faster than the 7044. But the system was doing more
> work scheduling and spooling than it was running "real" programs.

Oh, that, too.

Sometimes things are optimized for a large scale, and not for small scale.

That is what got us WATFOR and WATFIV, when the IBM compilers and
linker had so much overhead for small programs.

Though I did used to use WATFIV for large programs, when they needed
debugging such as array bounds and undefined variables.

For the 7094, you are supposed to run large programs that don't do much I/O,
and do lots of floating point number crunching.

But yes, spooling is always tricky.

John Levine wrote:
>>> The first versions of C ran on a GE 635
>>I haven't seen that claimed before. Can you expand on that?
>
> I found Dennis Ritchie's history of C paper and I somewhat
> misremembered. B ran on the PDP-7, but Dennis made a cross compiler to
> the 635, and there were C compilers targeting the 635 and S/370 by
> 1973, while C was still embryonic.
>
> https://www.bell-labs.com/usr/dmr/www/chist.html

Thanks for clearing that up!

According to gah4 <gah4@u.washington.edu>:
>Sometimes things are optimized for a large scale, and not for small scale.
>
>That is what got us WATFOR and WATFIV, when the IBM compilers and
>linker had so much overhead for small programs.

They kept rediscovering that over and over. The original Fortran
compiler produced fantastic code, to disprove claims from
self-interested assembly programmers that compiled code would never be
fast enough. At some point they added an option to skip optimizations
and compile faster for debugging, and of course a lot of people used
it in their production programs because it was fast enough.

S/360 had Fortran G which produced terrible code and Fortran H which
compiled a lot slower and produced excellent code. But most people used
Fortran G. Then WATFOR came along and as I recall its code was at least
as good as Fortran G, with the main limit being program size and the
ability to use assembler libraries.

Fun fact: Fortran G and the old DEC F40 Fortran used the same front
end, written in some kind of metalanguage. The later Fortran-10 was a
new product and produced considerably better code.

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

On Saturday, July 8, 2023 at 11:50:48 AM UTC-7, John Levine wrote:

(snip on WATFIV and fast compilers)

> S/360 had Fortran G which produced terrible code and Fortran H which
> compiled a lot slower and produced excellent code. But most people used
> Fortran G. Then WATFOR came along and as I recall its code was at least
> as good as Fortran G, with the main limit being program size and the
> ability to use assembler libraries.
Well, WATFIV does bounds check for all array access, and undefined
value (assuming the value is all X'81') for all variable access. That
probably slows it down a little, but speeds up debugging!

I don't remember asking, but I remember more people using Fortran H.

For one, with MVT people were encouraged to always use REGION=300K
to reduce fragmentation. If you do that, might as well use H.

> Fun fact: Fortran G and the old DEC F40 Fortran used the same front
> end, written in some kind of metalanguage. The later Fortran-10 was a
> new product and produced considerably better code.

About the time I was using a PDP-10 and Fortran-10, I had the source
listing for Fortran G. (On microfiche, as one machine I used had a
microfiche printer.) I remember being surprised at what it looked like.

I also remember knowing about F40, but not using it.

Johnny Billquist <bqt@softjar.se> wrote:
: On 2023-07-07 04:39, gah4 wrote:

: That don't make sense. A card with 72 colums have 72 characters, not 72
: bits.

Back in the dark ages object files were also stored on cards, so 2
36-bit words per row made some sense.

Other venders, including the PDP-10, used 3 12-bit columns, but you
still had to read all the bits and convert to the character encoding if
that's what you wanted.

Except for a system the USAF designed that used 12 bit characters, on
GE-6x5 hardware.

John Levine <johnl@taugh.com> wrote:

: Fun fact: Fortran G and the old DEC F40 Fortran used the same front
: end, written in some kind of metalanguage. The later Fortran-10 was a
: new product and produced considerably better code.

Originally writen by Digitek. The metalanguage was an assembler for a
"POP" machine, so you could port it by writiing an interpreter
for the POP machine. So they sold it to every small hardware
vendor, including DEC for F4 on the PDP-6. Then they tried to do the
same for PL/1 and went bust. The refugees startd Ryan-MacFarland.

IBM had more memory to play with so they expanded it as macros.

sarr.blumson@alum.dartmouth.org writes:
>Johnny Billquist <bqt@softjar.se> wrote:
>: On 2023-07-07 04:39, gah4 wrote:
>
>: That don't make sense. A card with 72 colums have 72 characters, not 72
>: bits.
>
>Back in the dark ages object files were also stored on cards, so 2
>36-bit words per row made some sense.

In the days of 6-bit characters, two would be stored per column.

However, it was best to design binary encoding on a card in such a
way as to ensure that there was sufficient card remaining after
punching to ensure safe passage through the reader (e.g. lace cards),
even if it meant not utilizing the full capacity of the card.

https://en.wikipedia.org/wiki/Lace_card