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: 3 Sep 92 10:17:15 GMT
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University

In article <jimf.715443391@centerline.com> jimf@centerline.com (Jim Frost) writes:
>lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>>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.
>
>No, it means that they didn't want to abandon their current
>investment.  They put up with "RAM CRAM" and tons of programs that
>operated incompatibly for years because of that decision.  Many of
>them didn't know that things could be better.

You are attempting to rewrite history.  The question was put at what survives
15 years, not what in your opinion could have been different/better.

>
>>The so-called new functionality is largely bad fluff that
>>most users are ignoring.
>
>Sure.  Most users didn't want more than 640k total for their
>spreadsheet program and its data.  Remember the LIM standard that
>worked around that?  It wouldn't have been necessary if it weren't for
>bad architectural design.

Again, not addressing the issue; it is what it is, not what it might have
been, and it stays around in the form it's in; the statement stands.  LIM
has been around for years also, it's a standard that exists across several
incompatible ways to implement it, yet it works fine.  Thus, it's just another
optional frill that some people have to deal with sometimes.  Not germaine to
the issue at all.

>
>And what about VM?  Most users don't want that either, they'd rather
>put up with out-of-memory errors from their application when they do
>something that requires a couple more bytes of memory for their
>application while they have this memory-resident application sitting
>idle.  Sure they do.  And VM wasn't possible without additional
>hardware before the 80386.

No, they use various forms of DOS extension, such as DR-DOS's superior
implementation of upper and high memory on NEAT-chip 286's or better.  Even
8088 can get back 96K more if a program is CGA or less in its requirements.

>
>And most users don't need floating point arithmetic.  That's why
>Weitek sold tons of FPU chips, right?

FPU chips are options from the beginning.  The Weitek chips used alone or
in combination with 387's are only supported by applications written with
MicroWay's compilers or equivalent.  This is another architecture grafted
onto the system; another possible is I860, so what?  Some applications
need these; the vast bulk of machines don't.  You are confusing options with
evolvements.

>
>And most users never count higher than 65536 so they don't want fast
>32-bit arithmetic.

Quite true.  Most actual running code counts in 8-bit and 16-bit ranges or
floating point.  32-bits helps the miniscule percentage of code that requires
this.  In some applications, you can use a macro to simulate the EAX stuff
if you have to.  PKZIP makes a once-only special-case check and substitutes
the appropriate piece of code where it can make a marginal improvement.  This
was best implemented as it actually was, namely in assembler.

>
>>OS/2 has been called a solution seeking a problem.
>
>OS/2 would have fared better if it had worked when it was introduced.

>Windows has been doing pretty well, providing most of what OS/2 had to
>offer.

Yeah, a gaudy WIMP interface on top of a slow-running system that needs more
memory, a great improvement :-).

>
>But what about the other DOS extenders?  You yourself use DR-DOS which
>has a number of features not found in MS-DOS.  Many users buy Desqview
>to get multiple applications running at once, or VM386, or other
>similar products.  I guess they were happy with what they had, right?
>That's why they bought all those copies of Windows.

Some of them run Windows under Desqview, so what?

There are people who want to "play" everywhere on every machine.  Desqview is
largely a "toy" for this kind of person.  Windows can be a different kind of
toy to a different audience :-).  BTW, Windows 3.1 runs perfectly fine over
DR-DOS 6.

>
>>>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.
>
>Sure they do.  What about the VGA text modes that have more than 25
>lines?  Oops....

These modes are nice if you have them, such as 43-line EGA text mode.  But
you can't guarantee it exists; most programs don't use it.  And in any case
the standard stuff which spans the machine's lifetime is all there and totally
compatible, thus fulfilling the topic.

>
>>Graphics programs have
>>to be designed for an express screen size.
>
>No they don't.  Ever see a Mac application?  In fact, most graphics
>programs designed today are designed to be as independent of the
>actual graphics hardware as possible because the hardware changes so
>damned fast.

You missed the point: there are many generic ways to program M x N screens
where you find out what M and N are.  These programs generally don't run
too fast regardless of language due to calculation overhead.  The alternative
is to standardize on only a few specific screens, such as CGA 4-color mode
or Hercules Mono graphics.  Update speed then becomes quite a bit faster.
Some applications substitute multiple runtime modules as they autoconfigure
for your machine, but any one just does one screen size.  In any case, the
compatible modes still work fine on all machines if that's what you need.
And the extensions are all cookbook variations of each other.

>
>>All newer interfaces support all
>>older modes, and generally do them more quickly;
>
>No they don't.  CGA didn't support MGA graphics, for instance.  And
>what about the other "standard" boards like the 8514/A?  Or
>nonstandard boards such as the Matrox or the growing population of
>TIGAs?

There are a few incompatible graphics boards.  Most come with drivers that
you call in a compatible (with something else more familiar) way.  And most
are actually compatible at some level (often only CGA admittedly).  When you
add a non-standard card, you have opted to take advantage of a non-standard
machine; still outside the main issue.

>
>If you're counting on permanent backwards compatibility you're already
>in trouble.

Not at all; the better interfaces are generally VGA with total backwards
compatibility as a prerequisite before the tack something else on.  All of 
the so-called "supervga" modes are cookbook variations on the standard modes
of VGA and EGA.

>
>>>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.
>
>Hahahahaha.  The BIOS is deficient in *every* I/O operation.  It sits
>in a loop waiting for disk when it could be doing other things.  Its
>screen output speed is so bad that virtually nobody in the business
>relies upon it.  Its serial port support is so deficient it's unusable
>for anything but setting the communications parameters.

But the screen and serial ports are the same ones from the original hardware;
literally nothing has changed here.  This is why MS-KERMIT runs on all of
the machines you mentioned.  Obviously I was responding to what you said
regarding the DOS file calls and the disk BIOS calls.

>
>Ok, I admit that the disk I/O subsystem works well enough that most
>people use it, but it's not what I'd call good at doing disk I/O.
>
>
>>>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.
>
>Well, you're even more deluded than I thought you were.

No, just as little as others who disagree with you and agree with me think
I am.  Most don't bother to post :-).

cjl
Newsgroups: alt.folklore.computers