Re: 6502 illegal opcodes questions

["mdj" <mdj.mdj@gmail.com>]

Paul Schlyter wrote:

> What "Java portability" ????
>
> Java is not a portable language.  Java is less portable than both
> FORTRAN, C or C++, which runs on several platforms.  Java runs on one
> single platform only: the Java platform.

Sorry, this isn't true. The Java language specification is quite
deliberately void of any language construct  that would bind it, or any
program written in it to a specific architecture. The key concepts that
are missing here are pointers, and more specifically, the ability to
perform arbitrary arithmetic on pointer types. Additionally, the
language specification defines EXACTLY the size and precision of each
data type. C and C++ on the other hand, not only allow arbitrary
pointer arithmetic, but also only define in the standard, the minimum
size requirements of each data type.

It is impossible to write a Java program that's bound to a specific
machine architecture. With C/C++ it's easy, and common to do so. In
fact, the ability of C/C++ to do such things is what makes it such a
useful language for low level programming, virtually replacing the need
for assembly language, except in cases of utilising the varied
coprocessors that adorn modern CPU's. Ever tried porting some C code to
a 64 bit platform? Many C compilers implement int as a 32 bit quantity
even on 64 bit architectures, which completely hoses an enormous amount
of C code, which wrongly assumes that int and int * are the same size,
simply because for many years on most implementations, it was.

You could point out that this is terrible coding practice, and I'd
agree with you. It was however one of the most common optimisations you
could do in C, and was frequently done precisely because of the
performance advantage it had.

The first 64 bit platform that GNU/Linux was self hosting on was the
Alpha (God bless it's soul). This particular portability issue with C
was the primary reason many good open source programs were not
available on this architecture.

Java can, and has, been implemented without the virtual machine. The
GNU compiler for Java for instance, can generate machine-code 'class'
files that run on a UNIX platform using the standard dynamic library
loader mechanisms available there. It can do this from both Java
source, and Java bytecode. Even if the VM is taken away, the source
level representation is still portable to any other Java
implementation.

Amusingly, there are a few higher level scripting languages out there
that are actually 'less portable' than java, because they provide
machine level access facilities that totally destroy the independence
of code written to use them.

> The Java platform doesn't exist in hardware - it must be simulated
> in software.  "But that means Java is portable: I can run my JVM on
> several other platforms" -- true, but if you define "portability" in
> such a way, then all Windows software becomes equally portable: just
> start your favourite Windows emulator on either your Mac or your Linux
> machine, and run your Windows software on it....

I'd be interested to hear a definition of 'portable' that doesn't apply
to Java, platform or language. I'd be prepared to conceed that perhaps
Linux could be considered "more portable" as it's a 'platform' that's
been ported to more architectures than perhaps any other in history.
The fact remains though, than even with Linux, one must be very
cautious not to write code in a machine dependant way while using it's
'natural' languages.

The big issue that existed with Microsofts implementation of Java, was
that they extended the language to permit pointer manipulation and
direct calls to native code segments, so that you can directly call the
Win32 API. This enabled them to easily generate Java stubs for the
entire Win32 API. This compromises not only the portability of Java
programs, but also the security model provided by the Java platform,
which is dependent on programs not being able to access memory that
belong to the VM, or any other program that's running in the same
memory space.

Ironically, Microsoft made the same design decision with .NET, by
providing the facility of unmanaged code. While this allows you to
easily leverage existing functionality, it also ties you to it, and is
undoubtedly the primary reason there was no 64 bit .NET VM for IA64 for
so long. Is there even one now? I bet Intel people, particularly on the
64 bit side of the fence curse Microsoft every night, as without the
ties that MS has between it's operating system and x86 architecture,
there'd be a lot more room in the marketplace for  a successor to x86,
rather than just another extension.

My only real gripe with the Java platform is that it's controlled,
essentially, by a single company with it's own agenda. There's still no
complete implementation of Java that's independent of Suns, and
everyone on the supposed JCP ultimately has to play second fiddle to
Suns iron first. To be though, this is still significantly better than
being tied to both a proprietary platform, and a machine architecture,
which is essentially the position that Microsoft developers are now in.

For me, the reason UNIX has endured as a platform for so long is that
it remains the ONLY platform which has a well specified, simple,
architecture agnostic API, and as a result has been implemented and
ported many times over. The next most ported platform after UNIX, is
probably Java, and it'll probably stay that way for quite some time.

Matt