[TUHS] Algol68 vs. C at Bell Labs
crossd at gmail.com
Fri Jul 1 05:43:21 AEST 2016
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:
>> 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
- Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the TUHS