Re: 6502 illegal opcodes questions

[pausch@saaf.se (Paul Schlyter)]

In article <gLOdnYcddOPrceHZnZ2dnUVZ_uqdnZ2d@comcast.com>,
Michael J. Mahon <mjmahon@aol.com> wrote:

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

Will it shrink all the way down to one such platform?


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

FYI: there is no such thing as "8-bit ASCII".  ASCII is a 7-bit code.

If you want to use 8-bit character codes you'll have a lot to choose
among.  Nowadays some flavor of ISO-8859 is the most common: in the
US and in western Europe ISO-8859-1 (aka ISO-Latin-1 -- yes there are
other versions of ISO-Latin than ISO-Latin-1) is usually used.

> Big alphabets are still a (national) problem,

The alphabets need not be bigger than ours to be a problem.  The Greek
alphabet is smaller than the Latin alphabet, but you'll have to use
ISO-8859-7 to get access to Greek letters.  The Cyrillic alphabet
is only slightly larger than ours, but to get access to that alphabet
you'll need to use ISO-8859-5.

Even some countries whose languages use the Latin alphabet still can't
use ISO-8859-1 because it lacks a few characters in their alphanet.
In Turkey one must use ISO-8859-3 and in Iceland ISO-8859-4.

There's a way out of this mess with different varieties of "8-bit
ASCII" though: Unicode.  Yes, it's coming and it's getting more and
more noticeable.  Windows-NT used UCS-2 for its internal
representation of e.g filenames, and in Windows-2000 a switch was made
to UTF-16 (both are 16-bit character codes, but while UCS-2 can only
hold the first 64K of the Unicode alphabet, UTF-16 can hold the entire
Unicode alphabet).  Java uses either UCS-2 or UTF-16 (don't know
which, maybe it doesn't matter except for display purposes) internally
in strings.  In situations where a 16-bit character code is
impractical, UTF-8 is the obvious choice.  Linux already supports
that in at least some distributions, and by choosing an UTF-8 locale,
one can have console output in Greek or Cyrillic characters.

Java is interesting here btw - a Java compiler already accepts
source code in Unicode - a proper BOM (Byte Order Mark) at the
beginning of the file will tell the Java compiler which flavor
of Unicode it is (UTF-8, UTF-16, UCS-4).

People who were used to programming langauges like FORTRAN and
Pascal, which were case insensitive, intially got a bit confused
by e.g. C code like this:

    int a = 12;
    int A = 45;

Doing the equivalent in Pascal would cause a "variable already
defined" error.  But in C this works because C is case sensitive,
and here a and A are two different variables.


In Java you can have even more fun that this - consider:

    int A = 12;
    int A = 45;
    int A = 82;
    int A = 113;
    int A = 176;
    int A = 217;

(this should really have been written in UTF-8 to be correct,
but displaying it would make it look like this anyway)

The same variable A defined six times?  That cannot work ....  yes it
can!

The first A is the capital Latin A - character code 0x41
The second A is the capital Cyrillic A - character code 0x391
The third A is the capital Greek Alfa - character code 0x410
The fourth A is the capital Cherokee A - character code 0x13AA
The fifth A is the capital Canadian Aboriginal A - character code 0x15C5
The sixth A is the Math Symbol capital A - character code 0x1D5A0
(the last case works only if Java uses UTF-16 rather than UCS-2)

Finally, we might have:

    int C = (A+A)*A - (A+A)*A;

and from a source listing it'll be impossible to figure out the value
of C (hint: it's not zero....) .... unless we take a hex dump of the
source code so we can see which identifiers really are used!


In Java, (almost) the entire Unicode alphabet can be used as names
for identifiers -- so expect some really "interesting" Java software
in, say, 10 years....




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

When the number of economically important "different" platforms
has decreased to one (M$-Window$), then .NET will finally have become
"universally portable" .... :-)

Will this horror future scenario ever happen?  Well, we're getting there:
Macs are nowadays Intel based, and in the future there will probably be
Windows versions which can boot on the Mac.  Today's sypercomputers are
usually clusters based on Intel machines.  But what about Linux?  Linux
will be there, of course, but since Linux is free it's not "economically
important".... :-)

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/