6502 illegal opcodes questions
in [Commodore]
|
Prev: what happened CBM=VGA
Next: 1581 Drive Kits on eBay
From: mdj on 25 May 2006 04:10 Paul Schlyter wrote: > What "Java portability" ???? > > Java is not a portable language. Java is less portable than both > FORTRAN, C or C++, which runs on several platforms. Java runs on one > single platform only: the Java platform. Sorry, this isn't true. The Java language specification is quite deliberately void of any language construct that would bind it, or any program written in it to a specific architecture. The key concepts that are missing here are pointers, and more specifically, the ability to perform arbitrary arithmetic on pointer types. Additionally, the language specification defines EXACTLY the size and precision of each data type. 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. It is impossible to write a Java program that's bound to a specific machine architecture. 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. Ever tried porting some C code to a 64 bit platform? Many C compilers implement int as a 32 bit quantity even on 64 bit architectures, 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. 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. The first 64 bit platform that GNU/Linux was self hosting on was the Alpha (God bless it's soul). This particular portability issue with C was the primary reason many good open source programs were not available on this architecture. Java can, and has, been implemented without the virtual machine. The GNU compiler for Java for instance, can generate machine-code 'class' files that run on a UNIX platform using the standard dynamic library loader mechanisms available there. It can do this from both Java source, and Java bytecode. Even if the VM is taken away, the source level representation is still portable to any other Java implementation. 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. > The Java platform doesn't exist in hardware - it must be simulated > in software. "But that means Java is portable: I can run my JVM on > several other platforms" -- true, but if you define "portability" in > such a way, then all Windows software becomes equally portable: just > start your favourite Windows emulator on either your Mac or your Linux > machine, and run your Windows software on it.... I'd be interested to hear a definition of 'portable' that doesn't apply to Java, platform or language. I'd be prepared to conceed that perhaps Linux could be considered "more portable" as it's a 'platform' that's been ported to more architectures than perhaps any other in history. The fact remains though, than even with Linux, one must be very cautious not to write code in a machine dependant way while using it's 'natural' languages. 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. 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. Ironically, Microsoft made the same design decision with .NET, by providing the facility of unmanaged code. While this allows you to easily leverage existing functionality, it also ties you to it, and is undoubtedly the primary reason there was no 64 bit .NET VM for IA64 for so long. Is there even one now? I bet Intel people, particularly on the 64 bit side of the fence curse Microsoft every night, as without the ties that MS has between it's operating system and x86 architecture, there'd be a lot more room in the marketplace for a successor to x86, rather than just another extension. My only real gripe with the Java platform is that it's controlled, essentially, by a single company with it's own agenda. There's still no complete implementation of Java that's independent of Suns, and everyone on the supposed JCP ultimately has to play second fiddle to Suns iron first. To be though, this is still significantly better than being tied to both a proprietary platform, and a machine architecture, which is essentially the position that Microsoft developers are now in. For me, the reason UNIX has endured as a platform for so long is that it remains the ONLY platform which has a well specified, simple, architecture agnostic API, and as a result has been implemented and ported many times over. The next most ported platform after UNIX, is probably Java, and it'll probably stay that way for quite some time. Matt
From: Bruce Tomlin on 25 May 2006 10:37 In article <e53i7m$1set$1(a)merope.saaf.se>, pausch(a)saaf.se (Paul Schlyter) wrote: > The Java platform doesn't exist in hardware - it must be simulated > in software. "But that means Java is portable: I can run my JVM on I thought Java bytecodes, or at least a significant portion of them, actually had been implemented in hardware. But I know for certain that UCSD P-code had been implemented in hardware once at least once in the mid '80s. I think it was called the "P-Engine", and Jerry Pournelle mentioned it in his column in Byte. Likewise, I recall that a significant portion of Smalltalk bytecodes and primitives were implemented in hardware at Xerox, using the Dorado's capability for downloadable microcode. So just because someone makes up an instruction set for a virtual machine doesn't mean that it can't (or won't) be implemented in hardware. There may be a few of the more complicated instructions that have to be trapped out and implemented in terms of the less complicated instructions, but if someone feels a need to do so, it can get implemented in hardware. (So when is someone going to take up the challenge and implement Zork's instruction set in VHDL?)
From: heuser.marcus on 25 May 2006 12:34 > I thought Java bytecodes, or at least a significant portion of them, > actually had been implemented in hardware. There are indeed implementations. IIRC Sun tried to establish a hardware platform for "web computing" (those small diskless PCs with funky colors looking like coffee machines): http://news.com.com/Java+chip+not+picking+up+steam/2100-1033_3-216359.html It failed miserably, but that didn't stop others http://www.xilinx.com/prs_rls/0134lavacore.htm http://www.particle.kth.se/~lindsey/JavaCourse/Book/Part3/Chapter24/chips.html bye Marcus
From: Eric Smith on 25 May 2006 16:02 Paul Schlyter wrote: > The Java platform doesn't exist in hardware - it must be simulated > in software. "But that means Java is portable: I can run my JVM on Bruce Tomlin wrote: > I thought Java bytecodes, or at least a significant portion of them, > actually had been implemented in hardware. Yes, Sun offered several chips that executed Java bytecodes. They were not commercially successful. > But I know for certain that > UCSD P-code had been implemented in hardware once at least once in the > mid '80s. I think it was called the "P-Engine", and Jerry Pournelle > mentioned it in his column in Byte. Western Digital "Pascal Microengine". It implemented the p-code interpreter in microcode, on the same chipset used in the LSI-11 and Alpha Micro AM100. > Likewise, I recall that a significant portion of Smalltalk bytecodes and > primitives were implemented in hardware at Xerox, using the Dorado's > capability for downloadable microcode. Yes, and before that on the Xerox Alto. > (So when is someone going to take up the > challenge and implement Zork's instruction set in VHDL?) Sounds like a fun project; if I didn't already have a zillion projects I want to do, I'd be tempted.
From: Paul Schlyter on 26 May 2006 08:43
In article <1148544621.115246.248890(a)y43g2000cwc.googlegroups.com>, mdj <mdj.mdj(a)gmail.com> wrote: > Paul Schlyter wrote: > >> What "Java portability" ???? >> >> Java is not a portable language. Java is less portable than both >> FORTRAN, C or C++, which runs on several platforms. Java runs on one >> single platform only: the Java platform. > > Sorry, this isn't true. The Java language specification is quite > deliberately void of any language construct that would bind it, or any > program written in it to a specific architecture. 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"). > 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. > 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. > 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. .....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 ...... > 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....... :-) > 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. > 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. C code which assumes a pointer to be of the same size as an int is broken. That assumption was invalid already in the 16-bit world, where an int naturally was 16 bits while a pointer could be 16 or 32 bits, depending on the memory model. In one and the same program, a function pointer could even be of a different size than a data pointer. > 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. > The first 64 bit platform that GNU/Linux was self hosting on was the > Alpha (God bless it's soul). This particular portability issue with C > was the primary reason many good open source programs were not > available on this architecture. > > Java can, and has, been implemented without the virtual machine. The > GNU compiler for Java for instance, can generate machine-code 'class' > files that run on a UNIX platform using the standard dynamic library > loader mechanisms available there. It can do this from both Java > source, and Java bytecode. Even if the VM is taken away, the source > level representation is still portable to any other Java > implementation. 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 !!!!! >> The Java platform doesn't exist in hardware - it must be simulated >> in software. "But that means Java is portable: I can run my JVM on >> several other platforms" -- true, but if you define "portability" in >> such a way, then all Windows software becomes equally portable: just >> start your favourite Windows emulator on either your Mac or your Linux >> machine, and run your Windows software on it.... > > I'd be interested to hear a definition of 'portable' that doesn't apply > to Java, platform or language. I'd be prepared to conceed that perhaps > Linux could be considered "more portable" as it's a 'platform' that's > been ported to more architectures than perhaps any other in history. > The fact remains though, than even with Linux, one must be very > cautious not to write code in a machine dependant way while using it's > 'natural' languages. > > 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.... > 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? > Ironically, Microsoft made the same design decision with .NET, by > providing the facility of unmanaged code. ....and Java did it with JNI.... > While this allows you to > easily leverage existing functionality, it also ties you to it, and is > undoubtedly the primary reason there was no 64 bit .NET VM for IA64 for > so long. Is there even one now? I bet Intel people, particularly on the > 64 bit side of the fence curse Microsoft every night, as without the > ties that MS has between it's operating system and x86 architecture, > there'd be a lot more room in the marketplace for a successor to x86, > rather than just another extension. > > My only real gripe with the Java platform is that it's controlled, > essentially, by a single company with it's own agenda. 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. > There's still no > complete implementation of Java that's independent of Suns, and > everyone on the supposed JCP ultimately has to play second fiddle to > Suns iron first. To be though, this is still significantly better than > being tied to both a proprietary platform, and a machine architecture, > which is essentially the position that Microsoft developers are now in. 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. > For me, the reason UNIX has endured as a platform for so long is that > it remains the ONLY platform which has a well specified, simple, > architecture agnostic API, and as a result has been implemented and > ported many times over. The next most ported platform after UNIX, is > probably Java, and it'll probably stay that way for quite some time. > > Matt Now even you call Java a platform.... 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. -- ---------------------------------------------------------------- Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN e-mail: pausch at stockholm dot bostream dot se WWW: http://stjarnhimlen.se/ |