Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uxc!deimos.cis.ksu.edu!rutgers!att!westmark!mole-end!mat
From: mat@mole-end.UUCP (Mark A Terribile)
Newsgroups: comp.lang.c
Subject: Re: Portability and the Ivory Tower (was Re: Book on Microsoft C)
Summary: Back-- compatability
Message-ID: <148@mole-end.UUCP>
Date: 9 Apr 89 03:52:30 GMT
References: <754@oravax.UUCP> <225800146@uxe.cso.uiuc.edu> <9937@smoke.BRL.MIL> <42674c5e.b11a@falcon.engin.umich.edu>
Organization: mole-end--private system.  admin: mole-end!newtnews
Lines: 59

This is drifting away from C, but ...

> >Machine independent code does not imply teletype compatibility. ...

> >	Termcap.
> >	Curses.
> >	X-Windows.
> >	NeWS.

> >> ... if the application is that valuable then the ... I would ... 
> >> hold out for backward-compatible hardware.

> >And so people build backwards-compatible hardware that cripples the NEXT
> >generation of applications. Great thinking.

There was a story some years ago about a very large corporation (you've heard
of it) that owned a large number of an obsolete IBM machine of the discrete
transistor generation.  They had a large amount of important application code
written in FORTRAN with machine code represented as decimal constants in the
FORTRAN DATA statements.  IBM was coaxed (at considerable cost) into making
several thousand 1-board bit-compatible machines to keep the applications
running.

I don't know if this story is true or not, but it does point to one way in
which old, non-portable software can hobble hardware.

> ...   Backwards compatibility does not imply crippling future applications.
> That your 80286 can run 8086 software does not seem to have crippled it from
> running system III Unix. ...

Yes in the name of remaining portable, Intel was pushed into a segmented
architecture that inspired several megabytes of heated discussion.  Per unit of
silicon real estate (or per dollar) the Intel processors don't do as well as
the Motorola chips that power the Sun 3.  Memory management and segment
handling are a nightmare because the machine is meant to support half-a-dozen
mutually exclusing multiprogramming models.  And additions to the instruction
set must be squeezed into the holes in the existing instruction set, which may
mean that a new instruction must be hidden behind a prefix (extra fetches) or
may have only one or two addressing modes available (the compiler writer's
nightmare which reduces the likelyhood that the instruction will actually be
used, further reducing the payback on the costs of the instruction.)

That the Intel processors incorporate the memory management on the processor
chip ensures that if it runs on one Intel-based motherboard, it will run on
any based on the same Intel processor--a great payback and a great way to get
a market lock.  This is the reason for the Intel market lock.

> You're right, 'vi' is an excellent example.  I tried to teach a
> Mac programmer (with an MS from MIT) how to use it, and he
> thought it laughably brutal compared to even the most simple
> Mac editor.  Do you really prefer h,j,k, and l to using a mouse?

I sure do.  I can keep my fingers over the keyboard, and work one heck of
a lot faster than I can with a mouse.  Even with a trackball, vi wins.
(To spare argument, I accept the proposition that EMACS beats the mouse.)
-- 

(This man's opinions are his own.)
From mole-end				Mark Terribile