Re: 6502 illegal opcodes questions

[pausch@saaf.se (Paul Schlyter)]

In article <1148544621.115246.248890@y43g2000cwc.googlegroups.com>,
mdj <mdj.mdj@gmail.com> wrote:

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

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

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

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

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

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

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

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

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

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.

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


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

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

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

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

> Ironically, Microsoft made the same design decision with .NET, by
> providing the facility of unmanaged code.

...and Java did it with JNI....

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

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.

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

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.

> 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

Now even you call Java a platform....

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.



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