C integral types [was Re: Semi-OT: Why Kids Can't use Computers] (fwd)

Lennart Sorensen lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org
Tue Aug 20 20:11:19 UTC 2013


On Tue, Aug 20, 2013 at 02:23:26PM -0400, D. Hugh Redelmeier wrote:
> In the era when the 286 was current?
> 
> Lots of big businesses built infrastructure based on OS/2 since they
> were promised that it was the future.  IT departments fell for it.
> Banks, ATM networks, Oil companies come to mind.

Yes in the era of the 286 there were some that bet on OS/2 and many of
those systems ran for years, long after OS/2 was pretty dead.

> Right.  I should have qualified the statement somehow.  They innovated
> quickly in things that they thought they could market in the short
> term.
> 
> Long-term thinking was reserved for Microsoft, Intel, IBM and various
> other companies that we've forgotten because it killed them.  That's
> the way monopoly markets work.

Well it seems it was companies like 3Dfx and nvidia, creative labs,
gravis, and such that really invented neat new stuff for the PC.
intel just made it fast, microsoft made it slower, and IBM didn't really
do anything after creating the thing in the first place.  It took compaq
to actually decide to put a 386 in it as a follow up to the 286.  IBM was
considering changing the architecture.

> It took years before the PC market valued multitasking.  Remember the
> horror of TSRs?

Certainly.

> The PC market was very conservative of interfaces.  Remember the A20
> fudge?  Example: because it was thought that vast amounts of PC
> software depended on the 8086's wrapping of addresses at 1MiB,
> chips/systems well into the Pentium era could be set to wrap there.
> As far as I know, there was very little software that actually broke
> without this feature.  A lot of systems broke due to this feature
> (i.e. matching A20 handlers with your hardware was non-trivial).

I remember the A20 wrapping was managed through a pin on the keyboard
controller for some silly reason.

> That one lack doesn't veto it.  Remember that the dominant alternative
> had that limitation too.

Windows NT was already vastly more capable in that regard, as were all
the unix systems.

> Why?

I remember it didn't even have a termcap for it's own console type.
Solaris on sparc worked great.  Solaris on x86 not so much.

ssh to a linux box, and the linux box knew how to deal with a solaris
x86 console, but solaris itself had no clue.  It was embarasing how
neglected the x86 version was by Sun.  They clearly didn't care about it.

> Lack of familiarity with the SVr5-ness of it?  I'm OK with that.  BSD
> has its own flaws.

I prefer to avoid BSD's concept of user space.

> Lack of drivers for your hardware?  All alternative OSes have that
> mountain to climb.

Actually it seemed to manage OK at driver support at the time.

> Right.  That was a bit of a government boondogle.  I don't know how
> the processor was chosen.  QNX ran on PC hardware initially, so maybe
> that was the deciding factory.  I think that they used the Watcom C
> compiler, also targetted at the PC.

Actually QNX may very well have been the reason.

> I guess you are referring to the segment descriptors and gate
> descriptor.  Here's an (unreferenced) wikimedia diagram
> <https://commons.wikimedia.org/wiki/File:SegmentDescriptor.svg>.  The
> parts in italic were added by the 386, and yes, the result isn't
> contiguous.  This is just annoying, not a serious problem.  That's
> kind of how things evolve: not for beauty but for function.

Many designs try to plan ahead so they don't end up with such a mess.
One would think that after extending the architecture enough times they
could start to plan ahead, but it seems intel never does.

> The Itanium was a noble experiment.  It's just that (a) they didn't
> realize it was an experiment, and (b) they poured their resources into
> the x86 battle, starving the Itanium project, and (c) they took the
> wind out of the sails (sales?) of RISC processors.

It was the second (or maybe third) time intel tried to do VLIW
architecture, and again it failed because it can't be done.  It seems
that intel kept thinking compiler developers would eventually solve the
compile time scheduling issue.  I believe I read somewhere that is has
now been proven to be unsolvable at compile time.  Maybe now intel won't
try it again.

VLIW is best left for DSPs where you have predictable workflows.

-- 
Len Sorensen
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists





More information about the Legacy mailing list