6502 illegal opcodes questions
in [Commodore]
|
Prev: what happened CBM=VGA
Next: 1581 Drive Kits on eBay
From: mdj on 31 May 2006 10:41 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
From: Paul Schlyter on 31 May 2006 12:13 In article <1149086466.883167.33940(a)y43g2000cwc.googlegroups.com>, mdj <mdj.mdj(a)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/
From: mdj on 1 Jun 2006 05:06 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
From: Paul Schlyter on 1 Jun 2006 12:13 In article <1149152773.404039.252780(a)i40g2000cwc.googlegroups.com>, mdj <mdj.mdj(a)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/
From: Michael J. Mahon on 1 Jun 2006 14:24
Paul Schlyter wrote: <snip> > The #pragma directove (an idea borrowed > from Ada) can be quite handy too. Actually, I believe that _pragma_ was borrowed from Algol 68, which must be the most influential least implemented language. ;-) -michael Parallel computing for 8-bit Apple II's! Home page: http://members.aol.com/MJMahon/ "The wastebasket is our most important design tool--and it is seriously underused." |