From: jimf@centerline.com (Jim Frost)
Subject: Re: The need for an assembler (was: Favorite CPU)
Organization: CenterLine Software, Inc.
Date: Mon, 31 Aug 1992 19:07:27 GMT

lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>Any architecture worth investing effort in generally stays around for awhile;
>I think a consensus was reached for a number around 15 years.  This tends to
>squelch the arguments about "porting" difficulties in assembler.

Well, I can think of a lot of arguments against that, but let's tackle
the 15 year lifespan.

Has the PC architecture really remained static for the eleven years of
its existence?  Meaning, could a program I wrote eleven years ago run
optimally on today's hardware?

No.  Why not?

The base CPU has undergone two major architectural changes.  While a
backwards-compatibility mode exists, it is inefficient to use compared
to software written to the particular CPU architecture.  For system
software the new CPU's provide functionality which cannot even be
emulated on the older CPU's.

There are three new I/O busses that take advantage of improved
throughput of newer processors.  Anything that uses the original 8-bit
bus is hopelessly underutilizing the hardware.

There have been four major improvements in the video subsystem (not
including the many high-end systems).  Most have been backward
compatible to some degree, but to fully utilize the system you needed
to make major changes to the way you utilize the video hardware at
each new introduction.

Fixed disk subsystems are now requisite although they didn't even
exist at the introduction of the machine.  Several major variations in
fixed disk adapters exist and lots of minor variations for disk
architecture.

The MS-DOS operating system has undergone several major changes that
cause software incompatibility.  Recently the changes have only
introduced minor incompatibilities, but that was not so at the
introduction of MS-DOS 2.0.  A program written to MS-DOS 1.0 isn't
efficient under the newer versions of MS-DOS (I'd be surprised to find
that it would run at all, actually).

Most systems nowadays run Windows 3.1, which is somewhat incompatible
with Windows 3.0, which is quite incompatible with Windows 2.0, and
all of which are totally different than running under standalone
MS-DOS.  Any application targetted for the 8086 under MS-DOS will
underutilize the system software of a Windows machine.

In the next year we'll have Windows NT which will be incompatible to
some degree with Windows 3.X, but which will provide many capabilities
that most PC users have never seen.  Applications will need to be
changed in major ways to take advantage of these new capabilities.
Applications which do not will be underutilizing the available
resources.

So, do you consider today's 80486 EISA bus machine with a Super VGA
adapter, SCSI disks, and a mouse, running Windows NT, to be the same
architecture as the original PC?  Or have applications needed to
undergo changes to run well (or at all!) on the newer machines and
newer operating systems?

It might have seemed like it's all the same architecture to you, but
in reality you've been adjusting to a changing architecture without
really thinking about it.  Just imagine what would have happened if
they changed the CPU on you so that you no longer could run 8086 code.
Part of the goal of Windows NT is to dissociate from the 80x86 CPU to
take advantage of newer, faster CPU designs, so it's happening as we
speak.

The IBM PC hasn't remained architecturally stable for more than three
years, if that long.  You can still run the same instructions, but at
low efficiency relative to the potential of the CPU and so long as you
didn't utilize the full capabilities of the I/O subsystems or the OS.
And the PC isn't even fifteen yet.

The PC isn't alone; no architecture that I'm aware of remained
constant for fifteen years.  Most don't even remain constant for five
years, although many provide backward compatibility -- at the cost of
underutilizing the new hardware -- for many years beyond that.  The PC
is one such example, as is the IBM 360.

>Moreover,
>there are insidious differences in C implementations that are *almost* the
>same, which causes true havoc to a maintainer of programs across multiple
>and thoroughly incompatible systems where the only measure of compatibility
>is the *hope* of C compatibility which may not quite measure up.

That's true, but that's because of the proliferation of C on totally
different architectures.  You get hit by it more than most because of
the brain-dead segmented architecture on the PC; most C
implementations don't differ quite that much.  I know, I've personally
used more than twenty different C compilers on almost as many
architectures.  Most C portability problems occur due to differences
in the OS, not in the compiler.

>Sometimes it's easier to totally rewrite the code for the new environment,
>since you know afresh all of the new situation's requirements :-).

Sure, if you have the time.  If your application is more than a few
thousand lines you won't have the time to completely recode and debug
it before a competitor eats your lunch for you.  That's life in the
big city.

jim frost
jimf@centerline.com