[TUHS] Algol68 vs. C at Bell Labs

[TUHS] Algol68 vs. C at Bell Labs

[Noel Chiappa]

    > From: scj at yaccman.com

    > I think one fatal mistake that A68 made

One of many, apparently, given Hoare's incredible classic "The Emperor's Old
Clothes":

   http://zoo.cs.yale.edu/classes/cs422/2014/bib/hoare81emperor.pdf

(which should be required reading for every CS student).

       Noel

[TUHS] Algol68 vs. C at Bell Labs

[William Cheswick]

I assumed by 1980 that Rule 1 (program security) was an obvious given. Alas, no.

> On 30Jun 2016, at 9:44 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> 
> One of many, apparently, given Hoare's incredible classic "The Emperor's Old
> Clothes":
> 
>   http://zoo.cs.yale.edu/classes/cs422/2014/bib/hoare81emperor.pdf
> 
> (which should be required reading for every CS student).
> 
>       Noel

[TUHS] 68000 vs. 8086 ( was Algol68 vs. C at Bell Labs)

[scj]

My memory was that the 68000 gave the 8086 a pretty good run for its
money, but when Moto came out with a memory management chip it had some
severe flaws that made paging and fault recovery impossible, while the
equivalent features available on the 8086 line were tolerable.  There were
some bizarre attempts to page with the 68000 (I remember one product that
had two 68000 chips, one of which was solely to sit on the shoulder of the
other and remember enough information to respond to faults!).  By the time
Moto fixed it, the 8086 had taken the field...

I got a lot more respect for the 8086 architecture when working at
Transmeta.  The instruction set encoding means that programs are small,
and that means that, for a given icache size, the cache hit rate was much
better than for our (wide word) machine.  By the time we had upped the
size of our caches, the increased area and cost made our chip much less
competitive.

[TUHS] 68000 vs. 8086 ( was Algol68 vs. C at Bell Labs)

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1372 bytes --]

scj at yaccman.com wrote:

> My memory was that the 68000 gave the 8086 a pretty good run for its
> money, but when Moto came out with a memory management chip it had some
> severe flaws that made paging and fault recovery impossible, while the
> equivalent features available on the 8086 line were tolerable.  There were
> some bizarre attempts to page with the 68000 (I remember one product that
> had two 68000 chips, one of which was solely to sit on the shoulder of the
> other and remember enough information to respond to faults!).  By the time
> Moto fixed it, the 8086 had taken the field...

The 68451 did exist early. We had a "ExorMax" development system with the MMU 
that we used to develop our UNOS derivate "VBERTOS" before we had our own 
hardware.

The design bug in the mc68000 was that the execption stack did not contain the 
complete microcode state for things like "*p++" and thus was not restartable at 
the same state.

The ideas using two 68000 did put the main CPU into halt (from wehre it could 
be restarted) and did only run the exception handling code on the second CPU.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'

[TUHS] 68000 vs. 8086 ( was Algol68 vs. C at Bell Labs)

[Dan Cross]

On Thu, Jun 30, 2016 at 1:17 PM, <scj at yaccman.com> wrote:

> My memory was that the 68000 gave the 8086 a pretty good run for its
> money, but when Moto came out with a memory management chip it had some
> severe flaws that made paging and fault recovery impossible, while the
> equivalent features available on the 8086 line were tolerable.  There were
> some bizarre attempts to page with the 68000 (I remember one product that
> had two 68000 chips, one of which was solely to sit on the shoulder of the
> other and remember enough information to respond to faults!).  By the time
> Moto fixed it, the 8086 had taken the field...
>

Brantley Coile mentioned this here a couple of years ago: M68k couldn't
restart auto-inc/dec style instructions after a fault (there wasn't enough
information in the trap frame to ensure the side-effects were correct),
which made e.g. dynamic paging hard. He did a Unix port in which he simply
loaded the process completely before switching to it (e.g., like <= 32V).
But if I understand correctly, this was fixed by the time the 68010 came
out (1982). And it wouldn't have mattered for a non-paging system. So in
principle the 68000 could support a 7th-Edition style Unix and indeed, did
so. Surely it could have supported another similar operating system for a
hypothetical IBM PC based around the 68k.

Still, the point that the 68451 MMU was pretty lame is well taken. The
segment table was too small (96 entries?) and it was clearly designed to
support segmented memory rather than paging. It is inadequate to the latter
task. The 68851 available for the 68020 got it right; supposedly this could
be used with the 68010 as well, but I don't know that anyone ever tried
that in a real product.

I got a lot more respect for the 8086 architecture when working at
> Transmeta.  The instruction set encoding means that programs are small,
> and that means that, for a given icache size, the cache hit rate was much
> better than for our (wide word) machine.  By the time we had upped the
> size of our caches, the increased area and cost made our chip much less
> competitive.
>

I've heard that this is still one of the selling points of the x86
instruction set. As someone put it to me not too long ago, "think of it as
a dense bytecoding over the underlying RISC core." We're back to a P-code.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/0912ba80/attachment.html>

[TUHS] Algol68 vs. C at Bell Labs

[John Cowan]

Noel Chiappa scripsit:

> One of many, apparently, given Hoare's incredible classic "The Emperor's
> Old Clothes":

I agree with 90% of what he says, but not about Algol 68.  He obviously
has a strong preference for small languages: it would be interesting
to see his uncensored opinions of C++, the Godzilla of our day as Ada
and PL/I and Algol 68 were the Godzillas of theirs.  But from where we
stand now, A68 looks like a minizilla indeed, and has many interesting
ideas (notably structural equivalence).  It would need a few upgrades
to provide for subtyping and functional programming.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
In might the Feanorians / that swore the unforgotten oath
brought war into Arvernien / with burning and with broken troth.
and Elwing from her fastness dim / then cast her in the waters wide,
but like a mew was swiftly borne, / uplifted o'er the roaring tide.
        --the Earendillinwe

[TUHS] 68000 vs. 8086 ( was Algol68 vs. C at Bell Labs)

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 815 bytes --]

Dan Cross <crossd at gmail.com> wrote:

> Still, the point that the 68451 MMU was pretty lame is well taken. The
> segment table was too small (96 entries?) and it was clearly designed to
> support segmented memory rather than paging. It is inadequate to the latter
> task. The 68851 available for the 68020 got it right; supposedly this could
> be used with the 68010 as well, but I don't know that anyone ever tried
> that in a real product.

We at H.Berthold AG in Berlin did manage to use 12 68451 in parallel for our 
virtual UNOS variant.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'

[TUHS] 68000 vs. 8086 ( was Algol68 vs. C at Bell Labs)

[Dan Cross]

On Thu, Jun 30, 2016 at 3:59 PM, Joerg Schilling <schily at schily.net> wrote:

> Dan Cross <crossd at gmail.com> wrote:
>
> > Still, the point that the 68451 MMU was pretty lame is well taken. The
> > segment table was too small (96 entries?) and it was clearly designed to
> > support segmented memory rather than paging. It is inadequate to the
> latter
> > task. The 68851 available for the 68020 got it right; supposedly this
> could
> > be used with the 68010 as well, but I don't know that anyone ever tried
> > that in a real product.
>
> We at H.Berthold AG in Berlin did manage to use 12 68451 in parallel for
> our
> virtual UNOS variant.


Sorry, I was referring to using a 68851 with a 68010; I'd imagine that by
the time the 68851 was appearing in new designs, it was paired with the
68020.

Wow. *12* 68451s? That's pretty wild.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/144e7bad/attachment.html>

[TUHS] 68000 vs. 8086 ( was Algol68 vs. C at Bell Labs)

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 497 bytes --]

Dan Cross <crossd at gmail.com> wrote:

> > We at H.Berthold AG in Berlin did manage to use 12 68451 in parallel for
> > our
> > virtual UNOS variant.

> Wow. *12* 68451s? That's pretty wild.

3 have been officially supported.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'

[TUHS] Algol68 vs. C at Bell Labs

[Ronald Natalie]

Yep, you could mount dectapes as filesystems, but you were not getting the greatest performance when you had to wait for it to rewind to update the superblock.

> On Jul 4, 2016, at 3:23 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
> On Thu, 30 Jun 2016, John Cowan wrote:
> 
>> Indeed, the PDP-8 system I cut my teeth on swapped (infrequently) to 
>> DECtape, which is essentially a floppy drive without random access.
> 
> DECtape was indeed random access; individual blocks could be addressed.
> 
> -- 
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Algol68 vs. C at Bell Labs

[Dave Horsfall]

On Thu, 30 Jun 2016, John Cowan wrote:

> Indeed, the PDP-8 system I cut my teeth on swapped (infrequently) to 
> DECtape, which is essentially a floppy drive without random access.

DECtape was indeed random access; individual blocks could be addressed.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Algol68 vs. C at Bell Labs

[Peter Jeremy]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1648 bytes --]

On 2016-Jun-30 22:21:27 +0300, Diomidis Spinellis <dds at aueb.gr> wrote:
>First, the 8088 was a 16-bit CPU with an 8-bit data bus in a cheap 
>40-pin package.  This halved the number DRAM chips required and allowed 
>the IBM PC to be easily designed along existing easily-available 8-bit 
>peripherals.  In contrast the 68000 had a 16-bit data bus in a more 
>expensive 64-pin package.  Remember that in the 1980s glue logic was 
>implemented through simple TTL chips, so adopting the 68000 might have 
>doubled the number of chips on the motherboard.

My understanding was that the 8-bit bus was a requirement so IBM could
have a 64KB base model using the then new 64k×1 chips.  IBM also
emasculated the PC so it didn't compete with their existing minis.  The
68008 wasn't available until later (and this would explain why Motorola
pushed the 6809 as a solution).

Both the 8086 and M68k could relatively easily use 8-bit peripherals
(both Intel and Motorola had a range of 8-bit peripherals that they
didn't want to make instantly obsolete).

>In addition, the 8086 architecture was an extension of the 8080 one, 
>which made it easier to make the MS-DOS API compatible with the CP/M 

Since IBM was buying the software, I'm not sure how much of a driver
this was.  Definitely, porting from 8080 to 8086 was easier but writing
from scratch would be far easier on M68k.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160703/16c609a7/attachment.sig>

[TUHS] Algol68 vs. C at Bell Labs

[Brantley Coile]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2528 bytes --]

Wirth attempted to write a simple language to write the real Pascal compiler. One fatal flaw was that the simpler language lacked recursion, which was optional in those days, and the use of the Pascal-0 was abandoned. The next attempt was to write the compiler in Pascal and ``desk’’ compile it into machine code. That was amazingly successful, if tedious.

Later, to make porting easier, the good professor wrote a version that generated a stack based intermediate code called P-code. You could get a copy of the compiler in Pascal and P-code, write your own P-code interpreter and have a Pascal compiler. It was easy. Pascal compilers spread like locus after that. One could then change the compiler to write machine code for the actual machine, although many just extended their P-code emulators. It was “compile once, run anywhere” long before Java’s virtual machine.

BCPL came the same way, with a version of the compiler in CINIT code to move the compiler. 

The PCC required a donor machine already running Unix in somewhat close proximity to the target machine.

  Brantley Coile

> On Jun 30, 2016, at 1:17 PM, Nelson H. F. Beebe <beebe at math.utah.edu> wrote:
> 
> Ori Idan <ori at helicontech.co.il> asks today:
> 
>>> Pascal compiler written in Pascal? how can I compile the compiler it I
>>> don't yet have a pascal compiler? :-)
> 
> You compile the code by hand into assembly language for the CDC
> 6400/6600 machines, and bootstrap that way: see
> 
> 	Urs Ammann
> 	On Code Generation in a PASCAL Compiler
> 	http://dx.doi.org/10.1002/spe.4380070311
> 
> 	Niklaus Wirth
> 	The Design of a PASCAL Compiler
> 	http://dx.doi.org/10.1002/spe.4380010403
> 
> It has been a long time since I read those articles in the journal
> Software --- Practice and Experience, but my recollection is that they
> wrote the compiler in a minimal subset of Pascal needed to do the job,
> just to ease the hand-translation process.
> 
> -------------------------------------------------------------------------------
> - Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
> - University of Utah                    FAX: +1 801 581 4148                  -
> - Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
> - 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
> - Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
> -------------------------------------------------------------------------------

[TUHS] Algol68 vs. C at Bell Labs

[Lyndon Nerenberg]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 921 bytes --]


> On Jun 30, 2016, at 5:38 PM, Clem Cole <clemc at ccc.com> wrote:
> 
> ​Hang on that it was not quite that simple.   In fact IBM did publish everything because that was what all the PC folks did at the time.   As did IBM themselves in their mainframes.   Remember when the PC was originally developed, Judge Green has not yet left IBM from its bondage.​   So IBM was very careful in those days to follow industry norms.   The PC folks (like Apple, Altair, Cromemco et al) published the schematics and the ROM listings.  The OS's and higher level tools were closed but the rest tended to be generally available so IBM followed suit.

But IBM had long stopped publishing source for VM/360 by that point.  They were quite aware by the time of ??-DOS that copyright applied to source code.

And by then there were copyright notices being slapped all over BIOS code.  I remember seeing it in S-100 systems at the time.

[TUHS] Algol68 vs. C at Bell Labs

[Jesus Cea]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]

On 30/06/16 17:07, Ori Idan wrote:
> Pascal compiler written in Pascal? how can I compile the compiler it I
> don't yet have a pascal compiler? :-)

That is standard procedure:

https://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29

-- 
Jesús Cea Avión                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
Twitter: @jcea                        _/_/    _/_/          _/_/_/_/_/
jabber / xmpp:jcea at jabber.org  _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160701/ac98b9bc/attachment.sig>

[TUHS] Algol68 vs. C at Bell Labs

[Kurt H Maier]

On Thu, Jun 30, 2016 at 10:35:27PM -0400, Nemo wrote:
> 
> Anyone remember Desqview/X? 

The best feature that software had was it let you run Windows programs
from the machine running DV/X on a unix workstation.  It was the only
reason anyone used the Sun machines in one of the labs when I first got
to college.

khm

[TUHS] Algol68 vs. C at Bell Labs

[Nemo]

On 30 June 2016 at 20:38, Clem Cole <clemc at ccc.com> wrote (in part):
> Marc,
>
[...]
> Seriously, Marc I get it and you are better man for dealing with the
> craziness of the day.  Many of the rest of us would not at the time, and
> until we got "real HW" did not mess that much with it.

Anyone remember Desqview/X?  A strange beast, running some window
manager on X on a PC. They made available a variant of gcc and you
could actually compile some X stuff.  I say "some" because I tried
compiling something by running xmkmf+make  and went back to laying
subfloor in an adjacent room.  A few minutes later, I heard the PC
rebooting.  The underlying file system was still DOS and thus 8.3
names.  The source included headers that differed in the 9th place and
the stack eventually blew.

N.

[TUHS] Algol68 vs. C at Bell Labs

[John Cowan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 444 bytes --]

Clem Cole scripsit:

> ​Truth is folks built systems that swapped to floppies (and cassette tape
> et al) in those days.  

Indeed, the PDP-8 system I cut my teeth on swapped (infrequently) to DECtape,
which is essentially a floppy drive without random access.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
There is / One art / No more / No less
To do / All things / With art- / -Lessness          --Piet Hein

[TUHS] Algol68 vs. C at Bell Labs

[Marc Rochkind]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5998 bytes --]

thanks for these comments... lots of interesting stuff

On Thursday, June 30, 2016, Clem Cole <clemc at ccc.com> wrote:

> Marc,
>
> I mostly agree but you have a little history out of order.  Apple and
> Franklin really are important here.  More inline...
>
> On Thu, Jun 30, 2016 at 7:16 PM, Marc Rochkind <rochkind at basepath.com
> <javascript:_e(%7B%7D,'cvml','rochkind at basepath.com');>> wrote:
>
>> Clem Cole: "IBM allowed the system to be cloned"
>>
>> I never looked at it that way. To discourage cloning, IBM published and
>> copyrighted the BIOS source code.
>>
> ​Hang on that it was not quite that simple.   In fact IBM did publish
> everything because that was what all the PC folks did at the time.   As did
> IBM themselves in their mainframes.   Remember when the PC was originally
> developed, Judge Green has not yet left IBM from its bondage.​   So IBM was
> very careful in those days to follow industry norms.   The PC folks (like
> Apple, Altair, Cromemco et al) published the schematics and the ROM
> listings.  The OS's and higher level tools were closed but the rest tended
> to be generally available so IBM followed suit.
>
>
>
>
>
>> ​....​
>>  A few outfits sprang up to do clean-room BIOS clones, including an
>> outfit called Phoenix, which had the best. Compaq's internal BIOS was also
>> excellent.
>>
> ​This post the Franklin Computer case.​  Clones of Apple II sprung up,
> with CPU motherboards coming from Taiwan.   Hey I made an Apple II clone,
> as well as an Xerox 820 clone in those days myself (I may still have the
> later).
>
> Franklin Computer of Philadelphia started to sell their Apple II to run
> Visacalc - which was the "killer app" of the day (note a theme here).  Jobs
> did not like it and took them to court.  I actually knew the main attorney
> for Franklin at the time (one of the few big cases he even lost).   Apple
> won because it was the contents of the ROM (bit for bit) that was found to
> be identical.   The question became could you "copyright" the bits. [There
> is a whole side discussion about what the memory chip guys of that day did
> to try to keep people from copying them BTW].
>
> Anyway, once that became case law, the concept of a "clean room" was
> created.  As you say, Phoenix did a remarkable job.   BTW:  in an
> interested side note, years later, IBM sold Phoenix its BIOS and started to
> use theirs when the Phoenix BIOS became the gold standard.
>
>
>
>>
>> As for the computer hardware, it was just Intel parts
>>
> ​Motorola, WD, and TI parts originally.​
>
>
>
>
>> For the clones, no copyrighted code was used, the programmers had never
>> seen the code, and the function of the BIOS wasn't copyrightable. So, IBM
>> really had no way to prevent the clones.
>>
> ​If they had not published the original material, I suspect it would have
> been far, far harder and less attractive.   But also remember, clone in the
> IBM land was already around.  Amdahl was selling like hot cakes.  IBM had
> learned that with the clone market, they sold more of their own product.
> It was an interesting business view.   The pie was getting bigger faster,
> so they got a larger amount of pie, even though the percentage of the pie
> got smaller.​  So IBM made more money.
>
> This was a lesson a lot of companies, particularly computer firms, never
> quite understood.   Having a weak, buy alive competitor is better than no
> competition.
>
>
>
>
>>
>>
>> There were a lot of PCs in the early 1980s that weren't clones.
>>
> ​Absolutely.​  But if the OS has been reasonable and had be able to hide
> the differences (and you not be able to go directly to HW addresses etc..)
> this would have been less of an issue.
>
>
>
>
>> ​...
>> DEC, which had their own weird version of a PC, was the worst.
>>
> ​No doubt.​
>
>
>
>> One might ask why we had such a primitive system with 384K, when UNIX had
>> been developed over 10 years before on a smaller system. Simple: UNIX had
>> swapping.
>>
> ​Truth is folks built systems that swapped to floppies (and cassette tape
> et al) in those days.  Originally Magix was going to be in that same camp
> when it was a "G-job" by Roger and myself.  When our boss funded its the
> first thing we did was add a 10M disk.​
>
>
>
>
>> ​... ​
>> To get the screen speed on a PC, the application had to own the hardware.
>>
> ​That was a deficiency of the PC HW design.   Other systems, such as the
> Magnolia and later Apollo/Masscomp/Sun, showed you could have fine speed
> with out having to do that.  Also in "PC land" consider when the '20 Mac
> came out and Apple started to get religion (as did NeXT shortly there
> after).
>
> You could do it, but the original PC designs were sloppy and did not care
> -- the feeling was that extra HW (and SW to support) was unnecessary.
> In many ways, the original PC guys were right given how far and how long
> those systems lived.   But it was painful for the SW building as you
> pointed out.    You should not have had to do such "unnatural" or "unsafe"
> acts.
>
>
>
>
>> UNIX insists on standing between the application and the hardware.
>>
> ​As it should ;-) ​It required  good HW under the covers and then UNIX
> drivers that did the the right things.  In the same time frame as the PC
> was developed it was definitely possible and would not have cost more.​
>
>
>
>
>> In PC land that would be unacceptable.
>>
> ​Only because the HW sucked and the OS did not have the right types of
> structures to make it work.​
>
> Seriously, Marc I get it and you are better man for dealing with the craziness
> of the day.  Many of the rest of us would not at the time, and until we got
> "real HW" did not mess that much with it.  Then again, I did not care to
> run a VisaCalc or a Word Perfect :-)
>
> Clem
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/ad177082/attachment-0001.html>

[TUHS] Algol68 vs. C at Bell Labs

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5596 bytes --]

Marc,

I mostly agree but you have a little history out of order.  Apple and
Franklin really are important here.  More inline...

On Thu, Jun 30, 2016 at 7:16 PM, Marc Rochkind <rochkind at basepath.com>
wrote:

> Clem Cole: "IBM allowed the system to be cloned"
>
> I never looked at it that way. To discourage cloning, IBM published and
> copyrighted the BIOS source code.
>
​Hang on that it was not quite that simple.   In fact IBM did publish
everything because that was what all the PC folks did at the time.   As did
IBM themselves in their mainframes.   Remember when the PC was originally
developed, Judge Green has not yet left IBM from its bondage.​   So IBM was
very careful in those days to follow industry norms.   The PC folks (like
Apple, Altair, Cromemco et al) published the schematics and the ROM
listings.  The OS's and higher level tools were closed but the rest tended
to be generally available so IBM followed suit.





> ​....​
>  A few outfits sprang up to do clean-room BIOS clones, including an outfit
> called Phoenix, which had the best. Compaq's internal BIOS was also
> excellent.
>
​This post the Franklin Computer case.​  Clones of Apple II sprung up, with
CPU motherboards coming from Taiwan.   Hey I made an Apple II clone, as
well as an Xerox 820 clone in those days myself (I may still have the
later).

Franklin Computer of Philadelphia started to sell their Apple II to run
Visacalc - which was the "killer app" of the day (note a theme here).  Jobs
did not like it and took them to court.  I actually knew the main attorney
for Franklin at the time (one of the few big cases he even lost).   Apple
won because it was the contents of the ROM (bit for bit) that was found to
be identical.   The question became could you "copyright" the bits. [There
is a whole side discussion about what the memory chip guys of that day did
to try to keep people from copying them BTW].

Anyway, once that became case law, the concept of a "clean room" was
created.  As you say, Phoenix did a remarkable job.   BTW:  in an
interested side note, years later, IBM sold Phoenix its BIOS and started to
use theirs when the Phoenix BIOS became the gold standard.



>
> As for the computer hardware, it was just Intel parts
>
​Motorola, WD, and TI parts originally.​




> For the clones, no copyrighted code was used, the programmers had never
> seen the code, and the function of the BIOS wasn't copyrightable. So, IBM
> really had no way to prevent the clones.
>
​If they had not published the original material, I suspect it would have
been far, far harder and less attractive.   But also remember, clone in the
IBM land was already around.  Amdahl was selling like hot cakes.  IBM had
learned that with the clone market, they sold more of their own product.
It was an interesting business view.   The pie was getting bigger faster,
so they got a larger amount of pie, even though the percentage of the pie
got smaller.​  So IBM made more money.

This was a lesson a lot of companies, particularly computer firms, never
quite understood.   Having a weak, buy alive competitor is better than no
competition.




>
>
> There were a lot of PCs in the early 1980s that weren't clones.
>
​Absolutely.​  But if the OS has been reasonable and had be able to hide
the differences (and you not be able to go directly to HW addresses etc..)
this would have been less of an issue.




> ​...
> DEC, which had their own weird version of a PC, was the worst.
>
​No doubt.​



> One might ask why we had such a primitive system with 384K, when UNIX had
> been developed over 10 years before on a smaller system. Simple: UNIX had
> swapping.
>
​Truth is folks built systems that swapped to floppies (and cassette tape
et al) in those days.  Originally Magix was going to be in that same camp
when it was a "G-job" by Roger and myself.  When our boss funded its the
first thing we did was add a 10M disk.​




> ​... ​
> To get the screen speed on a PC, the application had to own the hardware.
>
​That was a deficiency of the PC HW design.   Other systems, such as the
Magnolia and later Apollo/Masscomp/Sun, showed you could have fine speed
with out having to do that.  Also in "PC land" consider when the '20 Mac
came out and Apple started to get religion (as did NeXT shortly there
after).

You could do it, but the original PC designs were sloppy and did not care
-- the feeling was that extra HW (and SW to support) was unnecessary.   In
many ways, the original PC guys were right given how far and how long those
systems lived.   But it was painful for the SW building as you pointed out.
   You should not have had to do such "unnatural" or "unsafe" acts.




> UNIX insists on standing between the application and the hardware.
>
​As it should ;-) ​It required  good HW under the covers and then UNIX
drivers that did the the right things.  In the same time frame as the PC
was developed it was definitely possible and would not have cost more.​




> In PC land that would be unacceptable.
>
​Only because the HW sucked and the OS did not have the right types of
structures to make it work.​

Seriously, Marc I get it and you are better man for dealing with the craziness
of the day.  Many of the rest of us would not at the time, and until we got
"real HW" did not mess that much with it.  Then again, I did not care to
run a VisaCalc or a Word Perfect :-)

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/9cfcde67/attachment.html>

[TUHS] Algol68 vs. C at Bell Labs

[Random832]

On Thu, Jun 30, 2016, at 19:16, Marc Rochkind wrote:
> ...and the function of the BIOS wasn't copyrightable.

Well, that's apparently not actually settled law, judging by the fact
that Oracle v. Google wasn't laughed out of court nearly thirty years
later.

[TUHS] Algol68 vs. C at Bell Labs

[Marc Rochkind]

Clem Cole: "IBM allowed the system to be cloned"

I never looked at it that way. To discourage cloning, IBM published and
copyrighted the BIOS source code. Most serious programmers were very
familiar with it, because one had to know details of the BIOS to program
the computer, for many applications (such as ours). That reduced the number
of programmers who could work on a BIOS clone, as such people would have to
be recruited from outside the world of the IBM PC. A few outfits sprang up
to do clean-room BIOS clones, including an outfit called Phoenix, which had
the best. Compaq's internal BIOS was also excellent.

As for the computer hardware, it was just Intel parts along with
off-the-shelf floppy disk controllers and drives and other such stuff. IBM
had built the PC almost entirely from existing parts, and had no exclusive
on any of it.

For the clones, no copyrighted code was used, the programmers had never
seen the code, and the function of the BIOS wasn't copyrightable. So, IBM
really had no way to prevent the clones.

There were a lot of PCs in the early 1980s that weren't clones. They had
8088 or 8086 CPUs, and looked liked PCs, but they weren't identical, so we
had to port our software. Sometimes companies gave us machines, including
AT&T, whose PC was made by Olivetti. I remember many conversations with
computer vendors in which I was just trying to get the memory address and
layout for the screen. They never could even understand the question. DEC,
which had their own weird version of a PC, was the worst.

Within a few years all these went away, and only identical clones existed,
for which we didn't need to develop a special version.

A few people here have said that IBM could have produced a more
sophisticated OS. Actually, I would have been against anything that took up
more resident memory. Initially, I think the most memory IBM would supply
was 384K, and most serious applications needed it all. Multiprogramming or
sophisticated system calls of any sort would have sucked up valuable
memory. I was able to design the EDIX editor to be entirely memory
resident, even with multiple active files, with no floppy swapping at all.

As someone mentioned, we pretty much used MS-DOS only for its file
management. Access to all other facilities was through the BIOS or directly
to the hardware. With such a completely unprotected system, running more
than one application at a time was out of the question.

One might ask why we had such a primitive system with 384K, when UNIX had
been developed over 10 years before on a smaller system. Simple: UNIX had
swapping. With no hard drive, and floppies being inserted and removed,
everything had to be resident in RAM. In addition, as I've mentioned
already, screen speed is what distinguished PC software, ever since Apple
games and Visicalc. Traditional UNIX screen speed was ridiculously slow,
until the workstations came along, but for many times the price of a PC. To
get the screen speed on a PC, the application had to own the hardware. UNIX
insists on standing between the application and the hardware. In PC land
that would be unacceptable.

--Marc

On Thu, Jun 30, 2016 at 2:57 PM, Nemo <cym224 at gmail.com> wrote:

> On 30 June 2016 at 15:21, Diomidis Spinellis <dds at aueb.gr> wrote:
> [...]
> > Two factors might had made the choice of 8088 a more practical one for
> IBM.
> >
> [...]
> > In addition, the 8086 architecture was an extension of the 8080 one,
> which
> > made it easier to make the MS-DOS API compatible with the CP/M one, which
> > was used by many popular programs.  This would simplify their porting.
> (A
> > lot of early IBM PC software was written in assembly language.)
>
> I heard that a lot of the BIOS was a simple-minded translation of
> corresponding 8080-assembler.  I believe that; if you look at the
> horrible assembler, which was actually printed in the IBM Technical
> Manual, you could see that most 8086 extensions were not used.
>
> N.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/e6c206e9/attachment.html>

[TUHS] Algol68 vs. C at Bell Labs

[Random832]

On Thu, Jun 30, 2016, at 16:57, Nemo wrote:
> I heard that a lot of the BIOS was a simple-minded translation of
> corresponding 8080-assembler.  I believe that; if you look at the
> horrible assembler, which was actually printed in the IBM Technical
> Manual, you could see that most 8086 extensions were not used.

Well, a new system means there are no expert programmers for it, who
have learned all the tricks and how it all fits together. You see
something similar in environments like console video games, with a
progression of higher-performance games within each console generation
as programmers learn to wring more out of the same hardware.

[TUHS] Algol68 vs. C at Bell Labs

[Dave Horsfall]

On Thu, 30 Jun 2016, Ori Idan wrote:

> Pascal compiler written in Pascal? how can I compile the compiler it I 
> don't yet have a pascal compiler? :-)

I've always said that the ultimate test of a compiler was whether it could 
compile itself.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Algol68 vs. C at Bell Labs

[Nemo]

On 30 June 2016 at 15:21, Diomidis Spinellis <dds at aueb.gr> wrote:
[...]
> Two factors might had made the choice of 8088 a more practical one for IBM.
>
[...]
> In addition, the 8086 architecture was an extension of the 8080 one, which
> made it easier to make the MS-DOS API compatible with the CP/M one, which
> was used by many popular programs.  This would simplify their porting.  (A
> lot of early IBM PC software was written in assembly language.)

I heard that a lot of the BIOS was a simple-minded translation of
corresponding 8080-assembler.  I believe that; if you look at the
horrible assembler, which was actually printed in the IBM Technical
Manual, you could see that most 8086 extensions were not used.

N.

[TUHS] Algol68 vs. C at Bell Labs

[Lawrence Stewart]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

Regarding Pascal for the IBM PC. In its day, Borland Turbo Pascal was particularly fast.

But C existed as well. 

In 1982 I was building an ethernet telephone at PARC and used the 8088, mostly because
they were cheap (due to the PC) and because we had an internal C compiler for it.
I felt C was the necessary language, because that’s what we used on V7 at Stanford.

-L

[TUHS] Algol68 vs. C at Bell Labs

[Dan Cross]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 601 bytes --]

On Thu, Jun 30, 2016 at 3:55 PM, Clem Cole <clemc at ccc.com> wrote:
>
> On Thu, Jun 30, 2016 at 3:51 PM, Dan Cross <crossd at gmail.com> wrote:
>
>> In economics vs technology, economics almost always wins.
>
> ​Amen - although I would probably have said it as:    s/almost//
>

That was my escape hatch for the rare but fortuitous moments where the
stars align and the technologically superior solution matches the
economics. :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/8bdb2209/attachment.html>

[TUHS] Algol68 vs. C at Bell Labs

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 373 bytes --]

On Thu, Jun 30, 2016 at 3:51 PM, Dan Cross <crossd at gmail.com> wrote:

> In economics vs technology, economics almost always wins.

​Amen - although I would probably have said it as:    s/almost//
Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/12a2e1d9/attachment.html>

[TUHS] Algol68 vs. C at Bell Labs

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 670 bytes --]

On Thu, Jun 30, 2016 at 3:43 PM, Dan Cross <crossd at gmail.com> wrote:

> I wanted to write back and say that the 68008 in the 48-ing DIP package
> would address these concerns: 20bit address bus and an 8-bit data bus, but
> that doesn't appear to have been available until 1982.

​When the pick of the 8086/8088 was made, the 68000 did not official exist
either.​  As I understand it, >>I believe<< that the 68008 is just an 68000
die, that is bonded differently.  All the logic is in both chips.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/e21850a1/attachment.html>

[TUHS] Algol68 vs. C at Bell Labs

[Dan Cross]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3311 bytes --]

On Thu, Jun 30, 2016 at 3:21 PM, Clem Cole <clemc at ccc.com> wrote:
>
> On Thu, Jun 30, 2016 at 2:31 PM, Dan Cross <crossd at gmail.com> wrote:
>>
>> ​...​
>> why didn't they have a more capable kernel than MS-DOS?
>>
> ​I don't think they cared. or felt it was needed at the time (I disagreed
> then and still do).
>

Yeah...I guess you are right.

Surely a motivated team could have produced a floppy-only system capable of
>> running multiple processes, etc. It wouldn't be Unix, it wouldn't even
>> necessarily be a clone of Unix, but it could have been something better
>> than MS-DOS.
>>
> ​As Marc pointed out.  The PC was fabulously successful for what it was
> designed to be.  They wanted something the run VisiCalc and later a word
> processor for corporate America.   We are programmers saw it >>could<< have
> been more capable, but they did not really care.   The system way, way
> out did what it was planned.   So it's hard to tell folks that did
> something bad.
>
> ​... ​
>> I'm not sure I would assert that their success was due to good technical
>> decisions;
>>
> ​exactly.​
>
>
>
>> ​...
>>  The IBM brand added de facto legitimacy to the personal computer in the
>> workplace at a critical time when it was just starting to make inroads into
>> business: surely their success had a lot more to do with that than choosing
>> to use the 8088 and DOS?
>>
> ​Indeed.​
>
> Although I think a side story is that you did not mention is that IBM
> allowed the system to be cloned.  Remember at this same time, Apple out
> Franklin computer out of business for cloning the Apple II.    Because the
> PC became a standard of sort, because their were choices in getting lower
> cost systems, not just buying from IBM.   That ended top cementing it,
>

That's an excellent point.

The VHS vs. Betamax argument may apply here.
>>
> ​Maybe - I think of it in terms of economics.​     PCs and DOS
> "won" because they were cheaper than any other solution to the a similar
> task and it was good enough,
>

I suspect that, at the end of the day, this is the real reason for the
success of the PC. It's easy, as an engineer, to second-guess it and ask
why it couldn't have been "more" than it was, but I suspect a business
person would look at me funny. From a business perspective, it was wildly
successful (until the clone market undercut IBM so much they got out of the
PC business altogether). In economics vs technology, economics almost
always wins.

        - Dan C.


Like VHS/Betamax it was good enough for many, many people - so economics
> drove the standard.  But also at the time, Apple, who had a better product
> and actually was more polished than MS-DOS was, was >>perceived<< as being
> for home use and DOS for business.   IBM and MSFT and Intel did a great job
> of convincing people of that idea.   Add to it that it was cheaper, it was
> a hard order to get businesses to consider Macs.
>
> Which is different from Betamax....   business (TV stations/professionals
> et al) picked the "better" system.    But they did not here, they picked
> the cheap one no matter what.
>
> Clem
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/3ed60f2b/attachment-0001.html>

[TUHS] Algol68 vs. C at Bell Labs

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3153 bytes --]

On Thu, Jun 30, 2016 at 3:21 PM, Diomidis Spinellis <dds at aueb.gr> wrote:

> First, the 8088 was a 16-bit CPU with an 8-bit data bus in a cheap 40-pin
> package.  This halved the number DRAM chips required and allowed the IBM PC
> to be easily designed along existing easily-available 8-bit peripherals.
> In contrast the 68000 had a 16-bit data bus in a more expensive 64-pin
> package.  Remember that in the 1980s glue logic was implemented through
> simple TTL chips, so adopting the 68000 might have doubled the number of
> chips on the motherboard.
>
hrrmpt...​Moto had the 68008 which was an 8 bit bus, smaller # of pins,
plus all of the 68K chips could directly talk the 6800 line of peripheral
chips (I even have an old Moto app note right here telling you how).  In
fact IBM, used a number of 6800 chips in the PC for things like the display
controller.

Also remember in those days IBM and Moto were very, very tight.  MECL
-- Motorola Emitter Coupled Logic was design by Moto for IBM for the 370
family.  TTL or as it was called at IBM - VTL (Vendor Transistor Logic),
was less favored.

That said, what would become the 68000 was TTL levels.   That was because
the prototyped it in TTL (and wrote the microcode on the TTL system).



> In addition, the 8086 architecture was an extension of the 8080 one,
>
​Yes and no.​  Yes the 4004's HL register pair still lives on.  But the
8080/8085 instruction set was different from the 8086.




> which made it easier to make the MS-DOS API compatible with the CP/M one,
> which was used by many popular programs.  This would simplify their
> porting.  (A lot of early IBM PC software was written in assembly
> language.)
>
​Yes there were tools to help move assembler code but it still had to be
hand tuned,  Even the PL/M tools were specific to 8080 and 8086.​

But I don't know of much code that took the CP/M to MS-DOS conversion path.




> The MS-DOS 1.0 interrupts (system calls) even used the same numbers and
> structures (file control blocks - FCBs) as those used by CP/M.
>
​Yes, DOS-86 was attempt to rewrite CP/M for the 8086 by Seattle computer
products.  And CP/M was attempt by Digital Research to rewrite RT-11.
There are a lot of common structures, I/O calls and even command names.
 But that is more of the "baby duck syndrome" - it was what the
implementors knew and were used too.​

As other have suggested, it is sad that the model was not UNIX.   The BDS
guys wrote a UNIX-like system for the S-100 machines.   I remember it being
shown to Dennis at a USENIX in the early 1980s and he stating how much
it reminded him of early UNIX.  So yes, the key is that if people had had
other models AND it had made economic sense, the world might have been
different.

But RT-11, ney: CP/M , ney DOS-86, ney PC-DOS, ney MS-DOS >>was<< good
enough as Marc pointed out.   IBM and the Microsoft were fabulously
successful with what they build, even if it was not technically as good as
what was possible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/0e0c998f/attachment.html>

[TUHS] Algol68 vs. C at Bell Labs

[Dan Cross]

On Thu, Jun 30, 2016 at 3:21 PM, Diomidis Spinellis <dds at aueb.gr> wrote:

> On 30/06/2016 18:32, Dan Cross wrote:
>
>> Of
>> course it's only of historical interest now, but from a technology
>> standpoint MC68000 vs Intel 8088 seems like a no-brainer: the 68k is the
>> superior chip.
>>
>
> Two factors might had made the choice of 8088 a more practical one for IBM.
>
> First, the 8088 was a 16-bit CPU with an 8-bit data bus in a cheap 40-pin
> package.  This halved the number DRAM chips required and allowed the IBM PC
> to be easily designed along existing easily-available 8-bit peripherals.
> In contrast the 68000 had a 16-bit data bus in a more expensive 64-pin
> package.  Remember that in the 1980s glue logic was implemented through
> simple TTL chips, so adopting the 68000 might have doubled the number of
> chips on the motherboard.
>

It sounds an awful lot like Motorola was actively trying to steer IBM away
from the 68k, but that the 68k was what they really wanted. If that was the
case, presumably they could get the glue logic to an acceptable level. I've
looked at some 68k based board designs and it rarely seems that bad for
small systems; Clements's book has a really nice design for a 68030-based
system, even, that looks like it could be done on a fairly small board.

I wanted to write back and say that the 68008 in the 48-ing DIP package
would address these concerns: 20bit address bus and an 8-bit data bus, but
that doesn't appear to have been available until 1982.

In addition, the 8086 architecture was an extension of the 8080 one, which
> made it easier to make the MS-DOS API compatible with the CP/M one, which
> was used by many popular programs.  This would simplify their porting.  (A
> lot of early IBM PC software was written in assembly language.)  The MS-DOS
> 1.0 interrupts (system calls) even used the same numbers and structures
> (file control blocks - FCBs) as those used by CP/M.  MS-DOS 2.0 added file
> paths and other Unix-influenced abstractions.
>

That's a fair point. But if they were willing to look at UCSD Pascal,
presumably foregoing CP/M compatibility, why not the Unix syscall interface
as well?

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/75af1c55/attachment.html>

[TUHS] Algol68 vs. C at Bell Labs

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2633 bytes --]

On Thu, Jun 30, 2016 at 2:31 PM, Dan Cross <crossd at gmail.com> wrote:


> ​...​
> why didn't they have a more capable kernel than MS-DOS?
>
​I don't think they cared. or felt it was needed at the time (I disagreed
then and still do).




> Surely a motivated team could have produced a floppy-only system capable
> of running multiple processes, etc. It wouldn't be Unix, it wouldn't even
> necessarily be a clone of Unix, but it could have been something better
> than MS-DOS.
>
​As Marc pointed out.  The PC was fabulously successful for what it was
designed to be.  They wanted something the run VisiCalc and later a word
processor for corporate America.   We are programmers saw it >>could<< have
been more capable, but they did not really care.   The system way, way out
did what it was planned.   So it's hard to tell folks that did something
bad.

​... ​
> I'm not sure I would assert that their success was due to good technical
> decisions;
>
​exactly.​



> ​...
>  The IBM brand added de facto legitimacy to the personal computer in the
> workplace at a critical time when it was just starting to make inroads into
> business: surely their success had a lot more to do with that than choosing
> to use the 8088 and DOS?
>
​Indeed.​

Although I think a side story is that you did not mention is that IBM
allowed the system to be cloned.  Remember at this same time, Apple out
Franklin computer out of business for cloning the Apple II.    Because the
PC became a standard of sort, because their were choices in getting lower
cost systems, not just buying from IBM.   That ended top cementing it,




> The VHS vs. Betamax argument may apply here.
>
​Maybe - I think of it in terms of economics.​     PCs and DOS
"won" because they were cheaper than any other solution to the a similar
task and it was good enough,   Like VHS/Betamax it was good enough for
many, many people - so economics drove the standard.  But also at the time,
Apple, who had a better product and actually was more polished than MS-DOS
was, was >>perceived<< as being for home use and DOS for business.   IBM
and MSFT and Intel did a great job of convincing people of that idea.   Add
to it that it was cheaper, it was a hard order to get businesses to
consider Macs.

Which is different from Betamax....   business (TV stations/professionals
et al) picked the "better" system.    But they did not here, they picked
the cheap one no matter what.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/747706b7/attachment-0001.html>

[TUHS] Algol68 vs. C at Bell Labs

[Diomidis Spinellis]

On 30/06/2016 18:32, Dan Cross wrote:
> Of
> course it's only of historical interest now, but from a technology
> standpoint MC68000 vs Intel 8088 seems like a no-brainer: the 68k is the
> superior chip.

Two factors might had made the choice of 8088 a more practical one for IBM.

First, the 8088 was a 16-bit CPU with an 8-bit data bus in a cheap 
40-pin package.  This halved the number DRAM chips required and allowed 
the IBM PC to be easily designed along existing easily-available 8-bit 
peripherals.  In contrast the 68000 had a 16-bit data bus in a more 
expensive 64-pin package.  Remember that in the 1980s glue logic was 
implemented through simple TTL chips, so adopting the 68000 might have 
doubled the number of chips on the motherboard.

In addition, the 8086 architecture was an extension of the 8080 one, 
which made it easier to make the MS-DOS API compatible with the CP/M 
one, which was used by many popular programs.  This would simplify their 
porting.  (A lot of early IBM PC software was written in assembly 
language.)  The MS-DOS 1.0 interrupts (system calls) even used the same 
numbers and structures (file control blocks - FCBs) as those used by 
CP/M.  MS-DOS 2.0 added file paths and other Unix-influenced abstractions.

[TUHS] Algol68 vs. C at Bell Labs

[Dan Cross]

On Thu, Jun 30, 2016 at 1:57 PM, Marc Rochkind <rochkind at basepath.com>
wrote:

> Dan Cross: "... even if they didn't use Unix directly, it was an existence
> proof that such a thing was possible".
>
> Indeed it was. IBM contracted with Interactive Systems (Heinz Lycklama's
> company, in Santa Monica) to produce PC/IX, which was complete System 3 for
> the IBM PC. 8088, 4.77MHz, and 512K of RAM (if I'm remembering the numbers
> correctly). It was my primary development system for the first edition of
> Advanced UNIX Programming.
>
> As for why "IBM" didn't do something other than MS-DOS originally: It
> depends what you mean by "IBM". The PC was not originally strategic,
> although it might have become that way after a few years. It was just a
> small group in Boca Raton (as I recall) that whipped it out pretty quickly.
> MS-DOS was a good choice within the class of what then were known as
> personal computer operating systems (CP/M being the leader for 8080/Z80
> Intel systems).
>
> I don't think PC/IX would have run on a floppy-only system. And, if it
> would, it would have been a demonstration only--entirely impractical. IBM
> didn't provide a PC with a hard drive until later, and that's when PC/IX
> came along.
>
> Don't forget that the IBM PC completely dominated office use where
> personal computers were needed. A runaway success. That makes me think that
> the technical solutions were correct for what the project was supposed to
> achieve.
>
> When I tried to write responsive software for UNIX and UNIX-like OSes
> running on PCs, I could never achieve good results because the display
> support was inadequate. Typically, you treated the display like a terminal
> (escape sequences). MS-DOS allowed me to write to display memory directly,
> which what was made PC software so responsive.
>
> To say it another way, UNIX on a PC was always just a port. No
> consideration was given to providing support for the way PCs were actually
> used. That didn't happen until Xerox PARC started to produce PCs (at a much
> higher cost, of course). The first decent "PC" was the Macintosh SE. The
> earlier Macs were dogs.
>

Sorry, I don't think I was being clear in my earlier post. I get that IBM
(for the definition that is the group that built the PC) did not ship a
Unix port and frankly probably wouldn't have. But what irks me is that they
didn't produce an ersatz operating system that could support Unix-like
functionality: for example, support multiple processes, have a real
system-call interface, etc. In other words, why didn't they have a more
capable kernel than MS-DOS? Surely a motivated team could have produced a
floppy-only system capable of running multiple processes, etc. It wouldn't
be Unix, it wouldn't even necessarily be a clone of Unix, but it could have
been something better than MS-DOS.

My impression was that DOS programmers had to jump through a lot of hoops
due to the anemia of the "INT 21h" services, the memory model of the
8088/8086, and lack of a system-standard programming library: I suspect a
lot of them ended up using DOS as little more than a filesystem. Consider
the display issue you mention: as I understand it, programmers could
interact with the display adapter by simply reading and writing to
well-known addresses (did this require special IO instructions? I don't
believe so). Suppose instead that the OS provided a "system call" to "map"
the display memory into one's process and return a small structure
describing it (e.g., base pointer, rows, columns, a bitmap of capabilities
[color and so on]), or -1 on failure. If the mapping were successful, the
programmer could indirect through this pointer and treat the display as one
would in DOS (perhaps with a library to facilitate application
development). On the 8088 that wouldn't be protected, of course, so it
could be bypassed but the 80286 came along fairly shortly after and had an
on-chip MMU with protected mode. Again, it doesn't have to be Unix, but DOS
didn't really help the programmer a lot here as far as I can tell.

I'm not sure I would assert that their success was due to good technical
decisions; this was the era where IBM dominated business and as the saying
went, "no one ever got fired for buying IBM." The IBM brand added de facto
legitimacy to the personal computer in the workplace at a critical time
when it was just starting to make inroads into business: surely their
success had a lot more to do with that than choosing to use the 8088 and
DOS? The VHS vs. Betamax argument may apply here.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/a0d66b45/attachment-0001.html>

[TUHS] Algol68 vs. C at Bell Labs

[Steve Nickolas]

On Thu, 30 Jun 2016, John Cowan wrote:

> Dan Cross scripsit:
>
>> I've never understood why IBM didn't just write a real OS in a
>> high-level language instead of saddling the world with MS-DOS.
>
> I think because to IBM "a real OS" meant MVS.  The difference between
> Unix and MS-DOS simply wasn't visible to them.

And perhaps even less so when MS-DOS picked up a few of Xenix's features 
for 2.0 (mainly file i/o with Unix-like semantics, but FIND was a 
stripped-down version of "fgrep", and several of the new commands in 2.0 
were certainly derived from Unix...or even BSD), although to anyone who 
actually knew anything, that's about where the similarity ended.

-uso.

[TUHS] Algol68 vs. C at Bell Labs

[Marc Rochkind]

Dan Cross: "... even if they didn't use Unix directly, it was an existence
proof that such a thing was possible".

Indeed it was. IBM contracted with Interactive Systems (Heinz Lycklama's
company, in Santa Monica) to produce PC/IX, which was complete System 3 for
the IBM PC. 8088, 4.77MHz, and 512K of RAM (if I'm remembering the numbers
correctly). It was my primary development system for the first edition of
Advanced UNIX Programming.

As for why "IBM" didn't do something other than MS-DOS originally: It
depends what you mean by "IBM". The PC was not originally strategic,
although it might have become that way after a few years. It was just a
small group in Boca Raton (as I recall) that whipped it out pretty quickly.
MS-DOS was a good choice within the class of what then were known as
personal computer operating systems (CP/M being the leader for 8080/Z80
Intel systems).

I don't think PC/IX would have run on a floppy-only system. And, if it
would, it would have been a demonstration only--entirely impractical. IBM
didn't provide a PC with a hard drive until later, and that's when PC/IX
came along.

Don't forget that the IBM PC completely dominated office use where personal
computers were needed. A runaway success. That makes me think that the
technical solutions were correct for what the project was supposed to
achieve.

When I tried to write responsive software for UNIX and UNIX-like OSes
running on PCs, I could never achieve good results because the display
support was inadequate. Typically, you treated the display like a terminal
(escape sequences). MS-DOS allowed me to write to display memory directly,
which what was made PC software so responsive.

To say it another way, UNIX on a PC was always just a port. No
consideration was given to providing support for the way PCs were actually
used. That didn't happen until Xerox PARC started to produce PCs (at a much
higher cost, of course). The first decent "PC" was the Macintosh SE. The
earlier Macs were dogs.

--Marc



On Thu, Jun 30, 2016 at 11:07 AM, John Cowan <cowan at mercury.ccil.org> wrote:

> Dan Cross scripsit:
>
> > I've never understood why IBM didn't just write a real OS in a
> > high-level language instead of saddling the world with MS-DOS.
>
> I think because to IBM "a real OS" meant MVS.  The difference between
> Unix and MS-DOS simply wasn't visible to them.
>
> --
> John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
> Don't be so humble.  You're not that great.
>         --Golda Meir
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/cad6cee3/attachment.html>

[TUHS] Algol68 vs. C at Bell Labs

[Nelson H. F. Beebe]

Ori Idan <ori at helicontech.co.il> asks today:

>> Pascal compiler written in Pascal? how can I compile the compiler it I
>> don't yet have a pascal compiler? :-)

You compile the code by hand into assembly language for the CDC
6400/6600 machines, and bootstrap that way: see

	Urs Ammann
	On Code Generation in a PASCAL Compiler
	http://dx.doi.org/10.1002/spe.4380070311

	Niklaus Wirth
	The Design of a PASCAL Compiler
	http://dx.doi.org/10.1002/spe.4380010403

It has been a long time since I read those articles in the journal
Software --- Practice and Experience, but my recollection is that they
wrote the compiler in a minimal subset of Pascal needed to do the job,
just to ease the hand-translation process.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

[TUHS] Algol68 vs. C at Bell Labs

[John Cowan]

Dan Cross scripsit:

> I've never understood why IBM didn't just write a real OS in a
> high-level language instead of saddling the world with MS-DOS.

I think because to IBM "a real OS" meant MVS.  The difference between
Unix and MS-DOS simply wasn't visible to them.  

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Don't be so humble.  You're not that great.
        --Golda Meir

[TUHS] Algol68 vs. C at Bell Labs

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3576 bytes --]

On Thu, Jun 30, 2016 at 11:49 AM, Larry McVoy <lm at mcvoy.com> wrote:

> On Thu, Jun 30, 2016 at 11:32:08AM -0400, Dan Cross wrote:
> > MC68000 vs Intel 8088 seems like a no-brainer: the 68k is the superior
> > chip. From a business perspective, I guess it was a very different
> matter,
>
​Yup - you take what you can get.  And if Moto is not doing to sell it you
when you are designing a new system.​




> > but that's not my area and the ship has long sailed over the horizon.
> > Still, it's fun to speculate and I can't help but think that a 68k-based
> > IBM PC would have been a nicer machine.
>
> +1
>
​+1  And  I suspect so many fewer problems would have ensued.   At least
linear addressing would have been de rigueur from day 1;-)
​

>
> > Something I never understood about the IBM PC: even the 8088 machine was
> > fairly beefy compared to e.g. a PDP-11/20. The 6th Edition Unix kernel
> was
> > objectively pretty small and understandable; mini-Unix showed that that
> > sort of software could be used on a machine without an MMU. I've never
> > understood why IBM didn't just write a real OS in a high-level language
> > instead of saddling the world with MS-DOS. Perhaps it's naive of me, but
> > even if they didn't use Unix directly, it was an existence proof that
> such
> > a thing was possible. I suppose, again, it was less a technical issue and
> > more a business issue, or perhaps I'm underestimating the amount of work
> or
> > missing some of the technical complexities.
>
> I wonder if they just didn't know.

​Possible -- ignorance of that team would have been high, certainly at the
managerial layers.   You might ask Guy Sotomayer who showed up in Boca soon
after the release if not before it.   Guy certainly knew UNIX (he was one
of my lab partners at CMU​) and I'm sure a number of his peers did also.




> Unix was Bell Labs and Universities for
> ​ ​
> the most part.

​Mumble, IBM was selling to universities and has a strong on-site presence
at MIT (that's were VM came from).   Boca was doing stuff with 8085s and
this was "entry systems" so I think the field of view was a lot more
shallow.​   But parts of IBM knew about UNIX and TOPS-10.   One of Guy and
my other lab partners was Chris Pathe', who graduated from CMU to work for
IBM, but programming DEC systems for them.   They hired him because he knew
TOPS and UNIX, *etc.*



> Was the timing such that they may not have been aware of
> Unix?  Or maybe they knew about Unix but thought it was for the vax?

Stuff I have read said that IBM wanted to compete originally with S-100
type systems with this new system.   Hence the famous desire for CP/M​.
They always were primarily buying the SW from firms that had built SW for
microprocessors.  And, if I understand the history pieces that have been
published, the project was financed by large systems, that wanted to system
to run VisiCalc, which was a hit in financial circles.   But large systems
team were not doing much the SW themselves for these boxes.  It >>seems<<
like IBM was thinking about SW in terms of very large machines so even
PDP-11's were small in those days.  That said their marketing folks for the
PC, put the focus on 16 bits was because they wanted to be "better" than
the 8-bit 8080/8085/Z80 that was the S-100 standard or the 6502 in the
Apple II.   Hence, Moto pushing an 8-bit chip was rejected.


​Clem​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/fa5ba429/attachment.html>

[TUHS] Algol68 vs. C at Bell Labs

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

Marc Rochkind <rochkind at basepath.com> wrote:

> Bill Cheswick: "What a different world it would be if IBM had selected the
> M68000 and UCSD Pascal.  Both seemed
> to me to better better choices at the time."
>
> Not for those of us trying to write serious software. The IBM PC came out
> in August, 1981, and I left Bell Labs to write software for it full time
> about 5 months later. At the time, it seemed to me to represent the future,
> and that turned out to be a correct guess.

I worked on a "Microengine" in 1979.

The Microengine was a micro PDP-11 with a modified micro code ROM that directly 
supported to execute p-code.

The machine was running a UCSD pascal based OS and was really fast and powerful.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'

[TUHS] Algol68 vs. C at Bell Labs

[Larry McVoy]

On Thu, Jun 30, 2016 at 11:32:08AM -0400, Dan Cross wrote:
> MC68000 vs Intel 8088 seems like a no-brainer: the 68k is the superior
> chip. From a business perspective, I guess it was a very different matter,
> but that's not my area and the ship has long sailed over the horizon.
> Still, it's fun to speculate and I can't help but think that a 68k-based
> IBM PC would have been a nicer machine.

+1

> Something I never understood about the IBM PC: even the 8088 machine was
> fairly beefy compared to e.g. a PDP-11/20. The 6th Edition Unix kernel was
> objectively pretty small and understandable; mini-Unix showed that that
> sort of software could be used on a machine without an MMU. I've never
> understood why IBM didn't just write a real OS in a high-level language
> instead of saddling the world with MS-DOS. Perhaps it's naive of me, but
> even if they didn't use Unix directly, it was an existence proof that such
> a thing was possible. I suppose, again, it was less a technical issue and
> more a business issue, or perhaps I'm underestimating the amount of work or
> missing some of the technical complexities.

I wonder if they just didn't know.  Unix was Bell Labs and Universities for
the most part.  Was the timing such that they may not have been aware of 
Unix?  Or maybe they knew about Unix but thought it was for the vax?

[TUHS] Algol68 vs. C at Bell Labs

[Dan Cross]

On Jun 30, 2016 10:10 AM, "Marc Rochkind" <rochkind at basepath.com> wrote:

> Bill Cheswick: "What a different world it would be if IBM had selected
> the M68000 and UCSD Pascal.  Both seemed
> to me to better better choices at the time."
>
> Not for those of us trying to write serious software. The IBM PC came out
> in August, 1981, and I left Bell Labs to write software for it full time
> about 5 months later. At the time, it seemed to me to represent the future,
> and that turned out to be a correct guess.
>
> Microsoft Basic is well known as the primary initial language for the PC,
> but from day one there was another choice called Microsoft Pascal (we used
> the IBM Pascal version). It was a considerable extension over classical
> Pascal. It had full-blown string manipulation and pointers. With it, I was
> able to implement a text editor called EDIX and an nroff-ripoff called
> WORDIX. The compiler was full of bugs, but it was a true compiler, and the
> programs were small enough and fast enough to work well on the limited 8088
> (I think that was the processor) hardware.
>

I don't know about UCSD Pascal versus MS-DOS, but I think you yourself just
alluded to the processor distinction that Ches was referring to. Of course
it's only of historical interest now, but from a technology standpoint
MC68000 vs Intel 8088 seems like a no-brainer: the 68k is the superior
chip. From a business perspective, I guess it was a very different matter,
but that's not my area and the ship has long sailed over the horizon.
Still, it's fun to speculate and I can't help but think that a 68k-based
IBM PC would have been a nicer machine.

Initially, with no hard drive, I had to switch floppies several times just
> to compile one file. Later, I got a 6MB hard drive for about $3000.
> Interestingly, that drive could not even hold one (raw) image from my
> current digital camera!
>
> We could not have used Microsoft Basic or UCSD Pascal.
>
> Just a few years later, something called Lattice C came along, and we
> switched (back) to C, and stayed with it from there on out.
>

Something I never understood about the IBM PC: even the 8088 machine was
fairly beefy compared to e.g. a PDP-11/20. The 6th Edition Unix kernel was
objectively pretty small and understandable; mini-Unix showed that that
sort of software could be used on a machine without an MMU. I've never
understood why IBM didn't just write a real OS in a high-level language
instead of saddling the world with MS-DOS. Perhaps it's naive of me, but
even if they didn't use Unix directly, it was an existence proof that such
a thing was possible. I suppose, again, it was less a technical issue and
more a business issue, or perhaps I'm underestimating the amount of work or
missing some of the technical complexities.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/edfb7e55/attachment-0001.html>

[TUHS] Algol68 vs. C at Bell Labs

[Ori Idan]

On Thu, Jun 30, 2016 at 5:57 PM, Joerg Schilling <schily at schily.net> wrote:

> William Cheswick <ches at cheswick.com> wrote:
>
> > On the other hand, there was
> > no excuse for a Pascal compiler to be either large, buggy, or slow, even
> before Turbo Pascal.
>
> Large?
>
> The original Wirth pascal compiler source was 1800 lines of pascal code.
>

Pascal compiler written in Pascal? how can I compile the compiler it I
don't yet have a pascal compiler? :-)

Ori Idan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/ec8dbba7/attachment.html>

[TUHS] Algol68 vs. C at Bell Labs

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 527 bytes --]

William Cheswick <ches at cheswick.com> wrote:

> On the other hand, there was
> no excuse for a Pascal compiler to be either large, buggy, or slow, even before Turbo Pascal.

Large?

The original Wirth pascal compiler source was 1800 lines of pascal code.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'

[TUHS] Algol68 vs. C at Bell Labs

[Ronald Natalie]

> 
> On the other hand, there was
> no excuse for a Pascal compiler to be either large, buggy, or slow, even before Turbo Pascal.
> 
I remember the Pascal computer on my Apple II used to have to use some of the video memory while it was running.

[TUHS] Algol68 vs. C at Bell Labs

[William Cheswick]

I understand there were a number of problems that went the other way.  Motorola dropped the ball, software
was buggy, and IBM needed an immediate answer.

On the other hand, there was
no excuse for a Pascal compiler to be either large, buggy, or slow, even before Turbo Pascal.


> On 30Jun 2016, at 10:05 AM, Marc Rochkind <rochkind at basepath.com> wrote:
> 
> Not for those of us trying to write serious software. The IBM PC came out in August, 1981, and I left Bell Labs to write software for it full time about 5 months later. At the time, it seemed to me to represent the future, and that turned out to be a correct guess.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/f2d058b2/attachment.html>

[TUHS] Algol68 vs. C at Bell Labs

[Marc Rochkind]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6020 bytes --]

Bill Cheswick: "What a different world it would be if IBM had selected the
M68000 and UCSD Pascal.  Both seemed
to me to better better choices at the time."

Not for those of us trying to write serious software. The IBM PC came out
in August, 1981, and I left Bell Labs to write software for it full time
about 5 months later. At the time, it seemed to me to represent the future,
and that turned out to be a correct guess.

Microsoft Basic is well known as the primary initial language for the PC,
but from day one there was another choice called Microsoft Pascal (we used
the IBM Pascal version). It was a considerable extension over classical
Pascal. It had full-blown string manipulation and pointers. With it, I was
able to implement a text editor called EDIX and an nroff-ripoff called
WORDIX. The compiler was full of bugs, but it was a true compiler, and the
programs were small enough and fast enough to work well on the limited 8088
(I think that was the processor) hardware.

Initially, with no hard drive, I had to switch floppies several times just
to compile one file. Later, I got a 6MB hard drive for about $3000.
Interestingly, that drive could not even hold one (raw) image from my
current digital camera!

We could not have used Microsoft Basic or UCSD Pascal.

Just a few years later, something called Lattice C came along, and we
switched (back) to C, and stayed with it from there on out.

--Marc

On Thu, Jun 30, 2016 at 7:22 AM, Clem Cole <clemc at ccc.com> wrote:

> Steve - good stuff.   comments below.
>
> On Wed, Jun 29, 2016 at 11:17 AM, <scj at yaccman.com> wrote:
>
>> But the documentation was a huge barrier
>
> ​Amen​ - I remember trying to read the report and getting utterly
> befuddled.
>
>
>
>> --all the
>> ​ ​
>> familiar ideas were given completely new (and unintuitive) names, making
>> ​ ​
>> it very difficult to get into.
>>
> ​And as importantly, it was not clear to many of us what we were getting
> for all that stuff.   Was it sugar or really going to help?​    C, BLISS,
> PL/360, BCPL et al, took a much more minimalist view.   Algol68 seems like
> it was the "one ring to rule them all" but how could you be sure?
>
>
>
>>
>> I may be biased in my view, but I think one fatal mistake that A68 made
>> was that it had no scheme for porting the language to the plethora of
>> computers and systems around at that time.
>
> ​I would put this this a little differently.   To me it was not so much
> that there was or was not a scheme to move the language, but it was not
> economical to try.​   Between your and Dennis's compilers, which were both
> "reachable" by many of us, when we needed a language and compiler for
> these new microprocessors that were becoming prevalent at the same time, we
> had the sources for your compilers and it was "just a matter of a new back
> end."
>
>
>
>> (The Bliss language from CMU
>> ​ ​
>> had a similar problem, requiring a bigger computer to compile for the
>> ​ ​
>> PDP-11).
>
> ​While true, I'm not so sure that was the real problem with BLISS.  I
> really think it was that CMU sold the language to DEC and compiler sources
> were not available to people.   I've always said if DEC had given away the
> BLISS compiler and made the sources available in the same manner as C (or
> Pascal for that matter), folks like me would have been tempted to use it
> write a backend for the 68K (Z8000, 8086 much less the 8-bit micros).​
>
> I also think the size issue could have been (and would have been) fixed if
> it was worth it.   But it was not.  The requirement of needing a PDP-10 (or
> later Vax) to run was due to the small address space of the PDP-11 and the
> amazing things that the BLISS optimizer did.   But you are correct - that
> was never done, so it certainly added why BLISS never went very far.
>
> My own experience was simple. At Tektronix, in the late 1970's I was given
> a chip that would become the 68K (it was yet to be numbered by Motorola at
> that point) and I wanted a HLL for the system we started to make with it
> (what would later be called Magnolia).  As a V6 (and later V7) licensee, I
> had the sources to the Ritchie compiler.  I knew both BLISS and C (as well
> as Algol/Pascal/FTN/PL-1 et,), and I admit in those days still had a
> fondness for the former as a CMU grad and Bill Wulf student.   But I did
> not have any of the CMU tools (PQCC et al) much less the DEC ones (and you
> are correct, I ould get access to the PDP-10, but I had a couple of UNIX
> boxes available).  So, I had your tools and they worked well.   Thus,
> I wrote a back end for my project for that chip.  It was that simple.   It
> was pure economics.
>
>
>
>
>> Pascal had P-code, and gave C a real run, especially as a
>> teaching language.
>
> ​Right, Pascal had a number of generally available compilers, with P-Code
> being the most used.​  It was as economical as C to work.   And a lot of
> people used it.  While I liked it as a teaching language, it was useless as
> a production language unless you hacked on it and extended it.  And as
> importantly for me, it could not be used as a "systems" language as it.  In
> fact, at that time Tektronix has at least 6 different but incompatible
> flavors of "Tek Pascal." It was language of choice in the product teams
> (BTW, our friends and rivals had over 20 flavors of HP BASIC in those days
> too).
>
> I picked C because I could and I knew my PDP-11 code would pretty much
> just work on this new device.   Admittedly "proof by lack of imagination"
> reined here, but I really could not image trying to use Pascal to write an
> OS.    I knew I could with BLISS or C.
>
>
>
>
>> Nowadays, newer languages like Python just piggyback on C or C++...
>
> ​Hmm... I would say piggyback on the C ecosystem - i.e. GCC (or now LLVM).​
>
> ​Clem​
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/fa076930/attachment-0001.html>

[TUHS] Algol68 vs. C at Bell Labs

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1221 bytes --]

On Thu, Jun 30, 2016 at 9:18 AM, William Cheswick <ches at cheswick.com> wrote:

> What a different world it would be if IBM had selected the M68000


​Blame that on Moto, not IBM.  IBM wanted the 68K.   But Moto kept pushing
the 6809 on them.    IBM and Tek were two of the sites that had the
experimental chip that I was referring.  My friend Les Crudele related the
story of IBM visiting Austin (Les and Nick Tredenick were the primary 68K
guys).  It seems IBM wanted to use the new chip and Moto marketing kept
telling them it was an experiment and was not a product.  The cool new
product from Moto was the 6809 and they should use that.   IBM knew they
wanted a 16bit processor which it was not, so they looked elsewhere.

Then again, I might have my current job if Moto marketing not been so short
sighted.

Clem

PS  BTW:  Les has equally great stories about working with Apple BTW.  My
favorite is that he says, Moto tried to get Apple to put a MMU into the
original Mac, but Job's would not hear of it.  Not needed for a PC and all
that.
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/ea3dd579/attachment.html>

[TUHS] Algol68 vs. C at Bell Labs

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4371 bytes --]

Steve - good stuff.   comments below.

On Wed, Jun 29, 2016 at 11:17 AM, <scj at yaccman.com> wrote:

> But the documentation was a huge barrier

​Amen​ - I remember trying to read the report and getting utterly befuddled.



> --all the
> ​ ​
> familiar ideas were given completely new (and unintuitive) names, making
> ​ ​
> it very difficult to get into.
>
​And as importantly, it was not clear to many of us what we were getting
for all that stuff.   Was it sugar or really going to help?​    C, BLISS,
PL/360, BCPL et al, took a much more minimalist view.   Algol68 seems like
it was the "one ring to rule them all" but how could you be sure?



>
> I may be biased in my view, but I think one fatal mistake that A68 made
> was that it had no scheme for porting the language to the plethora of
> computers and systems around at that time.

​I would put this this a little differently.   To me it was not so much
that there was or was not a scheme to move the language, but it was not
economical to try.​   Between your and Dennis's compilers, which were both
"reachable" by many of us, when we needed a language and compiler for these
new microprocessors that were becoming prevalent at the same time, we had
the sources for your compilers and it was "just a matter of a new back
end."



> (The Bliss language from CMU
> ​ ​
> had a similar problem, requiring a bigger computer to compile for the
> ​ ​
> PDP-11).

​While true, I'm not so sure that was the real problem with BLISS.  I
really think it was that CMU sold the language to DEC and compiler sources
were not available to people.   I've always said if DEC had given away the
BLISS compiler and made the sources available in the same manner as C (or
Pascal for that matter), folks like me would have been tempted to use it
write a backend for the 68K (Z8000, 8086 much less the 8-bit micros).​

I also think the size issue could have been (and would have been) fixed if
it was worth it.   But it was not.  The requirement of needing a PDP-10 (or
later Vax) to run was due to the small address space of the PDP-11 and the
amazing things that the BLISS optimizer did.   But you are correct - that
was never done, so it certainly added why BLISS never went very far.

My own experience was simple. At Tektronix, in the late 1970's I was given
a chip that would become the 68K (it was yet to be numbered by Motorola at
that point) and I wanted a HLL for the system we started to make with it
(what would later be called Magnolia).  As a V6 (and later V7) licensee, I
had the sources to the Ritchie compiler.  I knew both BLISS and C (as well
as Algol/Pascal/FTN/PL-1 et,), and I admit in those days still had a
fondness for the former as a CMU grad and Bill Wulf student.   But I did
not have any of the CMU tools (PQCC et al) much less the DEC ones (and you
are correct, I ould get access to the PDP-10, but I had a couple of UNIX
boxes available).  So, I had your tools and they worked well.   Thus,
I wrote a back end for my project for that chip.  It was that simple.   It
was pure economics.




> Pascal had P-code, and gave C a real run, especially as a
> teaching language.

​Right, Pascal had a number of generally available compilers, with P-Code
being the most used.​  It was as economical as C to work.   And a lot of
people used it.  While I liked it as a teaching language, it was useless as
a production language unless you hacked on it and extended it.  And as
importantly for me, it could not be used as a "systems" language as it.  In
fact, at that time Tektronix has at least 6 different but incompatible
flavors of "Tek Pascal." It was language of choice in the product teams
(BTW, our friends and rivals had over 20 flavors of HP BASIC in those days
too).

I picked C because I could and I knew my PDP-11 code would pretty much just
work on this new device.   Admittedly "proof by lack of imagination" reined
here, but I really could not image trying to use Pascal to write an OS.
 I knew I could with BLISS or C.




> Nowadays, newer languages like Python just piggyback on C or C++...

​Hmm... I would say piggyback on the C ecosystem - i.e. GCC (or now LLVM).​

​Clem​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160630/f8c8ad8f/attachment-0001.html>

[TUHS] Algol68 vs. C at Bell Labs

[William Cheswick]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1636 bytes --]

What a different world it would be if IBM had selected the M68000 and UCSD Pascal.  Both seemed
to me to better better choices at the time.

> On 30Jun 2016, at 9:15 AM, David <david at kdbarto.org> wrote:
> 
> 
>> From: Dave Horsfall <dave at horsfall.org>
>> 
>> On Wed, 29 Jun 2016, scj at yaccman.com wrote:
>> 
>>> Pascal had P-code, and gave C a real run, especially as a teaching 
>>> language.
>> 
>> Something I picked up at Uni was that Pascal was never designed for 
>> production use; instead; you debugged your algorithm in it, then ported it 
>> to your language of choice.
> 
> I was an active member of the UCSD Pascal project from 77 to 80, and then was with SofTech MicroSystems for a couple years after that.
> 
> An unwritten legacy of the Project was that, according to Professor Ken Bowles, IBM wanted to use UCSD Pascal as the OS for their new x86 based personal computer. The license was never worked out as the University of California got overly involved in it. As a result IBM went with their second choice, some small Redmond based company no one had ever heard of. So it was intended and, at least IBM thought, it was good enough for production use.
> 
> I also knew of UCSD Pascal programs written to do things such as dentist office billing and scheduling and other major ‘real world’ tasks. So it wasn’t just an academic project.
> 
> I still have UCSD Pascal capable of running in a simulator, though I’ve not run it in a while. And I have all the source for the OS and interpreter for the Version I.5 and II.0 systems. Being a code pig just means that I need a lot of disk space.
> 
> 	David

[TUHS] Algol68 vs. C at Bell Labs

[David]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1394 bytes --]


> From: Dave Horsfall <dave at horsfall.org>
> 
> On Wed, 29 Jun 2016, scj at yaccman.com wrote:
> 
>> Pascal had P-code, and gave C a real run, especially as a teaching 
>> language.
> 
> Something I picked up at Uni was that Pascal was never designed for 
> production use; instead; you debugged your algorithm in it, then ported it 
> to your language of choice.

I was an active member of the UCSD Pascal project from 77 to 80, and then was with SofTech MicroSystems for a couple years after that.

An unwritten legacy of the Project was that, according to Professor Ken Bowles, IBM wanted to use UCSD Pascal as the OS for their new x86 based personal computer. The license was never worked out as the University of California got overly involved in it. As a result IBM went with their second choice, some small Redmond based company no one had ever heard of. So it was intended and, at least IBM thought, it was good enough for production use.

I also knew of UCSD Pascal programs written to do things such as dentist office billing and scheduling and other major ‘real world’ tasks. So it wasn’t just an academic project.

I still have UCSD Pascal capable of running in a simulator, though I’ve not run it in a while. And I have all the source for the OS and interpreter for the Version I.5 and II.0 systems. Being a code pig just means that I need a lot of disk space.

	David

[TUHS] Algol68 vs. C at Bell Labs

[arnold]

arnold at skeeve.com wrote:

> Yes and know; GCC has a number of front-ends, in various stage of

Not enough sleep. Obviously "yes and no". Sorry.

[TUHS] Algol68 vs. C at Bell Labs

[arnold]

scj at yaccman.com wrote:

> Nowadays, newer languages like Python just piggyback on C or C++...

Yes and know; GCC has a number of front-ends, in various stage of
production worthiness. Besides C and C++ the Ada front end is full
production quality.  I think Fortran and Java are at lower levels; there
are also D, Go, and Pascal front ends.

There is a trend back towards compiled languages. Of note: D, Go, and Rust.

For whatever it's worth. :-)

Arnold

[TUHS] Algol68 vs. C at Bell Labs

[John Cowan]

scj at yaccman.com scripsit:

> Steve Bourne tried hard to interest us in A68, and I personally liked some
> features of it (especially the automatic type morphing of arguments into
> the expected types).  But the documentation was a huge barrier--all the
> familiar ideas were given completely new (and unintuitive) names, making
> it very difficult to get into.

I heartily agree.  That and the van Wijngaarden grammar were serious
roadblocks to understanding, though such grammars are themselves very
elegant, especially in the form used by the Revised Report.

> I may be biased in my view, but I think one fatal mistake that A68 made
> was that it had no scheme for porting the language to the plethora of
> computers and systems around at that time.  (The Bliss language from CMU
> had a similar problem, requiring a bigger computer to compile for the
> PDP-11).  Pascal had P-code, and gave C a real run, especially as a
> teaching language.  C had PCC.

Indeed.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
That you can cover for the plentiful and often gaping errors, misconstruals
and disinformation in your posts through sheer volume -- that is another
misconception.  --Mike to Peter

[TUHS] Algol68 vs. C at Bell Labs

[Dave Horsfall]

On Wed, 29 Jun 2016, scj at yaccman.com wrote:

> Pascal had P-code, and gave C a real run, especially as a teaching 
> language.

Something I picked up at Uni was that Pascal was never designed for 
production use; instead; you debugged your algorithm in it, then ported it 
to your language of choice.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Algol68 vs. C at Bell Labs

[scj]

Steve Bourne tried hard to interest us in A68, and I personally liked some
features of it (especially the automatic type morphing of arguments into
the expected types).  But the documentation was a huge barrier--all the
familiar ideas were given completely new (and unintuitive) names, making
it very difficult to get into.

I may be biased in my view, but I think one fatal mistake that A68 made
was that it had no scheme for porting the language to the plethora of
computers and systems around at that time.  (The Bliss language from CMU
had a similar problem, requiring a bigger computer to compile for the
PDP-11).  Pascal had P-code, and gave C a real run, especially as a
teaching language.  C had PCC.

Nowadays, newer languages like Python just piggyback on C or C++...