muta...@gmail.com  wrote:   
   > On Wednesday, November 2, 2022 at 6:02:46 AM UTC+8, Joe Monk wrote:   
   > > > When they were giving money to IBM to develop MVS or   
   > > > some precursor (I don't know the details - I just heard   
   > > > that from someone), the US government could have   
   > > > insisted that development be done in C instead of 370 assembler.   
   > > You mean 360 assembler. The 360 OS'es (MFT/MVT) were the precursors to   
   OS/VS.   
   > >   
   > > Now onto the real problem. C hadn't been invented yet.   
   >   
   > Was there a barrier to inventing that, or something near-identical,   
   > in 1955?   
      
   There is trivial prioblem: C wants 8-bit characters, in 1955   
   computers used 6-bit characters.  Note: memory was very expensive   
   in 1955, so adding 33% more memory for 2 extra bits was   
   extramally unattractive.  Later, around 1965 computers got   
   8-bit characters (notably in 360 series), but most peripherials   
   were limited to upper case.  Even later, in 1990 C standard   
   included trigraphs, to allow using C programs on systyms lacking   
   some characters needed by earlier C.  But trigraphs make source   
   hard to read, so you really want support for all characters   
   used by C (essentially printable ASCII).   
      
   Less trivial problem is memory use.  C compiler is not bad when   
   it comes to memory use, but also not the most efficient/spartan   
   one.  Early languages/compilers were designed to be compiled on   
   small system and that were visible at level of language: names   
   had to be short one, 6 characters max was popular, but there   
   were also compilers limiting names to max 3 characters.   
   Official language definition could contain some more general   
   constructs, but compiler could drop anything which compiler   
   aouthors deemed complicated/hard to implement.   
      
   In 1955 you had big trouble convincing users to use something   
   higher level than assembler.  In fact, there were great fuss   
   made distingushing machine language and assembler: machine   
   language was typically in numeric form that could be input   
   into machine with trivial translation (basically convert   
   numbers from external form to internal form used by the   
   machine).  Assembler required character processing and symbol   
   tables, which required scarce memory and computer time.   
   Due to computer resources needed for assemby some people   
   advocated use of machine code in numeric form.  There is   
   a story: von Neumann graduate students created one of   
   first assemblers.  Supposedy when von Neumann heard this   
   he said: how they dare to waste valuable scientific   
   instrument to do work that could be easily done by   
   humans?  That story is probably false, but ilustrates   
   spirit of the time.   
      
   There were higher level languages in 1955, but they generated   
   rather inefficient and big code, probably 10-20 times slower   
   than hand written assembler.  Fortran got it fame and   
   acceptance because compiler generated reasonably efficient   
   code.  But to have compiler of managable size and complexity   
   language was quite limited.   
      
   You may ask why IBM did not create C in 1965?  Well, they   
   did.  Small trouble is that they called it PL/I.  Bigger   
   trouble is that several things are done differently than   
   in actual C.  First trivialites: PL/I uses character set   
   available on IBM 360, taking into account limitations of   
   peripherials (that is usability with upper case only).   
   They used different syntax, that can be easily explained   
   by limitations of caracter set and fact that they wanted   
   to appeal to Fortran and Cobol programmers, so parts of   
   syntax look like Fortran/Cobol and rest is done to match.   
   Several newer languages following C use braces in syntax,   
   but this was not possible in 1965 due to limitation of   
   peripherials.  If you try to point out things that C have   
   and PL/I does not, it hard to do.  One thing is pointer   
   arithmetic, which probably PL/I does not have.  I write   
   "probably" because in PL/I (and also in C) there are   
   "better" ways of doing things which are done using   
   pointer aritmetic and probably in all cases one can get   
   desired effect in PL/I.  Now why "better" in quotes.   
   Well, not using pointer arithmetic gives code which   
   is more readable, it may even optimize better, but   
   when using non-optimizing compiler pointer arithmetic   
   gives faster code.  To say more, some time ago I did   
   a little benchamark: I wrote the same simple code   
   using pointer aritmetic in one version and array   
   indexing in second one.  IIRC, gcc -O2 from both   
   versions gave very similar code which run in 0.5s.   
   gcc -O0 for pointer version gave code needing 0.8s.   
   gcc -O0 for array version gave code needing about 2.5s.   
   So basically, unoptimized array version was 3 times   
   slover than pointer version and 5 times slower than   
   optimized one.  So, optimization gave significant   
   speedup, but unoptimized pointer version was closer   
   to optimized one than to unoptimized array version.   
      
   IIUC early C compiler did not have real optimizer, but   
   generated code slightly better than gcc -O0.  That   
   I think explains eraly claim that "C is fast": if your   
   machine is too small to run optimizing compiler, then   
   carefully coded C can be much faster than other languages   
   which lack similar means.  Beside pointer arithmetic   
   "register" keyword could make big difference on early   
   compilers.  Things like +=, etc also help in getting   
   better code from naive compiler.   
      
   OTOH, users of big 360 had Fortran H.  This was   
   one of first optimizing compiler and I think that it   
   could generate faster code than C compilers available   
   in early seventies.  Certainly it would be hard to   
   sell C to users of Fortran H based on speed of   
   generated code.  Concerning PL/I, big problem was that   
   PL/I had too much.  In particular, PL/I had exceptions   
   and it took some time to learn how to generate good   
   code when exceptions are present.  Anyway, around   
   1975 IBM had its system verision of PL/I, which IIUC   
   allowed object code which was competivie with   
   hand-written assembly.  VM370 contains several assembly   
   files with comment saying that they are output from   
   compiler (and corresponding PL/I-like source), looking   
   a bit at them I can not see anything significantly   
   worse than files which are supposed to be written by   
   hand.  And at some moment IBM got optimizing PL/I   
   compiler (unfortunately, public domain source comtain   
   only non-optimizing PL/I compiler).  Concerning 1965,   
   all "goodies" that were included in PL/I looked like   
   good idea, it took time to appreciate that those   
   "goodies" make implementing compiler much harder,   
   and in particular to appreciate which things interfere   
   with optimization and what to do in such cases.   
   C benefited to some degree from Pascal.  Pascal offered   
   much smaller language than earlier languages, but   
   still getting good coverage for general purpose   
   programming and much simpler implementation.  C dropped   
   few things from Pascal that complicate implementation   
   (nested functions, set types, enumarated types, range   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)