Re: 6502 illegal opcodes questions

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

Michael wrote:

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

Obviously if your application requires the use of a data size or type
that's unsupported by your hardware you're going to have performance
problems, but this applies regardless of language used.

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

For heavily numeric intensive applications, you need dedicated numerics
libraries. This is the case for C and C++ as well.

It'd be nice if people could come up with a nice standardised rich
numeric specification that could be added to Java. I'd imagine it'll
happen eventually.

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

I've only used Java in desktop and server environments, where the
problems are mitigated by mature virtual machines.

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

Every one of the issues you mention is the result of poorly implemented
virtual machines,  or at least *young* virtual machines. There's no
real reason for Java code to execute more slowly than C or C++, and
benchmarks routinely show that it does indeed run as fast, and in some
cases faster. It all depends on the sophistication of your compiler, or
in the Java case, the JIT/HotSpot engine.

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

It's still a very young platform that's changing quickly.  As a result,
there's little API standardisation across phones. Then there's vendors
wanting to keep their own API under lock and key.

None of these are Java, or more generically VM based platform issues,
just immature platforms growing fast, and experiencing pains as a
result.

Matt