Re: 6502 illegal opcodes questions

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

Paul Schlyter wrote:

> <large optimisation example snipped>

:-) Of course this is valid in theory. In practice you might find that
the looped version is actually faster, since it fits inside a L1 Cache
line... Theoretical speed and actual speed aren't the same thing on
modern processors.

> There's even a special data type for that in C: the bit field.  It's
> not an array though -- it's merely a way to give specific bits of an int
> a name of its own, and let the compiler take care of the needed shifting
> and masking.

Indeed. Bit fields however have implementation specific warnings all
over them. You can usually get better portability avoiding them.

> C is frequently referred to as "portable assembler".  C is also the
> target language for the output from compilers of other languages,
> such as Eiffel, and also early C++ compilers.

It's useful for bootstrapping a compiler on a new platform, yes.

> I don't consider that an API, but a library!  An API should provide access
> to something else but itself.  Such as external hardware, or some other
> software module.

Fair enough. I consider the terms API and "standard library"
synonymous, as I'm sure most developers do .... And I am referring to
the standard library in this case, ie. the functionality you can rely
on to be in every Java implementation. Of course, what you can't rely
on, you can bring with you...

> Almost all languages has a library of functions or classes.  The "high
> level assembler" language C is no exception.  Consider for instance
> the qsort() function in the Standard C library -- is that function an
> API?  Or is it a library function?

Please... The ANSI C library is hardly the basis of a portable
platform.

> Emulating the x86 architecture isn't enough.  The Mac has now switched to
> the x86 CPU, yet you cannot boot Windows on any x86 equipped Mac.  You
> must emulate the surrounding hardware environment as well.

Actually, you can boot Windows on any x86 equipped Mac, with Apple's
blessing. The other way around on the other hand....

> ...just like the original intention of Basic -- and both these languages are
> still used to write actual applications, even though Basic nowadays usually
> is called "Visual Basic" and Pascal usually is called "Delphi".

Both VB and Delphi are far enough removed from the languages they're
derived from to be considered different languages, IMO

> ...but why does java lack unsinged integer data types?  And regarding safety:
> Java integers still overflow silently, just like C integers do.

That's true. Overflows don't cause portability problems though, just
bugs. You can get around unsigned types easily enough by using the next
larger type, but I agree it's an oversight, and an ugly one. It does
however dramatically simplify the expression compiler/optimiser

> Manipulating binary data is a bit awkward due to the lack of unsigned
> byte and integer types in Java.

See above. I've never found it particularly annoying, no more so than I
used to back in BASIC on the Apple II peeking negative locations :-)

> Complex arithmetic: Java lacks a Complex data type, and also lacks the
> capability of operator overloading.  Here, FORTRAN, C++ or C99 are the
> preferred languages.  Vector arithmetic: ditto - here C++ or Fortran-9x
> are the preferred languages.  Bignum arithmetic: Ditto - C++ preferred.
> Any other form of arithmetic where the built-in data types are
> insufficient.

I think we've strayed from the point a bit. Yes, Java is missing a
number of features that are available in other languages. To be honest,
I don't miss operator overloading all that much, but it'd be nice if it
was there...

> > It's actually possible to implement the VM in such a way that any
> > danger imposed by JNI cannot compromise the security model, or even
> > crash the application. Typically this isn't done for performance
> > reasons, but there are implementations that provide this level of
> > safety.
>
> That would require the VM to run in a memory space different from the
> memory space of the called C code.  Switching memory spaces when calling
> C code is definitely a performance bottleneck.

That's right, which is why it isn't done unless you're security
paranoid, or have a very good reason.

> We can compare with another technology: television.  Consider the US
> NTSC ("Never The Same Color") TV system which has been in use for over
> 50 years now.  The color problem of this system has since long been
> fixed, and the fix was implemented in the European TV systems which
> went color about a decade after the US.  But the US TV system cannot
> be upgraded because of the huge amounts of TV sets out there that one
> would need to maintain backwards compatibility to.  Only now, when
> switching to digital TV, it will be upgraded -- but it'll be there for
> at least another decade or so, for backwards compatibility.

The analogy holds to some extent, but lifecycles are much shorter in
the computing world. The question is, will the issues of the old
'standard' be fixed when moving to the new. I reckon with Microsofts
approach they won't, as they've carried the issues forward with them,
making their next generation signal a bit like NTSC at several times
the bandwidth, but still off colour ;-)

Matt