Re: 6502 illegal opcodes questions

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

Paul Schlyter wrote:

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

I'm unfamiliar with FORTRAN, However all the other language you mention
make it possible to make use of the underlying architecture. The only
difference is that Pascal/Ada force you to be specific about your
intentions whereas C/C++ allows this to be done very simply.

> > The key concepts that are missing here are pointers, and more specifically,
> > the ability to perform arbitrary arithmetic on pointer types.
>
> FORTRAN, Pascal and Ada lacks this too.

Both Pascal and Ada allow arbitrary pointer arithmetic, granted not be
explicit language construct in the case of Pascal, but it's still
easily done, and was actually quite routinely done. I used this
facility myself many times on the Apple II when there was no provided
library routine to access a hardware feature.

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

That correct, but that's the price of portability ;-)

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

Yes, and this is a cause of portability issues for programs written in
those languages.

> ....which will enable you to use the underlying hardware more efficiently.
> Do you want to write a program which runs on a 64-bit machine?, and use
> the increased size of the basic data type?  Forget about Java - that language
> has a 32-bit architecture more or less hardwired into it.  Just like UCSD
> Pascal (which has a concept similar to Java: portable binary code which is
> to be interpreted on the target machine) had a 16-bit architecture more or less
> hardwired into it.
>
> > 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 ......

No. You're confusing the issues. Java is comprised of a language, an
API and a virtual machine. The API is written in Java, and is just a
portable as any other Java program.

> > 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.
>
> ....in Java, you must use JNI, and C, to do this.......  :-)

Which is the entire point; non-portable code stays in the non-portable
realm. There is actually plenty of example of code that was rewritten
in Java since it turned out to be more efficient that way, because the
necessary restrictions of JNI due to portability.

> > Ever tried porting some C code to a 64 bit platform?
>
> I've ported some 8-bit and 16-bit C code to 32 bit platforms, so I'm well
> acquainted with the problems which then may arise.  Porting from 32-bit
> to 64-bit is probably not much different.
>
> > 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.

Sure they are. The ANSI standard requires only that int is at least 16
bit, and signed. Addresses are whatever they are on the host
architecture.

> > 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.
>
> Check out:
>
> http://www.doc.ic.ac.uk/lab/secondyear/cstyle/node32.html#SECTION000260000000000000000
>
> in particular point 10, the last point.

Yes, but these are guidelines established to discipline C programmers
to write portable code! They are only necessary because the language
itself is not portable; it allows you to write a valid program that is
architecture dependant, and such guidelines are prevalent due to the
fact that people ignorant of them will write non-portable applications
without even realising it.

> > 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.
>
> I don't see the performance advantage here.  In what way would it
> degrade performance to keep int's separare from pointers?  At least
> the people doing this could have typedef'ed int to some name clearly
> indicating this int actually held a pointer.

Could have, didn't. That's the point.

> 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.
>
> > 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.
>
> You can do that in Java too -- read up on JNI !!!!!

No, JNI forces architecture dependent code to be written in a language
other than Java and linked to it via very specific portably defined
C/C++ interface. You can't just link in any old thing, you have to wrap
it in the portable interface of JNI on the C/C++ side.

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

It's not at all the same thing. Linking a code section from a
non-portable language via a portable interface is a radically different
approach than modifying a portable language to include non-portable
features. This is the basis of the Sun/Microsoft dispute.

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

Just as well, of course. The language definition is the same, and it
still prevents you writing code that will access machine dependant
features.

> Yep -- Java was about to be standardized some years ago, but then Sun
> changed its mind and stopped that.  Even C# now has an (ECMA) standard.

Which is to be honest a pointless marketing exercise. The language
definition itself is useless without its API, as 99.9% of useful C#
programs rely on the .NET API, which is in itself not portable - it
relies heavily on Win32 to provide its functionality.

The Java API on the other hand, is mostly written in Java, and utilises
a very small number of host OS facilities, all of which exist on
virtually every platform. In fact, it relies on the portable subset of
other languages to define these facilities.

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

This is true. Java is a Language, an API specification, and a VM. The
VM + API constitutes a platform. Comparing the Windows platform to the
Java platform however isn't sensible - the Windows platform is
non-portable, the Java platform is designed to be portable.

> Now even you call Java a platform....

Because it is. A language, and a  platform. When you refer to Java you
have to be specific about whether you mean the Java language, or the
Java platform, generally the terms are used interchangably and it's
discernable from context what someone is referring to.

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

This is what the POSIX standard is for. Even Microsoft made a token
attempt at providing a POSIX interface to Windows NT. They pulled it in
the end. These days you can get this interface via Cygwin. There's a
large subset of common functionality across all of these systems which
constitute the UNIX platform. Like anything, if you rely on
vendor-specific extensions, you break portability.

I mean really, to create anything that allows sophisticated
applications to run across multiple platforms, you must specify a
'meta-platform' which hides the specifics of each specific platform.
This is exactly what Java does. Without this technique, you're forced
to write lowest common denominator code.

Considering C/C++ in this light would mean sticking with only the ANSI
standards, which wouldn't allow you to leverage any OS facility beyond
basic file I/O

Java certainly has its blemishes, but how else does one write a
sophisticated application, then pick it up, either binary or source,
and drop it on every major OS and architecture ?

Matt