Re: [Lit.] Buffer overruns

From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 03/16/05 

Date: Wed, 16 Mar 2005 08:01:46 -0700

jmfbahciv@aol.com writes:
> What I would you to speculate about is: If PLI had been distributed
> as freely and widely as C would the oodles of code still be "buffer
> safe"? I've only met PLI once and that was in the form of the cards
> I punched for the guy who wrote the code 37 years ago so I don't
> remember much. PLI never got popular because it was a PITA to use.
> In my area one had to drive from Kalamazoo to Ann Arbor, submit the
> card deck, and then drive back with the results because a user was
> only allowed one run/visit.

the upfront learning curve tended to be higher and the full PLI
(at least IBM) tended to be much larger. however there were various
PLI subsets that were used at universities.

i would assert that a number of things were going on, at least by the
early 80s.

ibm mainframes and software minimum configurations were fairly large
(not easy to justify incremental installations at universities,
a least by comparison to some alternatives)

ibm's education discount was significantly reduced (especially in
comparison to what they had been in the 60s)

there weren't a lot of freely available, easily portable PLI
compilers

the environment for the ibm pli compilers; operating systems, etc were
proprietary and not portable

a number of new hardware vendors were starting to appear with
relatively inexpensive computing offerings, smaller minis,
workstations, etc. the past model of a vendor building both
proprietary hardware and operating systems from scratch was difficult
to apply (i.e. a full-blown proprietary operating system from scratch
would be significantly more than the whole vendor hardware effort).

a demand was emerging for entry level, relatively portable, relatively
non-proprietary operating system and programming envrionment at
universities and the vendors of these new emerging class of hardware
computing products.

i had put together a proposal in the 82/83 time-frame to address most
of these issues ... but it became involved in large corporation
politics and got way too much attention and one characterization would
be that it reached (blackhole) critical mass and imploded. there was
some study of various (portable?) languages that could be used for
operating system implementation and their associated integrity
characteristics. I did a couple demos of taking existing kernel
components (implemented in assembler) and redesigning and recoding
them from scratch in (enhanced) pascal.

a few postings on one such activity:
http://www.garlic.com/~lynn/2000b.html#43 Migrating pages from a paging device (was Re: removal of paging device)
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2003b.html#33 dasd full cylinder transfer (long post warning)
http://www.garlic.com/~lynn/2003k.html#26 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2003k.html#63 SPXTAPE status from REXX
http://www.garlic.com/~lynn/2004g.html#19 HERCULES
http://www.garlic.com/~lynn/2004p.html#3 History of C
http://www.garlic.com/~lynn/2005d.html#38 Thou shalt have no other gods before the ANSI C standard

this somewhat overlapped the fort knox/801 period where a variety
of custom microprocessors (used in controllers, devices, low-end
370s, various system/xxs) would be replaced with 801 with common
pl.8 programming language (supposedly pl.8 comes from it being
80 percent of pli).
http://www.garlic.com/~lynn/subtopic.html#801

the low-end 370s would have had an 801 microprocessor with the 370
microcode implemented (mostly) in pl.8 ... but suffering the
traditional 10:1 instruction ratio (10 microprocessor instructions for
every 370 instruction). there was also starting to appear small
chipsets that implemented 370 directly in silicon (avoiding a lot of
the 10:1 mip ratio degradation). I had proposed uniform board design
with (relatively) large collections (primary limiting factor were
cooling constraints) of such computer boards could be packaged in
drawers and racks (mixing 370 boards, 801 boards, memory boards).
this was envisioned to be an mixture of shared-memory (aka
tightly-coupled) multiprocessing and loosely-coupled/cluster
operation ... aka a real early precursor to GRID. the idea was
to take most cost effective components and be able to replicate
them in large numbers. minor ref with some drift:
http://www.garlic.com/~lynn/95.html#13

i envisioned making a transition period from 370 assembler based
infrastructures to pl.8/pascal implementations running natively (at
significant higher mip rate) directly on 801s. part of this could be
directly implementing operating system feature/function from scratch
... and part incremental transition involving translating native 370
assembler to higher level code and then compiling back down to native
801. for instance, i've posting before about a pli program that i had
written in the early 70s that processed 370 assembler listings, built
abstract representation of the program, did detailed code flow and
register use analysis ... and could spit out higher level abstract
representation of the program.

misc. past postings on assembler analysis:
http://www.garlic.com/~lynn/94.html#12 360 "OS" & "TSS" assemblers
http://www.garlic.com/~lynn/2000d.html#36 Assembly language formatting on IBM systems
http://www.garlic.com/~lynn/2001j.html#6 Losing our culture.
http://www.garlic.com/~lynn/2001l.html#24 mainframe question
http://www.garlic.com/~lynn/2002k.html#38 GOTOs cross-posting
http://www.garlic.com/~lynn/2003n.html#34 Macros and base register question
http://www.garlic.com/~lynn/2004d.html#21 REXX still going strong after 25 years
http://www.garlic.com/~lynn/2004i.html#12 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004k.html#36 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004m.html#35 Shipwrecks
http://www.garlic.com/~lynn/2005b.html#16 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#17 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#28 Relocating application architecture and compiler support 

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/