[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/