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.

Microcap & Penny Stocks : Patriot Scientific - PTSC -- Ignore unavailable to you. Want to Upgrade?

To: Benedict Arnold who wrote (4100)	12/29/1997 11:57:00 PM
From: Jon Tara	Read Replies (1) \| Respond to of 8581

In other words, those "sound bites" are inaccurate, but that's OK, because the investors know better. Or, it's OK to fib, as long as your investors are smart enough to know you are fibbing. If you don't think that that's OK, then stop perpetrating the fib by speaking in sound-bites about the PSC1000 being a "Java processor", which it isn't. It wasn't designed to be one, and it isn't one, plain and simple. It was, in fact, designed to be a Forth processor. Somewhere along the line somebody slapped some Java marketing spin on it, and it stuck. The PSC1000 may well be "an excellent processor for Java applications", "ideally suited for executing Java byte code", may "greatly simpilfy the design of just-in-time compilers", etc. etc. etc. (I'm not commenting one way or another whether or not it is.) Why not use these more accurate terms in your sound bites? (I address this to both you and the company.)

To: Benedict Arnold who wrote (4100)	12/30/1997 9:54:00 AM
From: Kunal Singh	Read Replies (1) \| Respond to of 8581

Well said Benedict, You've made two important points: 1) The bytecode to opcode translation being straightforward is important 2) The most often used bytecodes being directly translated is more important than an arbitrary larger number of bytecodes being easily translated. I would like to make one more point regarding the translation: The complexity of the JIT compiler used to do the translation is significant. An embedded system cannot rely on a huge virtual memory space to execute a compiler that itself is an executable of several megabytes even if such a process can yield very efficient native code. We're not necessarily talking about full fledged computers here with a disk drive and swapping that can accomodate any JIT compiler! The JIT compiler for embedded systems has to be small and efficient! If most often used java bytecodes map to PSC1000 opcodes, then it is a matter of a simple lookup in a table! The compilation process for those instructions becomes rather trivial! As for the rest, the subroutines that have to be provided to support the other operations will be fewer in number and will take up less space on the system, probably stored in ROM/EPROM/SRAM! But in any case, the executable size itself will be small if most instructions don't expand to many opcodes which will be another advantage for a smaller system. Any processor CAN RUN JAVA! But the issue is how many routines have to be stored in the ROM and how large the executable is after it is translated! If every opcode translates to a subroutine call, the size of the executable could grow considerably, requiring greater RAM for running!