Re: 6502 illegal opcodes questions

[Andy McFadden <fadden@fadden.com>]

In comp.sys.apple2 Paul Schlyter <pausch@saaf.se> wrote:
>> 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.
> 
> Java is not unique in this respect - languages like FORTRAN, C, C++,
> Pascal and Ada are also void of any language construct that would bind
> it, or any program written in it, to a specific architecture.  To
> write non-portable programs in these languages you almost always have
> to use implementation specific extensions (with the exception of C and C++,
> where you can use pointes for a lot of architecture dependent stuff -- otoh
> if you read the standards of these languages carefully, the behaviour of
> such programs is described as "undefined").

This is better in, say, C99, which declares the existence of "inttypes.h",
with types like "int32_t" (a signed 32-bit integer).

I've seen FORTRAN code that initialized multiple global arrays, of
varying types, with a single integer "clear memory area to zero" loop.
The author knew exactly how large all of the types were, how they packed,
how they were laid out in memory, what the floating point representation of
"all bits zero" meant, and so on.  Any change to the way the compiler
worked would have broken it.

There's nothing implementation-specific about it; the language clearly
allows it.  No pointers involved.  C/C++ would allow it too.  Java does not.

>> Additionally, the language specification defines EXACTLY the size and
>> precision of each data type.
> 
> ...which will limit Java to architectures having exactly these sizes and
> precisions of their data types.  Do you need 128-bit binary floating-point
> numbers for your number crunching stuff?  Forget about Java then....  or
> does your hardware have 1-complement signed integers?  Java requires
> integers to be 2-complement, i.e. you must then have some emulation layer
> on top of your native integer format - that's inefficient.

Yes.  Java trades portability and safety for efficiency.  That's rather
the point of the exercise.

>> It is impossible to write a Java program that's bound to a specific
>> machine architecture.
> 
> ...actually, it's quite easy to do that:  just use some of the common Java
> class libraries in your program, then try to run it on some architecture
> except the java architecture, i.e. without a JVM ......

With C/C++ the machine architecture and compiler configuration/capabilities
are significant.  With gcc on a 32-bit architecture you are likely to get
the same results on multiple platforms, but the "class libraries" can be
different.  You're usually okay so long as you stick with POSIX.

With Java we're talking about a virtual machine architecture, which is
the same everywhere.  Writing to Java is like knowing that you're always
going to be running on x86 Linux with libc6.

We're getting into a pedantic/semantic argument over what "portability"
means, but I think the rigid definitions of the Java language, VM, and
class libraries make it significantly more likely that you will be able
to write code once and have it run everywhere.  And you don't need to
have an autoconf script to make that happen.

>> Many C compilers implement int as a 32 bit quantity even on 64 bit
>> architectures,
> 
> Those C compilers aren't follow ANSI C compliant, I would say.

Check the spec.

> C code which assumes a pointer to be of the same size as an int is
> broken.  That assumption was invalid already in the 16-bit world,
> where an int naturally was 16 bits while a pointer could be 16 or 32
> bits, depending on the memory model.  In one and the same program, a
> function pointer could even be of a different size than a data
> pointer.

It's not broken -- it runs fine on the architecture for which it was
written -- it just isn't portable.  This is the argument for Java.  If
you believe that code of this nature is actually broken, then you will
be pleased to discover that it is impossible to write broken code of
this type in Java.

> I know about these implementations -- but how well do these non-JVM
> Java compilers run most Java programs originally written for JVM-Java?
> They lack a number of classes in the Java class library, don't they?
> Java is, by itself, such a small language that you cannot do much
> interesting with it without using the Java class libraries.

You actually cannot do anything -- several fundamental types required
by the VM are, in theory, part of the class libraries.  The idea is not
to do without the VM or class libraries, but rather to skip the "JIT"
part of compilation.

>> 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.
> 
> You can do that also in Sun's Java - just use JNI and some glue C code....

It's not quite as dramatic in JNI.  You can get and set types, and do
some fancy things with arrays, but the VM can decide that data should be
copied in and out rather than giving you direct access.  The .NET stuff
is more aware of what the VM is doing, which can make it more efficient
but also ties the C# VM to a specific data model.

>> 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.
> 
> How well is that security model maintained in GNU's Java implementation
> which runs without any VM and generates native code?

Probably as secure as a VM-based implementation, which is itself just a
bunch of native code.

> Here you compare two platforms.  I agree with what you say here, however
> it does illuminate my point:  Java isn't platform independent, Java is
> a platform.  And here you compare the Java platform with the Windows
> platform.  That makes sense.  It would not have made sense to compare
> the Windows platform with e.g. C or C++, because they are languages,
> not platforms.

Getting to the pedantic/semantic part.  When people say "Java is portable",
they assume that you have a Java VM running on your platform of choice.
Programs running inside the Java VM are portable, but whether or not Java
is available on your Apple II is a different issue.

> Btw, UNIX isn't "a platform". UNIX is a collection of several similar
> platforms which still are different enough to make some programs
> written for e.g. Linux source incompatible with e.g. Free-BSD, HP-UX or AIX.

Java is a collection of several similar platforms (Sun's, GNU classpath,
several commercial versions, some open source versions) running similar
goodies, but each has been limited or extended in some way.

If you think of a "POSIX + gcc" platform, it's fairly similar to Java.

-- 
Send mail to fadden@fadden.com (Andy McFadden) - http://www.fadden.com/
CD-Recordable FAQ - http://www.cdrfaq.org/
CiderPress Apple II archive utility for Windows - http://www.faddensoft.com/
Fight Internet Spam - http://spam.abuse.net/spam/ & http://spamcop.net/