A doubly linked-list in C

[luserXtrog]

Hollywood does not do anything but fiction, what does fiction have to do with
history?  Nothing.  Stop thinking of Hollywood recording history and you will be
fine.

Too true; even from sources purportedly interested in accurate
presentations. I've yet to see a program on Egypt that doesn't
naively attribute the Sphinx to Chephren.

 

[Richard Tobin]

Hollywood does not do anything but fiction, what does fiction have to
do with history? Nothing. Stop thinking of Hollywood recording
history and you will be fine.

No, to be "fine" you would need to stop others interpreting it as
history too. Biased rewritings of history are not without
consequences, whether or not they excuse themselves as fiction.

-- Richard

 

[Gordon Sande]

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.

Thanks. I was aware of the PL/I but not the relative amount.

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.

I expect that their PL/I had relatively little IO (as it was in the kernel)
and otherwise looked much like the language in the Data Proc. So they were
only using a more portable subset which was to their advantage.

 

[nmm1]

Thanks. I was aware of the PL/I but not the relative amount.

That figure is from memory, so may be wrong! It was the bulk of it,
in terms of line count, though. That is a bit deceptive, because
many of the most important features were in Assembler.

I expect that their PL/I had relatively little IO (as it was in the kernel)
and otherwise looked much like the language in the Data Proc. So they were
only using a more portable subset which was to their advantage.

Yes, to both - but they STILL said they couldn't port it!


Regards,
Nick Maclaren.

 

[Peter Flass]

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.

Fred Brooks has a lot to say about the OS/360 linker in _The Mythical
Man-Month_.

 

[nmm1]

Fred Brooks has a lot to say about the OS/360 linker in _The Mythical
Man-Month_.

The linker had only one major performance defect - its symbol lookup
was a linear search. That (obviously) affected only large programs,
and would have been trivial to fix - I drafted the code once, but it
wasn't an important enough matter for us to modify the linker.

Its real problem was I/O time, and that was a constraint of the load
module format. If it had used the same tricks as program fetch, it
could have handled even that efficiently, but those tricks were truly
horrible. Basically, that was a hangover from minimising memory on
the very early System/360s.


Regards,
Nick Maclaren.

 

[John W Kennedy]

The linker had only one major performance defect - its symbol lookup
was a linear search. That (obviously) affected only large programs,
and would have been trivial to fix - I drafted the code once, but it
wasn't an important enough matter for us to modify the linker.

Its real problem was I/O time, and that was a constraint of the load
module format. If it had used the same tricks as program fetch, it
could have handled even that efficiently, but those tricks were truly
horrible. Basically, that was a hangover from minimising memory on
the very early System/360s.

Yeah. I wrote, in assembler, the equivalent of a QPAM access method, and
then I wrote, in PL/I, a delinkeditor that ran at about 95% of the
instantaneous I/O rate of the disk. I was toying with the idea of
writing a replacement linker with the same overall design, but then the
all-new linker with PDSE and long-name support, etc., came out.

But I achieved that speed by throwing a /lot/ of memory at the problem.

 

[Franken Sense]

In Dread Ink, the Grave Hand of (e-mail address removed) Did Inscribe:

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.

You seem to agree with me about texas insecurity, which is refreshing. It
would make my day if El Paso were in another country.

Do you have an opinion on F?
--
Frank

If [Stuart Saves His Family] had actually been successful it would have
been a lot better teacher for me than the failure that it was, because it
would have given me the opportunity to do more movies,
~~ Al Franken, CNN interview

 

[nmm1]

You seem to agree with me about texas insecurity, which is refreshing. It
would make my day if El Paso were in another country.

My day is made

Do you have an opinion on F?

Not really. I looked at it and, while it had some good principles,
it seemed to throw the baby out with the bathwater.

It is EXTREMELY hard to produce a subset of any design that is any
use - it is almost always simpler to produce a new design.


Regards,
Nick Maclaren.

 

[Franken Sense]

In Dread Ink, the Grave Hand of Keith Thompson Did Inscribe:

[snip]

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

No, not really. The lingua franca can't be secessionist.

 

[Dik T. Winter]

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

I think it was already earlier that CDC started to implement their
compilers in IMPL, a derivate of JOVIAL. The reason they wrote the
Algol 68 compiler in IMPL was because there was already a complete
code generator in that language, written for other compilers.

 

[Dik T. Winter]

>
> 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.

Europe was a bit larger than only the UK. ICL may have been small compared
to IBM, but the different computer industries together in Europe were
comparable. No PL/I there.

 

[nmm1]

Europe was a bit larger than only the UK. ICL may have been small compared
to IBM, but the different computer industries together in Europe were
comparable. No PL/I there.

Quite. And, at the relevant time, ICL was small only by comparison
with IBM - it was bigger than most (all?) of the Seven Dwarfs. Yes,
it shrank in importance later.


Regards,
Nick Maclaren.

 

[nmm1]

...

I think it was already earlier that CDC started to implement their
compilers in IMPL, a derivate of JOVIAL. The reason they wrote the
Algol 68 compiler in IMPL was because there was already a complete
code generator in that language, written for other compilers.

Ah. Then I apologise to CDC



Regards,
Nick Maclaren.

 

[Bill Buckels]

And, at the relevant time, ICL was small only by comparison with IBM

When we began selling our MS-DOS POS system to ICL/Fujitsu back in the late
'80's - early 90's ICL Europe was bigger in Micros than IBM Europe or so I
was told. Strangely they were also into OS2 in a big way a short time
later... then after drinking some Bundy rum from ICL/Fujitsu in Australia a
couple of years later they seemed to have vanished... I heard from Fujitsu
in Singapore a year or two after that... haven't heard anything since the
'90's other than that. I guess my old device drivers are likely not in use
anymore. They were written in C and assembler and not PL/I anyway.

 

[robin]

My day is made


Not really. I looked at it and, while it had some good principles,
it seemed to throw the baby out with the bathwater.

It's a very useful subset that removes the error-prone constructs of Fortran.

 

[Donald L. Dobbs]

In its heyday, the CDC 6600 & 7600 Fortran compilers were written in
assembler. I know because the (now retired) maintenance programmer of
those compilers is a personal friend. One evening I was invited to
the CDC facility in Silicon Valley (not Minneapolis) where the
maintenance work was done, to witness the process. About 8,000 punch
cards were read into a peripheral device (CDC 1600/1700???) which in
turn transferred the file to a 6600 that was used as an I/O device and
scheduler to the 7600. In less than one second the 7600 had done the
assembly and the listing started pouring out of a line printer. If CDC
switched to IMPL for Fortran that would have come much later. Having
only been exposed to S/360 shops up until that time I was completely
blown away by the shear speed of CDC's high-end offerings.