[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 6502 illegal opcodes questions



In article <1149086466.883167.33940@y43g2000cwc.googlegroups.com>,
mdj <mdj.mdj@gmail.com> wrote:

> Paul Schlyter wrote:

......................

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

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.

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

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

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

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

Natively?  Or on top of some emulation layer?

> The other way around on the other hand....

That's because Apple didn't make its OS-X86 conform to standard x86
computers... <g>

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

....well I can agree about that.

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

That's not enough:

    byte b = (byte) 0xA0;
    int i  = b;

Here i will still be a negative number.  So you must do:

    int i = b & 0xFF;

to get what you want.

However, Java *does* have an unsigned data type: the char data type which
is a 16-bit unsigned type.  But doing:

    byte b = (byte) 0xA0;
    char c = (char) b;

would leave c with a positive value, sure, but the value would be 0xFFA0.
So we still have to do:

    char c = (char)(b & 0xFF);

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

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

Actually, you were forced to do that only in Integer Basic.  In Applesoft
Basic you had a choice: you could use either negative or positive numbers.
So in Applesoft, "CALL -151" could also be written as "CALL 65385".

Constants in hex would have been nice though.  You got that with Apple CP/M,
where in MBasic you could write  "CALL &HFF69" --- but of course the Apple
Monitor couldn't be called just like that from the Z80....

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