[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 6502 illegal opcodes questions
mdj wrote:
Paul Schlyter wrote:
<snip>
If so, then it's just as impossible to write a Windows program that's bound to
a specific machine architecture: just write a Windows emualator for any
target platform you want.
History has shown this isn't true. Any effective emulator for Windows
is actually an emulation of the x86 architecture, which can then run
Windows itself.
The only third party attempt at reimplementing Windows that has had any
success at all is the WINE project, and that too is bound to the x86
architecture. It is also, woefully incomplete, despite being started as
a project back when Win16 was the dominant API.
So Windows emulation relies on implementing a Windows compatible
machine emulator. Not exactly an efficient solution.
Microsoft themselves know this. Why else would they have moved to an
extremely Java like system with .NET ?
Actually, there are (were, in the case of Alpha?) native Windows NT
ports to both Alpha and IA-64. Neither of these machines was used
"like an x86"--they are good, high performance ports.
<snip>
But Win32 is just as portable as the Java API - there are Win32 emulators
running on other platforms.
This is more precisely put as Intel architecture emulators running on
other architectures. The Win32 platform remains tied to x86. Have a
look at Windows 64 bit edition on the IA-64 and see how it handles
backwards compatibility. It's so inefficient that you just do not do
it, you use real x86 boxes instead.
If anything, this is an argument against your case.
The IA-64 architecture contains a hardware x86 emulator that is a
performance disaster (relative to object code compilation). Any
use of this emulator is bound to be a performance problem.
The fact that x86 compatibility performs poorly is an argument for
how different IA-64, and the IA-64 Windows port, is from the native
x86 version.
Native IA-64 code flies on Windows for IA-64.
This is going to remain the case with .NET applications as well,
despite their supposed 'portability' due to the way legacy code can be
called. For some time, .NET applications on Win64 had to run via the
Win32 emulator, which is already terribly slow. This applies for any
application that uses the .NET API, since it merely thunks calls
through to Win32.
That's just a matter of prioritizing which parts of the system get
ported sooner and which later. Understandably, Microsoft designers
decided that Java code was not performance critical. ;-)
The Java approach is different. Reimplement the API in Java. Make it as
portable as anything else written in the language. The result? Java is
implemented on every platform it's viable to run it on.
Then how come there are Windows emulators running on other platforms?
Which ones? See above. Any successful implementation of Windows
emulation is actually an x86 PC emulator running actual Windows.
The ones I mentioned--see above. ;-)
I assure you that the Alpha port and the IA-64 port of Windows are
*not* written to x86 standards and limitations.
I note, however, that in any "portable" program, tradeoffs are made
that affect native performance on any *particular* machine.
I think you underestimate how effective the lower levels of NT are,
particularly the HAL, at insulating higher levels of the OS from
peculiarities of the metal.
Modern OSs--and NT is one of the most modern--have adopted techniques
for achieving relative portability with only modest effects on native
performance.
<snip>
It's certainly a contentious issue, and theres supporters on either
side of the fence. Academically speaking, there's no such thing as true
portability. As long as there are multiple platforms there will be
applications that aren't portable.
And the number of economically important "different" platforms is
decreasing to a very small number, largely as a result of market
forces triggered by a huge object code base (which the market thinks
of as non-portable).
Some would call it a vicious cycle, some a virtuous cycle, which
eliminates all but one contender for the binary interface. But there
is no disputing events.
Practically speaking, most portability problems are a result of either
resource constraints or data representation differences.
Moore's "Law" has all but vanquished resource limitations for all but
the most demanding (and therefore niche) applications.
And, perhaps because of designers' clarity, or perhaps because of their
laziness, we have settled almost universally on a set of data repre-
sentations that are common across architectures: IEEE floating point,
twos-complement integers in power-of-two byte sizes, and 8-bit ASCII.
Big alphabets are still a (national) problem, and pointers are still
often confused with other data types, but, by and large, the data
wars are over. Even the completely arbitrary endianness problem is
all but vanquished, with big endian machines switch-hitting and little
endian machines enjoying their popularity.
In this day and age, you really have to be creative (or malevolent)
to come up with a legitimate portability barrier. ;-)
It's pointless though to consider the argument in academic terms, only
in practical terms. Java meets its goals of portability. .NET has yet
to meet those goals, and frankly, I doubt it ever will. Microsoft
simply have no interest in making it easy to run Windows applications
on a non-Microsoft platform. You can argue that their system is
inherently portable, but it remains impractical to port Windows
applications.
Your last point is perhaps the most significant--the clear motivation
to *obstruct* portability "away" from your platform. This is the issue
that perenially prevents any real Unix standard. Only the losers in
the marketshare game *really* want portability--winners never do. ;-)
(Come to think of it, maybe Linux can eventually "mop up" in the market
and then we'll have a *real* _de facto_ Unix standard. ;-)
-michael
Parallel computing for 8-bit Apple II's!
Home page: http://members.aol.com/MJMahon/
"The wastebasket is our most important design
tool--and it is seriously underused."