Re: 6502 illegal opcodes questions

["Michael" <michael.pohoreski@gmail.com>]

mdj 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. The key concepts that
> are missing here are pointers,

It has pointers, just not accessible by the user.
i.e. null reference

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

You say that, as if it was a bad thing.

The problem is one of size vs speed, and ease of serialization, which
is why C99 added int#_t, int_fast#_t, int_least#_t

While most code doesn't need to know the bit size of types, you still
need to know the min sizes, so you don't have to worry about underflow
/ overflow.  The size issue comes up when serializing.  By the language
mandidating features, even if the hardware doesn't support them, say
like doubles on DSPs, or the PS2, is one of the reasons Java is so
slow.

See: "How Java's Floating-Point Hurts Everyone Everywhere"
http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf


Maybe you have a different experience on "portability" you can comment
on, compared to Carmack's (May 2006) one with Java and cell-pohones?

http://www.armadilloaerospace.com/n.x/johnc/Recent%20Updates

It turns out that I'm a lot less fond of Java for
resource-constrained work. I remember all the little gripes I had with
the Java language, like no unsigned bytes, and the consequences of
strong typing, like no memset, and the inability to read resources into
anything but a char array, but the frustrating issues are details down
close to the hardware.

The biggest problem is that Java is really slow. On a pure cpu / memory
/ display / communications level, most modern cell phones should be
considerably better gaming platforms than a Game Boy Advanced. With
Java, on most phones you are left with about the CPU power of an
original 4.77 mhz IBM PC, and lousy control over everything.

I spent a fair amount of time looking at java byte code disassembly
while optimizing my little rendering engine. This is interesting fun
like any other optimization problem, but it alternates with a bleak
knowledge that even the most inspired java code is going to be a
fraction the performance of pedestrian native C code.

Even compiled to completely native code, Java semantic requirements
like range checking on every array access hobble it. One of the phones
(Motorola i730) has an option that does some load time compiling to
improve performance, which does help a lot, but you have no idea what
it is doing, and innocuous code changes can cause the compilable
heuristic to fail.

Write-once-run-anywhere. Ha. Hahahahaha. We are only testing on four
platforms right now, and not a single pair has the exact same quirks.
All the commercial games are tweaked and compiled individually for each
(often 100+) platform. Portability is not a justification for the awful
performance.

Cheers