Slashdot Mirror

You forgot assemble.
Oh, and some micro-processors implements java in hardware. DID I JUST BLOW YOUR MIND?

Finally a chip that you can run Java on.

>compiled java class are effectively machine code for a machine that doesn't exist Maybe you mean machine code for a processor that might not exist on the host machine. aJile Systems has a Native Java processor that runs at 100 MHz. It's assembly code IS Java Byte Code. Check out Ajile Systems for the processor. Or you can see products that use them at JStik.com. You can also check out benchmarks at PracticalEmbeddedJava.com. Your distinction is vaild, but he does have a point. Unless the host machine natively understands the "bytecode", then the bytecode runs on an interpreter ie JVM.

Assuming that what you mean by "the potential size of the instruction set" is the number of opcodes (i.e. ADD, MUL etc. think 'function') that are available in the instruction set. I think that you might have misunderstood what a 64-bit processor is.

The 'bitness' of a processor has NO relationship to the number of opcodes. A 64-bit chip will not have 2^64 opcodes (or even the possibility of such a thing).

The 'instruction-size' of a given architecture may be a constant size (i.e. 32-bit) however, this refers to the size of a complete instruction. That is the encoded opcode and the operands (i.e. register0, #0x01 etc. think 'parameter'). Some architectures (such as ARM) have a constant instruction-size (all ARM instructions are 32-bit). Others, such as x86 have a variable instruction-size (x86 instructions can vary from 4 to around 11 bytes).

Current CPU design methods call for a reduced number of opcodes. This is because the number of opcodes is limited by the fact that each opcode requires an actual physical piece of silicon to execute it. So more opcodes = more silicon and more silicon = hotter (which can mean slower) and more expensive chips.

x86 has alot of opcodes, however, these are not 'real'. The x86 architecture is a 'micro-architecture' which means that each instruction is actually decoded into a number of smaller operations (called micro-ops). In the case of micro architectures, there is a smaller piece of silicon to decode the opcode into micro-ops, and then several other pieces of silicon to execute the resulting micro-ops, however, these are shared between many opcodes. This allows x86 to have a large number of opcodes for backwards compatability, without a crippling chip size. The extra silicon needed for each opcode is relativly small but the whole set of opcodes can be implemented by a much smaller number of micro-ops.

The downside to this is that a number of the opcodes are very slow, as they decode to alot of micro-ops. These opcodes are not really used by modern compilers/programmers because they can normally be replaced by a sequence of several other instructions that are faster (as they decode to less micro-ops or 1 micro-op in some cases).

What a "64-bit processor", normally means is that the GPRs in the processor are 64-bit. The main advantage of this is that larger integers can be represented by the GPRs which also means that 'larger' pointers can be held in them. Hence a larger memory space can be directly addressed by the machine (i.e. the machine can have more RAM).

64-bit processors also normally come with 64-bit architectures so the memory bus etc. is wider.

There's really no way that a "higher-level" language could be implemented effectivly in hardware. It doesn't make any sense. C++, C and Java are all compiled anyway, and the python interpreter is way to complex to put into hardware. There is a chip that executues the Java byte-code instruction set in hardware. But that's the closest that you're going to get, and really, coding in Java byte-code is both painful and pointless.

Anyway, to say something slightly on topic. I have found that going back and learning alot of asm has definatly made me better at my job. I haven't read the book, but I believe that it's a sound approach if you want to work in a field where performance really matters (like games) to look at asm first. However, if you're going to be a database programmer or make business tools or somthing, you can probably find better things todo with your time.

What about this? [.pdf document] There are several such processors out there.

I "sniff" two main arguments out of this article:

1. is that java is not reliable: eg: inherently unstable (understandable b/c its a complex problem), AND this memo exposes some of the design issues over the progressing releases of java (which they actually classify as bugs (not in runtime or anythiing, but in usability and maintainability).

2. is the performance aspect that they are whining about. (both timewise, and memorywise).

Well....for the amount of garbage collection and optimization that goes on in a JRE (like the HotSpot (tm) and what not...)its not wonder that its "big". Sheesh, it took 30 years to figure out primes in P http://www.cse.iitk.ac.in/news/primality.html , and what? its been less than 10 years since gosling has managed to convince sun that java is worth it.
Anyway, theres a reason python and eiffel are more stable...they do less optimization. Please don't argue that python is anywhere near as fast as java. The computer language shootout, OR just experience with both languages can tell you this.

Anyway, I think that ultimately, computers should have something like a co-processor for bytecoded languages. Everyone needs to get together (like the now-dying parrot project), make a SOLID standard for a bytecode and for a hardware implementation, and sit back and enjoy the ride (eg http://www.ajile.com/ ...but based on something less proprietary). Heck we have graphics cards dont we!

Finally,if sun is bailing, im sure a CS department/thinktank will pick up a grant and continue with java in a completely non-proprietary fashion (java *is* open source, just too proprietary to conflict with GNU and what not... (not like im a gnuru or anything).

Im sure theres something im forgetting. thank ya.

Check out this PDA reference platform by Ajile. The processor is aj-100, 100% native java CPU. So even the device drivers are in Java.

Ajile's AJ-100 and AJ-80 chips implement native Java instruction set. You grab a development board from Systronix . Which means you write your device drivers in Java!

A number of the negative statements about Java have been attributed to the JVM. I agree that the JVMs out there are generally poor for embedded apps, but is that really the core problem? Is embedded JVM too slow or is Java itself inherently inappropriate?

It's easy to forget how Sun's picoJava cores got canned. According to Sun starting in 1996 the answer to poor embedded JVMs was to announce a silicon chip that executed Java directly. picoJava I was a JVM-like execution engine, executing bytecodes in silicon. That was too limiting though, so Sun announced picoJava II, introducing about 50 new opcodes so it could be used for C and C++! Sun even hired MetaWare to write a C compiler for their Java chip!

Sun's microJava 701, based on the picoJava II core, was supposed to be a standard product produced and shipped in commercial quantities. However, Sun cancelled those plans in 1999. The microJava 701 was produced in small sample lots, but ultimately its death was hastened by poor demand and lack of commercial acceptance.

The same can be said of Java-on-silicon generally. With a few notable exceptions, several high-powered semiconductor manufacturers have failed to bring Java ICs to market despite initally signing on with Sun. Fujitsu, Siemens, IBM, Sun, NEC, and Rockwell/Collins fill out the list of no-shows to the Java-chip game.

Yes there are a few chips out there like Ajile Systems (former Rockwell/Collins technology), and Patriot Scientific, but if Sun and all these other big boys can make Java-on-silicon fly, what does that say about Java in the embedded space?

One man's opinion.