A doubly linked-list in C

[robin]

I remember seeing a notice in my college computer center "Do not use
FORTRAN H until further notice.", and I graduated in January of 1968.

Probably because H was core hungry -- it needed 256K IIRC,
whereas E and G required half that or less.

 

[robin]

One thing that most people learn is that flexibility comes at a cost.
The cost almost always includes increased difficulty of debugging and
increased cost/difficulty of implementation, and very often worse
performance. PL/I had all of those problems, badly, as everyone who
had the relevant experience can witness.


The mind boggles. Almost every system had a Fortran 66 compiler,
but not more than one in ten had a PL/I compiler - and the dialects
they accepted were all very different. The latter was because most
non-IBM vendors omitted many of the features to reduce the cost of
implementing it.

PL/I was available from the major players -
- IBM (F and DOS, the latter being a subset).
- Burroughs
- CDC
- Data General
- Honeywell
- UNIVAC
- DEC
That looks like 7/7 to me.

There was a common language among those implementations
[apart from the DEC].
It was certainly easy to write portable code that would compile
under any of them.

You would know that if you have been in the game of writing truly
portable applications - I was, and my code has been run on hundreds
of (different) systems over several decades.

So has mine.

True, but not as much as PL/I

What major vendor is supporting Algol 68?

 

[robin]

Once it settled down, it wasn't a bad language, but with some EVIL
"gotchas" - very like Algol 68, but starting from the exactly
opposite approach to design The things that killed it were its
lack of portability and poor performance

PL/I codes were very portable.
It was more portable than other languages, because
it wasn't necessary to write assembly codes to fill in
what the language couldn't do.

As for performance, that was good.
What users familiar with FORTRAN didn't take into account
was that PL/I codes contained their subroutines and functions,
whereas FORTRAN subroutines and functions were separate
compilations.
Codes with nested procedures took longer to compile than
without.

As regards run-time speed -- again, what was not understood
was the fact that PL/I arrays were (still are) dynamic, and thus
there was an overhead in allocating storage on procedure entry
(and de-allocating it on exit).

FORTRAN didn't have those overheads except at program start.
But then, FORTRAN codes weren't true algorithms, because array
sizes were hard wired. That limitation meant that tricks had to be
resorted to to try to overcome that deficiency, such as "adjustable
dimensions" and EQUIVALENCE.

What PL/I offered was the ability to run programs having large
arrays that wouldn't run in FORTRAN. By making use of
a number of BEGIN blocks (or CONTROLLED storage)
temporary and local arrays could be allocated and freed as required.
In this manner, the codes could be run in small core machines.

As to performance: there was a matrix scheme that took 1 to 2 seconds per job
compared to 75 seconds with anything else.
It was written in PL/I.

These were just a few of the issues of the time.

 

[Tony]

arnuld wrote:
[something about a simple data structure and has garnered way too many posts
(?).. Are developers bored? Indication of C as a first-interest historical
language?]

WTF is the issue? The reserve space shuttle is potentially compromised
because of linked-list ADT "physics"?

 

[nmm1]

PL/I was available from the major players -
- IBM (F and DOS, the latter being a subset).
- Burroughs
- CDC
- Data General
- Honeywell
- UNIVAC
- DEC
That looks like 7/7 to me.

You have a deluded idea of both what the major players were and what
a non-hobbyist means by "available". At the relevant time, ICL was
larger and MUCH more important than most of those, and several other
non-USA companies were comparable. Also, a quick gurgle brings up the
following amusing page:

http://www.archive.org/stream/preliminaryrepor00abra/preliminaryrepor00abra_djvu.txt

Salient points include "operational since 1972" and "Features Not Yet
Implemented", which include I/O and arithmetic types!

Yes, by the late 1970s, there were a fair number of implementations.
But, by then, most of the names you mention were clearly on the way
out, and even IBM had admitted defeat over PL/I. The relevant period
is 1965-1975.

If you can provide independent evidence that there was a functional,
supported and usable PL/I compiler for all of those available by (say)
1972, I will apologise to you. Web references will do - provided that
they are independent and plausibly authoritative.


Regards,
Nick Maclaren.

 

[Kevin G. Rhoads]

As for writing the PL/I-F compiler in assembler,

all IBM's compilers at the time were done in assembler, AFAIK.

At that time, nearly all compilers were written in assembler.
The idea of writing a compiler in an HLL was radical, a few
people were trying it. But in the late 60s and early 70s
compilers in HLL were still literally "avante garde".
That changed rather abruptly over the next decade.

But the use of anything other than assembly for system
stuff, compilers and utilities was just not a widespread
or accepted idea in the 60s.

 

[nmm1]

At that time, nearly all compilers were written in assembler.
The idea of writing a compiler in an HLL was radical, a few
people were trying it. But in the late 60s and early 70s
compilers in HLL were still literally "avante garde".
That changed rather abruptly over the next decade.

But the use of anything other than assembly for system
stuff, compilers and utilities was just not a widespread
or accepted idea in the 60s.

That's seriously overstated, and even false. Other languages were
widely used (including LISP, ALGOL, BCPL and more), and the idea
of writing compilers and utilities was already regarded as outmoded
in many communities by the late 1960s.

However, that change of mindset didn't hit the IBM-dominated area
(including CDC, in this context) until the late 1970s, as you say.


Regards,
Nick Maclaren.

 

[Peter Flass]

You have a deluded idea of both what the major players were and what
a non-hobbyist means by "available". At the relevant time, ICL was
larger and MUCH more important than most of those,

Depends on your POV. ICL never got a foothold in the US, although they
tried. Too bad, since they had some interesting stuff, but from A US
POV, they were definitely not *important." Don't forget the US had the
lion's share of the world's computers then.

and several other

non-USA companies were comparable. Also, a quick gurgle brings up the
following amusing page:

http://www.archive.org/stream/preliminaryrepor00abra/preliminaryrepor00abra_djvu.txt

Salient points include "operational since 1972" and "Features Not Yet
Implemented", which include I/O and arithmetic types!

Interesting link, but CIMS PL/I was a student PL, along the lines of
PL/C, PLUM, PLUTO, etc.

 

[nmm1]

Depends on your POV. ICL never got a foothold in the US, although they
tried. Too bad, since they had some interesting stuff, but from A US
POV, they were definitely not *important." Don't forget the US had the
lion's share of the world's computers then.

That is precisely what it didn't have. It had the majority, but NOT
even the vast majority, let alone the lion's share.

Hollywood is notorious for rewriting history to inflate the USA's
importance, but please don't follow its path.

Interesting link, but CIMS PL/I was a student PL, along the lines of
PL/C, PLUM, PLUTO, etc.

Precisely. And I think that you will find that it was the only PL/I
available on CDCs during the relevant period.


Regards,
Nick Maclaren.

 

[Peter Flass]

That is precisely what it didn't have. It had the majority, but NOT
even the vast majority, let alone the lion's share.

Hollywood is notorious for rewriting history to inflate the USA's
importance, but please don't follow its path.


Precisely. And I think that you will find that it was the only PL/I
available on CDCs during the relevant period.

I believe you were talking about the early 70's. Apparent;y CDC had a
PL/I compiler, but somewhat later, around 1979:

http://bitsavers.vt100.net/pdf/cdc/6x00/instant/60483700A_PL1_Ver_1_Instant_Nov79.pdf

Of the rest, I don't know about Univac, I won't count PLUM. Everyone
else on the list had PL/I, but again I'm not sure about dates.
Honeywell (Multics) was quite early. Dec had an excellent compiler for
VAXen which, in fact, was spun off by Compaq and is still actively
marketed, most recently ported to Itanium. There was also a
conversational PL/I for DEC-10. DG had a good Subset-G compiler for
Eclipse, and Burroughs also had a compiler, I believe for 6600's, but
pushed their ALGOL much more heavily.

 

[robin]

At that time, nearly all compilers were written in assembler.

I seem to recall that all the compilers of Burroughs 5000 series
were written in Algol (1963?).
I see from the XPL book that it (XPL) appeared on the B5500.

The idea of writing a compiler in an HLL was radical, a few
people were trying it. But in the late 60s and early 70s
compilers in HLL were still literally "avante garde".

The XPL system was available by about 1968 on the S/360,
and the text "A Compiler Generator" (XPL system) was published in 1970.

 

[robin]

You have a deluded idea of both what the major players were and what
a non-hobbyist means by "available". At the relevant time, ICL was
larger and MUCH more important than most of those, and several other
non-USA companies were comparable. Also, a quick gurgle brings up the
following amusing page:

http://www.archive.org/stream/preliminaryrepor00abra/preliminaryrepor00abra_djvu.txt

Salient points include "operational since 1972" and "Features Not Yet
Implemented", which include I/O and arithmetic types!

Yes, by the late 1970s, there were a fair number of implementations.
But, by then, most of the names you mention were clearly on the way
out,

You're being absurd. Those name were prominent in the 1970s.

and even IBM had admitted defeat over PL/I.

They hadn't admitted anything. They were still upgrading their
PL/I compilers and released new ones in the 1970s (e.g., Series/1 PL/I).
and thru the 80s and beyond.
You may recall that IBM iself released its Optimising and checkout compilers
c. 1970.

 

[robin]

That is precisely what it didn't have. It had the majority, but NOT
even the vast majority, let alone the lion's share.

IBM was installing computers by the thousands, while ICL
and other British computer mfrs were installing by the tens,
hundreds. The population in the US (and hence the market) was greatly
larger than in the UK.

The Brits lost the lead that they had by the 1950s with the first
stored program computer. That lead was lost by the late 1960s
as a result of the do-good government forcing amalgamations on the
various mfrs, thus stifling competition.

Hollywood is notorious for rewriting history to inflate the USA's
importance, but please don't follow its path.

The USA does not need its history rewriting.

Precisely. And I think that you will find that it was the only PL/I
available on CDCs during the relevant period.

CDC had its PL/I on the 6000 and Cyber 70.

 

[robin]

I believe you were talking about the early 70's. Apparent;y CDC had a
PL/I compiler, but somewhat later, around 1979:

Even earlier.

 

[Keith Thompson]

[snip]

I wonder if you folks would consider dropping comp.lang.c from the
Newsgroups: line. Thanks.

 

[nmm1]

I believe you were talking about the early 70's. Apparent;y CDC had a
PL/I compiler, but somewhat later, around 1979:

Late 1960s and early 1970s. IBM had started to abandon its "PL/I will
replace everything campaign" by 1975, and it was dead by 1979.

Of the rest, I don't know about Univac, I won't count PLUM. Everyone
else on the list had PL/I, but again I'm not sure about dates.

Because of what I said above, the dates are critical. During the
relevant period, the ONLY languages that were reasonably portable
were COBOL and FORTRAN. Everybody had a LISP, but they were all
different. Almost everybody had an ALGOL, but that had no I/O and
many were joke implementations.

That is why a lot of people here wrote portable applications in
BCPL - it was easier to port the compiler than to port between two
implementations of the same language. Yes, really. An amusing
C-relevant footnote is that there is some evidence that C is going
back to that ....


Regards,
Nick Maclaren.

 

[nmm1]

The USA does not need its history rewriting.

No, it doesn't, but it seems addicted to it. The root cause is almost
certainly insecurity, which also explains certain worse misbehaviours.


Regards,
Nick Maclaren.

 

[Gordon Sande]

Late 1960s and early 1970s. IBM had started to abandon its "PL/I will
replace everything campaign" by 1975, and it was dead by 1979.


Because of what I said above, the dates are critical. During the
relevant period, the ONLY languages that were reasonably portable
were COBOL and FORTRAN. Everybody had a LISP, but they were all
different. Almost everybody had an ALGOL, but that had no I/O and
many were joke implementations.

That is why a lot of people here wrote portable applications in
BCPL - it was easier to port the compiler than to port between two
implementations of the same language. Yes, really. An amusing
C-relevant footnote is that there is some evidence that C is going
back to that ....

I repeatedly heard the story that when SAS did their rewrite into C
(from 360 assembly) they bought a C compiler company as it would be
easier to port the compiler (and leave SAS alone) than it would be to
port SAS to various Cs. That ws an earlier time for C and C for 360s
was not really a popular option then.

 

[robin]

No, "H" came later, around 1967 IIRC, and it was initially pretty buggy.

It required 256K to compile, which is why we couldn't run it
initially. When we had sufficient memory, and could use it,
we did not find any issues with it.

It could be fairly slow. It was very sensitive to the amount of memory
it had to run in.

I have timing figures from those days, and compilation times were
comparable to Fortran. As I said, it was the linker where additional time
was taken.

 

[nmm1]

I repeatedly heard the story that when SAS did their rewrite into C
(from 360 assembly) they bought a C compiler company as it would be
easier to port the compiler (and leave SAS alone) than it would be to
port SAS to various Cs. That ws an earlier time for C and C for 360s
was not really a popular option then.

That is true, except for one thing: only the SAS 'kernel' was in
Assembler (VERY nasty Assembler, too!), but the vast bulk of the
code (80-90%) was in PL/I.

I know that their customers repeatedly asked them to port it to
various other systems, but SAS always claimed that it was infeasible.
As far as I could see, there was nothing particularly horrible about
the PL/I, which may indicate something about the portability of that
language.


Regards,
Nick Maclaren.