Re: 6502 illegal opcodes questions

[pausch@saaf.se (Paul Schlyter)]

In article <44771e89$0$65426$742ec2ed@news.sonic.net>,
Andy McFadden  <fadden@fadden.com> wrote:

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

Somewhat in the spirit of Ada then, where you declare a numeric variable
as the number of decimal digits it should be able to hold, at a minimum.
 
> 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 are indeed a lot of ugly tricks you can do in FORTRAN.  A lot of
them involve "interesting" uses of EQUIVALENCE ......

> There's nothing implementation-specific about it; the language clearly
> allows it.

Sorry, but such tricks becomes *very* implementation dependent....

When handling strings in FORTRAN-66, you even HAD to resort to these
tricks.  FORTRAN-66 lacked string variables, so strings of characters
had to be stored in arrays of numeric variables.  Now, the number of
characters which could be stored in an INTEGER or a REAL varied
between implementation ... on machines with 8-bit bytes and 32-bit
integers or reals one could store 4 characters in each numeric
variable (or 8 characters in a DOUBLE PRECISION or COMPLEX variable),
while on machines with 6-bit bytes and 60-bit integers and reals, one
could store 10 characters in each numeric variable (or 20 characters
in a DOUBLE PRECISION or COMPLEX variable).

> No pointers involved.  C/C++ would allow it too.

Yep - C has unions....

> Java does not.

Which is curious, since Java prescribes the way numeris variables should
be represented, it would actually work there.

Otoh Java is too restrictive -- it's a real mess to handle unsigned
data in Java, since Java lacks unsigned integer types.


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

Java loses some portability though -- I'm not aware of any JVM targeted
for hardware using 1-complement integer arithmetic, or non-IEEE f.p.
formats.  In this respect, C and C++ will be more portable than Java.

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

....that's called "single platform"....

> Writing to Java is like knowing that you're always
> going to be running on x86 Linux with libc6.

Yep -- another example of single platform development.  WHatever
platform you're using, you can write your program for that platform only,
ignoring what might happen the day your program is ported to another
platform.

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

No --- Java programs will run only on the Java platform without problems.
And there are even problems between different versions of the JVM: if
you upgrade the JVM to the latest version on your web browser, some older
applets will cease working properly.  For that reason, I still keep an
old Netscape 4.7 web browser available, with its own very old JVM, for
applets which won't run on the latest JVM's.

So the claim that "Java programs run everywhere without problems" is
a myth -- even among different JVM's on the same computer!

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

I just did.  ANSI X3.159-1989, paragraph "3.1.2.5 Types", says:

# A "plain" int object has the natural size suggested by the
# architecture of the execution environemt.

So do you think 32 bits really is the natural size suggested by a 64
bit architecture?

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

Naturally it's impossible to write code that's broken in this way in
any single-platform language - not just 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.

You can reverse engineer a particular JVM, and then use the pointer
given to your C code by JNI, and then do about anything you want inside
the JVM with your C code.  Such a situation would be similar to the
.NET situation, where there is one single .NET-VM, written by Microsoft
to run on Windows.
 
>>> 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.

Then I could as well way: "When people say 'Windows apps are all
portable'", they assume that you have a Windows emulator running on
your platform of choice.  Programs running inside the Windows emulator
are portable, but whether or not Windows is available on your Apple II
is a different issue".

In both cases it's the same kind of "portability".

Btw, C programs can be run on an Apple II.  As a matter of fact, my very
first acquaintance with the C language I made on an Apple II, using Leor
Zolman's BDS C compiler.

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

....except the security aspects... :-)

You could also say: "if you think MSVC + Windows platform, it's
fairly similar to Java".

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