6502 illegal opcodes questions
in [Commodore]
|
Prev: what happened CBM=VGA
Next: 1581 Drive Kits on eBay
From: Paul Schlyter on 27 May 2006 06:12 In article <nospam-467DFC.23375126052006(a)network-065-024-007-027.columbus.rr.com>, > In article <e56rj1$7lo$1(a)merope.saaf.se>, > pausch(a)saaf.se (Paul Schlyter) wrote: > >> In article <1148544621.115246.248890(a)y43g2000cwc.googlegroups.com>, >> mdj <mdj.mdj(a)gmail.com> wrote: > [...] >>> The key concepts that are missing here are pointers, and more specifically, >>> the ability to perform arbitrary arithmetic on pointer types. >> >> FORTRAN, Pascal and Ada lacks this too. > [...] > > This is certainly false for Ada: > > http://www.adapower.com/rm95.php > > In particular, the standard package Interfaces.C.Pointers overloads the > "+" and "-" operators for just this purpose. > > http://www.adapower.com/rm95/RM-B-3-2.html OK, Ada has pointer arithmetic - but is it arbitrary? Doesn't Ada impose strict range checking for all its data structures, throwing exceptions as soon as an attempt of out-of-range access is performed? I though the fundamental idea behind Ada was to provide provably secure software, and then one cannot take pointer arithmetic as lightly as C and C++ both do. > It is arguably false for many widely used flavors of Pascal including > Object Pascal and Turbo Pascal. > > Even Fortran has a non-standard extension for this: > > http://gcc.gnu.org/onlinedocs/gfortran/Cray-pointers.html If we are going to include non-standard extensions of languages too, then the Java camp should also include both J++ and C# ..... -- ---------------------------------------------------------------- Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN e-mail: pausch at stockholm dot bostream dot se WWW: http://stjarnhimlen.se/
From: Paul Schlyter on 27 May 2006 06:12 In article <bruce#fanboy.net-7FEFE6.22195226052006(a)news.newsreader.com>, Bruce Tomlin <bruce#fanboy.net(a)127.0.0.1> wrote: > In article <e56rj1$7lo$1(a)merope.saaf.se>, > pausch(a)saaf.se (Paul Schlyter) wrote: > >> numbers for your number crunching stuff? Forget about Java then.... or >> does your hardware have 1-complement signed integers? Java requires >> integers to be 2-complement, i.e. you must then have some emulation layer >> on top of your native integer format - that's inefficient. > > Seriously, has anyone used 1's complement arithmetic in the past 10-20 > years or so? And why? I used a CDC Cyber-720 twenty years ago: it has 60-bit word size, non-IEEE floating-point format, and one-complement arithmetic - not only for integer data but for floating-point data as well! A few years later that machine was put out of service though. Btw one could also ask: "Seriously, has anyone used the Apple II, or some other obsolete 8-bit micro, in the past 10-20 years? If so, why?" ....and the surprising (to some) answer is: yes! There are emulators not just for the Apple II and other past popular micros. There are emulators for old mainframes as well - check out: https://gna.org/projects/backtolife/ -- ---------------------------------------------------------------- Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN e-mail: pausch at stockholm dot bostream dot se WWW: http://stjarnhimlen.se/
From: Bruce Tomlin on 27 May 2006 07:54 In article <e598co$12ur$1(a)merope.saaf.se>, pausch(a)saaf.se (Paul Schlyter) wrote: > In article <bruce#fanboy.net-7FEFE6.22195226052006(a)news.newsreader.com>, > Bruce Tomlin <bruce#fanboy.net(a)127.0.0.1> wrote: > > > In article <e56rj1$7lo$1(a)merope.saaf.se>, > > pausch(a)saaf.se (Paul Schlyter) wrote: > > > >> numbers for your number crunching stuff? Forget about Java then.... or > >> does your hardware have 1-complement signed integers? Java requires > >> integers to be 2-complement, i.e. you must then have some emulation layer > >> on top of your native integer format - that's inefficient. > > > > Seriously, has anyone used 1's complement arithmetic in the past 10-20 > > years or so? And why? > > I used a CDC Cyber-720 twenty years ago: it has 60-bit word size, > non-IEEE floating-point format, and one-complement arithmetic - not > only for integer data but for floating-point data as well! A few > years later that machine was put out of service though. Exactly. Put out of service. That's why I gave a range, because I know how some places can be about their expensive old mainframes and micros. And you didn't answer my other question of WHY? What advantage does 1's complement math have that would make someone _want_ to use it now? > Btw one could also ask: > > "Seriously, has anyone used the Apple II, or some other obsolete 8-bit > micro, in the past 10-20 years? If so, why?" > > ...and the surprising (to some) answer is: yes! Apples and oranges. I'm talking about a way of doing math, and you're trying to bring up a specific hardware platform. Old platforms are going to be obsolete, period. Old math isn't necessarily so. "That calculus stuff is over 200 years old, nobody uses it any more."
From: Paul Schlyter on 27 May 2006 12:12 In article <1148720485.731835.6030(a)j55g2000cwa.googlegroups.com>, mdj <mdj.mdj(a)gmail.com> wrote: > Paul Schlyter wrote: > >> Java is not unique in this respect - languages like FORTRAN, C, C++, >> Pascal and Ada are also void of any language construct that would bind >> it, or any program written in it, to a specific architecture. To >> write non-portable programs in these languages you almost always have >> to use implementation specific extensions (with the exception of C and C++, >> where you can use pointes for a lot of architecture dependent stuff -- otoh >> if you read the standards of these languages carefully, the behaviour of >> such programs is described as "undefined"). > > I'm unfamiliar with FORTRAN, However all the other language you mention > make it possible to make use of the underlying architecture. The only > difference is that Pascal/Ada force you to be specific about your > intentions whereas C/C++ allows this to be done very simply. In FORTRAN you could access any address available to the program by declaring an array and then exceed the bounds of the array. Negative subscripts usually worked too. Port I/O wasn't possible in that way though, there you had to resort to subroutines in e.g. assembly language. >>> The key concepts that are missing here are pointers, and more specifically, >>> the ability to perform arbitrary arithmetic on pointer types. >> >> FORTRAN, Pascal and Ada lacks this too. > > Both Pascal and Ada allow arbitrary pointer arithmetic, granted not be > explicit language construct in the case of Pascal, but it's still > easily done, and was actually quite routinely done. I used this > facility myself many times on the Apple II when there was no provided > library routine to access a hardware feature. You still couldn't do port I/O that way. That didn't matter on the Apple II of course, since the 6502 didn't have any hardware ports. >>> Additionally, the language specification defines EXACTLY the size and >>> precision of each data type. >> >> ...which will limit Java to architectures having exactly these sizes and >> precisions of their data types. Do you need 128-bit binary floating-point >> numbers for your number crunching stuff? Forget about Java then.... or >> does your hardware have 1-complement signed integers? Java requires >> integers to be 2-complement, i.e. you must then have some emulation layer >> on top of your native integer format - that's inefficient. > > That correct, but that's the price of portability ;-) Not necessarily. The idea of portability in C is to use the underlying hardware as efficiently as possible: if the hardware uses 1-bit complement then that C implementation uses 1-bit complement too .... etc etc. If written with portability in mind, C code can then be made to run as efficiently as possible in very different architectures. >>> C and C++ on the other hand, not only allow arbitrary pointer arithmetic, >>> but also only define in the standard, the minimum size requirements of each >>> data type. > > Yes, and this is a cause of portability issues for programs written in > those languages. ....interesting portability problem: "...hey, these 128-bit integers are too big! We're having problems storing the value 763 in it....." :-) >> ....which will enable you to use the underlying hardware more efficiently. >> Do you want to write a program which runs on a 64-bit machine?, and use >> the increased size of the basic data type? Forget about Java - that language >> has a 32-bit architecture more or less hardwired into it. Just like UCSD >> Pascal (which has a concept similar to Java: portable binary code which is >> to be interpreted on the target machine) had a 16-bit architecture more or less >> hardwired into it. >> >>> It is impossible to write a Java program that's bound to a specific >>> machine architecture. >> >> ...actually, it's quite easy to do that: just use some of the common Java >> class libraries in your program, then try to run it on some architecture >> except the java architecture, i.e. without a JVM ...... > > No. You're confusing the issues. Java is comprised of a language, an > API and a virtual machine. The API is written in Java, The API is just glue code between the Java program and the VM. > and is just a portable as any other Java program. If so, then it's just as impossible to write a Windows program that's bound to a specific machine architecture: just write a Windows emualator for any target platform you want. >>> With C/C++ it's easy, and common to do so. In fact, the ability of C/C++ >>> to do such things is what makes it such a useful language for low level >>> programming, virtually replacing the need for assembly language, except >>> in cases of utilising the varied coprocessors that adorn modern CPU's. >> >> ....in Java, you must use JNI, and C, to do this....... :-) > > Which is the entire point; non-portable code stays in the non-portable > realm. There is actually plenty of example of code that was rewritten > in Java since it turned out to be more efficient that way, because the > necessary restrictions of JNI due to portability. I suppose that happened when JIT was introduced in Java: code called through JNI was more efficient than "old Java", without JNI, but less efficient than Java with JIT. And the JNI interface is by itself an overhead. >>> Ever tried porting some C code to a 64 bit platform? >> >> I've ported some 8-bit and 16-bit C code to 32 bit platforms, so I'm well >> acquainted with the problems which then may arise. Porting from 32-bit >> to 64-bit is probably not much different. >> >>> Many C compilers implement int as a 32 bit quantity even on 64 bit >>> architectures, >> >> Those C compilers aren't follow ANSI C compliant, I would say. > > Sure they are. The ANSI standard requires only that int is at least 16 > bit, and signed. Addresses are whatever they are on the host > architecture. Sorry, but ANSI C says more than that about the size of an int. ANSI X3.159-1989, paragraph "3.1.2.5 Types", explicitly says: # A "plain" int object has the natural size suggested by the # architecture of the execution environemt. Now, what do you think the "natural size" on a 64-bit architecture is? 32 bits? <g> >>> which completely hoses an enormous amount of C code, which wrongly assumes >>> that int and int * are the same size, simply because for many years on most >>> implementations, it was. >> >> Check out: >> >> http://www.doc.ic.ac.uk/lab/secondyear/cstyle/node32.html#SECTION000260000000000000000 >> >> in particular point 10, the last point. > > Yes, but these are guidelines established to discipline C programmers > to write portable code! They are only necessary because the language > itself is not portable; it allows you to write a valid program that is > architecture dependant, and such guidelines are prevalent due to the > fact that people ignorant of them will write non-portable applications > without even realising it. C follows the idea "Trust the programmer" -- apparently, a lot of programmers weren't trustworthy. Therefore "strait-jacket languages" like Pascal and Java were needed.... >>> You could point out that this is terrible coding practice, and I'd >>> agree with you. It was however one of the most common optimisations you >>> could do in C, and was frequently done precisely because of the >>> performance advantage it had. >> >> I don't see the performance advantage here. In what way would it >> degrade performance to keep int's separare from pointers? At least >> the people doing this could have typedef'ed int to some name clearly >> indicating this int actually held a pointer. > > Could have, didn't. That's the point. Another victory for strait-jacket languages... :-) >> I know about these implementations -- but how well do these non-JVM >> Java compilers run most Java programs originally written for JVM-Java? >> They lack a number of classes in the Java class library, don't they? >> Java is, by itself, such a small language that you cannot do much >> interesting with it without using the Java class libraries. >> >>> Amusingly, there are a few higher level scripting languages out there >>> that are actually 'less portable' than java, because they provide >>> machine level access facilities that totally destroy the independence >>> of code written to use them. >> >> You can do that in Java too -- read up on JNI !!!!! > > No, JNI forces architecture dependent code to be written in a language > other than Java and linked to it via very specific portably defined > C/C++ interface. You can't just link in any old thing, you have to wrap > it in the portable interface of JNI on the C/C++ side. I know the stuff called through JNI must be written in C (using C++ here would be messier). Yet, JNI is a hole in Java which also poses a danger. >>> The big issue that existed with Microsofts implementation of Java, was >>> that they extended the language to permit pointer manipulation and >>> direct calls to native code segments, so that you can directly call the >>> Win32 API. This enabled them to easily generate Java stubs for the >>> entire Win32 API. >> >> You can do that also in Sun's Java - just use JNI and some glue C code.... > > It's not at all the same thing. Linking a code section from a > non-portable language via a portable interface is a radically different > approach than modifying a portable language to include non-portable > features. This is the basis of the Sun/Microsoft dispute. The method differs, true, but the end result is the same: versatility, insecurity, and non-portability. >>> This compromises not only the portability of Java >>> programs, but also the security model provided by the Java platform, >>> which is dependent on programs not being able to access memory that >>> belong to the VM, or any other program that's running in the same >>> memory space. >> >> How well is that security model maintained in GNU's Java implementation >> which runs without any VM and generates native code? > > Just as well, of course. The language definition is the same, and it > still prevents you writing code that will access machine dependant > features. > >> Yep -- Java was about to be standardized some years ago, but then Sun >> changed its mind and stopped that. Even C# now has an (ECMA) standard. > > Which is to be honest a pointless marketing exercise. The language > definition itself is useless without its API, as 99.9% of useful C# > programs rely on the .NET API, which is in itself not portable - it > relies heavily on Win32 to provide its functionality. But Win32 is just as portable as the Java API - there are Win32 emulators running on other platforms. > The Java API on the other hand, is mostly written in Java, and utilises > a very small number of host OS facilities, all of which exist on > virtually every platform. In fact, it relies on the portable subset of > other languages to define these facilities. > >> Here you compare two platforms. I agree with what you say here, however >> it does illuminate my point: Java isn't platform independent, Java is >> a platform. And here you compare the Java platform with the Windows >> platform. That makes sense. It would not have made sense to compare >> the Windows platform with e.g. C or C++, because they are languages, >> not platforms. > > This is true. Java is a Language, an API specification, and a VM. The > VM + API constitutes a platform. Comparing the Windows platform to the > Java platform however isn't sensible - the Windows platform is > non-portable, the Java platform is designed to be portable. Then how come there are Windows emulators running on other platforms? >> Now even you call Java a platform.... > > Because it is. A language, and a platform. When you refer to Java you > have to be specific about whether you mean the Java language, or the > Java platform, generally the terms are used interchangably and it's > discernable from context what someone is referring to. When you say just "Java" I think you usually mean both. Remove the platform and you can't run your Java program. Remove the language, and you'll have to program in bytecode directly, which would be possible, although awkward. >> Btw, UNIX isn't "a platform". UNIX is a collection of several similar >> platforms which still are different enough to make some programs >> written for e.g. Linux source incompatible with e.g. Free-BSD, HP-UX or AIX. > > This is what the POSIX standard is for. Even Microsoft made a token > attempt at providing a POSIX interface to Windows NT. They pulled it in > the end. These days you can get this interface via Cygwin. There's a > large subset of common functionality across all of these systems which > constitute the UNIX platform. .....the POSIX platform ... right? > Like anything, if you rely on vendor-specific extensions, you break > portability. > > I mean really, to create anything that allows sophisticated > applications to run across multiple platforms, you must specify a > 'meta-platform' which hides the specifics of each specific platform. > This is exactly what Java does. Without this technique, you're forced > to write lowest common denominator code. > > Considering C/C++ in this light would mean sticking with only the ANSI > standards, which wouldn't allow you to leverage any OS facility beyond > basic file I/O > > Java certainly has its blemishes, but how else does one write a > sophisticated application, then pick it up, either binary or source, > and drop it on every major OS and architecture ? UCSD Pascal perhaps? :-) Although now obsolete, that system had precisely the same objective. But UCSD Pascal was too early -- the slow hardware of that time made emulating a pseudo-machine unacceptably slow. And there also was no widespread Internet through which applications could be distributed. > 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 27 May 2006 15:30
It seems appropriate to point out that, given Turing equivalence of all computers (with enough storage and time), "portability" is always assured in principle, though it may require widely varying degrees of effort. Practically, "portable" means "easily ported" and "non-portable" means "difficult to port". -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." |