Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Insignia Solutions (INSG) -- Ignore unavailable to you. Want to Upgrade?

To: Javaaah who wrote (574)	1/26/1999 4:36:00 PM
From: Charles Tutt	Respond to of 1606

So how does everyone feel about the "earnings" announcement?

To: Javaaah who wrote (574)	1/26/1999 5:14:00 PM
From: Prognosticator	Read Replies (1) \| Respond to of 1606

Hi Javaaah. You have some interesting points, I'd like to discuss further. Java CPUs bring their own problems with them, also. True, they are fast, cf. interpreted Java bytecodes, but remember that the standard bytecodes are designed to prevent uncontrolled access of machine resources ... for example, there are no bytecodes for accessing memory at arbitrary addresses, or for accessing device ports. To get round this, Java CPU manufacturers have defined their own superset of Java bytecodes, where the non-standard bytecodes have special meaning to that CPU. Hence CPU A may use a different bytecode to CPU B to access some device port. This then means that you have portability issues for a Java based OS (not for the Java apps). Fair enough. The Java CPU's do have to have extra opcodes, since it is clearly impractical to write a JVM in Java (to my knowledge, no one has managed that yet). So that means your operating system will be tied to the architecture of the chip. No problem really, I don't know anyone who want's to dynamically load new operating systems :) But above that level of abstraction you are back into Java, and those bytecodes can be ripped through by the hardware. Also, Java may not be the only game in town on embedded devices ... there may be other non-Java apps running as well. This too could reduce the usefulness of a Java CPU. In this scenario, a Java VM and some sort of RTOS offer more flexibility. I guess that you'll find the standard CPUs more prevalent in embedded devices, in preference to Java CPUs. At present I'd have to conceded this point, but in future I think you'll seem more pure-Java applications and the RTOS and underlying CPU architecture will become increasingly irrelevant. This assumes that Sun's Embedded Java initiative fixes things like only 10 priority levels, i.e. I'd hope to see a full priority-inheritance mechanism in the java.lang.Thread or whatever it becomes, and that they can come up with a Java API for all the useful RTOSs things like message queues and semaphores (shouldn't be too hard). Of course, this wouldn't be to the advantage of the current RTOS manufacturers (no lock-in!), so expecting them to help set the standard may be too optimistic. With price being so important to consumer electronics manufacturers, I'd say that a pure-Java solution with no RTOS royalties or JIT royalties, and screaming-fast low-power 32-bit hardware would be very attractive. Not to mention easy to program and field upgradable.