Re: 6502 illegal opcodes questions

[pausch@saaf.se (Paul Schlyter)]

In article <1149152773.404039.252780@i40g2000cwc.googlegroups.com>,
mdj <mdj.mdj@gmail.com> wrote:

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

.... I'm more annoyed with old code whith ceases to work with new JVM versions...

Actually, I keep a copy of Nescape 4.7 in working condition (with its
own, quite old, JVM), mostly to be able to browse web sites with
applets which no longer run properly on modern web browsers.
 
>> 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 :-)

I was talking about portable code, not necessarily about complete applications.
Code doing no I/O can still be useful, as a library called by your own program.

> And it's still easy to write platform dependent C programs that do no I/O

...of course ...such as:

int main()
{
    if ( sizeof(int) == sizeof(int *) )
        for(;;)
            ;

    return 0;
}

:-)

Btw in C you cannot write a program which do no output whatsoever.  Even the
minimal C program:

int main()
{
    return 42;
}

outputs a return code to the OS, which can be tested in shell scripts/etc.
And if you remove the return statement, the required output will be garbage.

 
>>> 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 :-(

One good thing about standards is that there are so many to choose among... :-/
 
>> 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.

...but if I want to output the value to some terminal or file, I'd
like the output to be A0 rather than FFFFFFA0 .... :-)
 
> I've actually implemented a C compatible expression parser. Leaving out
> the unsigned types dramatically simplifies things.

I believe you!  Leaving out most operators too will make the parser even
simpler.... :-)

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

...or constants!  In C++ a 'const' declared int (or float, or....) is
really a constant and not merely a write protected variable.  So you can
do things like:

   const int arraysize = 1234;
   int array[arraysize];

Doing this is illegal in C - there you *must* use a macro (or a literal
integer constant).

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

Even in C++, the preprocessor is useful for conditional compilation.  You
can't do that with methods.....   The #pragma directove (an idea borrowed
from Ada) can be quite handy too.

And C/C++ macros contain the # (stringize) operator, which converts a
symbolic name to a string containing that name.  You can't do that with
methods either....
  
> Matt

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