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: Prognosticator who wrote (572)	1/26/1999 12:28:00 PM
From: Luce Wildebeest	Respond to of 1606

Thanks I appreciate the time you took to reply to my question. I am the smarter for it. Calvin

To: Prognosticator who wrote (572)	1/26/1999 3:33:00 PM
From: Javaaah	Read Replies (2) \| Respond to of 1606

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). 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. Javaaah