From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Newsgroups: alt.folklore.computers,comp.unix.misc
Subject: Re: The need for an assembler (was: Favorite CPU)
Date: 1 Sep 92 22:48:33 GMT
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University

In article <jimf.715288047@centerline.com> jimf@centerline.com (Jim Frost) writes:
>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.

This is a crock.  Industry acceptance of MS-DOS since the inception of
V 2.00 means that there is no such problem.  I don't use MS-DOS, I use
DR-DOS, which is a compatible superset.  Frill features of the hardware
are seamlessly added, not required.  My code just runs slightly faster; 
the alleged improvements are overblown when it comes to actual performance
improvement.  In many ways, 386's are more inefficient than 286's, and there
are 286's that clearly outperform them.  But, in all cases, my code runs there
about as best as can be expected.  No one's gonna reimplement something that
does much better.  The so-called new functionality is largely bad fluff that
most users are ignoring.  OS/2 has been called a solution seeking a problem.
In any case, I could easily recompile for protect mode if I had to, so what?

>
>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.

That's right, and totally irrelevant to what my code is doing.  However, it
does mean that you can write new software drivers for newer devices to speed
up overall operations, and this is done all the time, so what?

>
>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.

Wrong, there is only mono and color text.  They differ only in the base
address for the buffer, and are totally compatible.  Graphics programs have
to be designed for an express screen size.  All newer interfaces support all
older modes, and generally do them more quickly; this has no implication on
the quality of my code; I would do it today identically as when written N
years ago, and there simply isn't any avenue for improvement as you suggest.
What *is* available is the potential for greater-resolution applications on
the newer hardware, but that's changing the application spec, not what you
infer.

>
>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.

True, and pure smokescreen.  That's why we have BIOS calls.  All code runs
as best as can be expected as dictated by the autoconfiguration of the
O/S.  As the hardware gets better, the same exact code runs faster if it
does lotsa I/O.  The code quality isn't improvable per se, it's simply not
an issue in the slightest.  The benefits are obtained in a 100% modular way.
This applies to all running programs, even hll ones.

>
>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).

That's totally true, and it's a good thing that Version 2 came out so fast
so we wouldn't be futzing with 1.x anymore.  You might notice that virtually
every program since the days of the PC Jr require DOS 2.0 or higher.  The only
stuff that requires 3.0 or higher are programs that need to talk to 
high-density disks, which weren't introduced until version 3.0.  In any case, 
no incompatibility occured.  More importantly, no major reprogramming issues
ever arise from these upgrades, rather issues come up outside the venue of
the vast majority of programs, such as the maximum size of a system's
partitions, etc., and are only in the province of the system itself.  The
Norton Utilities are a good example of the exception you are addressing:
they have had to be upgraded a lot as the system grew, but no applications
that generally work are undergoing anything like this.

>
>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.

The only incompatibility between Windows 3.0 and 3.1 was the arbitrary dropping
of real mode because Microsoft doesn't want to support the 8086/8088 users
anymore and they are in league with planned-obsolescence companies.
The rest has to do with fixing limitations of the environment, not revamping it
as you suggest.  Windows 2.0 is totally compatible: it's the standard mode
subset of 3.x.  All programs run fine from there as well; no one is suggesting
they need to be rewritten.

>
>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.

NT is not windows, rather it's a shell on another operating system that
is fundamentally incompatible with both DOS and OS/2.  Its absurd disk
and memory requirements will likely make it an even less attractive
system OS/2.  I suspect that all it will do is sell more copies of
DR-DOS and perhaps IBM's OS/2 version 2 (which runs MS-DOS programs fine)
when people find out how gaudy and slow it is.

>
>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?

In summary, the answer is yes, the same exact environment, surrounded
by a lot of optional shit that can be 100% ignored.  Some applications
will be respecified to possibly take advantage of the newer features if
need be.  I have no reservations in writing new code to take advantage
of new features.

>
>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.

NT is a system written in C with a graphics shell.  It is not geared 
towards any particular hardware, and has been demo'd on the DEC Alpha
chip.  Thus there is no relevance to your statement.  Also, NT is going
to have to compete with a whole lot of other systems for "supremacy" on
these systems, such as various shades of unix, etc., or even VMS.  The
user may like the graphics shell, but that isn't NT itself.

>
>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.

Thanks for putting all of your broken eggs in one basket; I replied to all
of them above.  Restating the points doesn't change them.  You can't draw
conclusions from points presented and refuted.

>>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.

Interesting, since the MS-DOS versions most closely resemble the VMS ones; the
actual source of much of the incompatibilities seems to be elsewhere; I suggest
you ask the maintainers of the programs I mentioned as to their gripes with
which incompatibilities in which systems are eating up their time.  You won't
find MS-DOS/DR-DOS to be where their gripes are.

cjl