Re: 6502 illegal opcodes questions

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

Paul Schlyter wrote:

> I don't -- an API does not need to be standard, while a "standard
> library" certainly cannot ignore standards!  Of course an API can be
> implemented as a library, but it doesn't have to.  A header file (in C
> or C++) could also serve as an API.

Generally speaking the libraries that ship with platforms are
considered a part of their API. True enough I suppose that an API
doesn't necessarily end up a library, if you use a strict definition of
library. As we all know though, these are pretty lose terms.

> > And I am referring to the standard library in this case, ie. the functionality
> > you can rely on to be in every Java implementation.
>
> Unfortunately the Java standard library has varied between versions - even
> if we only consider Sun's Java implementations.  So you can forget that
> about "every Java implementation"....

!!! There's nothing unfortunate about it improving with age :) There
were a few examples of backwards compatibility being broken in the
early editions, but these issues are well and truly behind us.
Obviously if you write code that depends on new features, you break
compatibility old editions.

> The qsort() function is *quite* portable ---- as are most other ANSI C
> library functions which do not access external hardware or OS services.

Indeed C programs that do no I/O are more portable that those that do,
but they're also completely useless :-) And it's still easy to write
platform dependent C programs that do no I/O

> > Actually, you can boot Windows on any x86 equipped Mac, with Apple's
> > blessing.
>
> Natively?  Or on top of some emulation layer?

http://www.apple.com/macosx/bootcamp/

> > The other way around on the other hand....
>
> That's because Apple didn't make its OS-X86 conform to standard x86
> computers... <g>

Actually, x86 Macs are standard x86 computers... MacOS X relies on the
newer EFI firmware specification. After promising that Windows Vista
would support EFI, Microsoft have reversed that decision, and
accordingly most of the big vendors are not supporting EFI in new
chassis. Another 5 years or so in the dark ages :-(

> That's not enough:
>
>     byte b = (byte) 0xA0;
>     int i  = b;
>
> Here i will still be a negative number.  So you must do:

The type promotions rules are the same as for C/C++. They're a lot more
useful that way that the other way around. When you're doing bitwise
operations, the actual numeric value doesn't matter that much, and you
can always use hex notation for constants to avoid the issue.

I've actually implemented a C compatible expression parser. Leaving out
the unsigned types dramatically simplifies things.

> to get what we want.  And Java don't even have macros to hide such stuff....

You use methods instead. The compiler will inline the method for you.
The same rule applies to C++, where use of the preprocessor is
generally frowned upon. It's there for backwards compatibility.
 
Matt