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: bob who wrote (4093)	12/29/1997 8:46:00 PM
From: cksla	Respond to of 8581

to all: came across this posting re stack architecture written almost 5 years ago before the existence of java. thought it might be of interest-- especially related to cost, program size, and its conclusion: THAT STACK MACHINES ARE AN EXCELLENT FIT FOR HIGH PERFORMANCE IN A LOW COST SYSTEM.... ESPECIALLY WELL IN EMBEDDED APPLICATIONS. ==================================================================== Why Stack Machines? (A Usenet posting that was printed in Usenet Nuggets, Computer Architecture News, Vol. 21, No. 1, March 1993) This is a consolidated attempt to address some of the points people have been bringing up about stack-based architectures. It's written from the point of view of someone who has actually made a living designing and selling them (first with WISC Technologies, later with the Harris Semiconductor RTX family). Pipelining Stack processors don't need to be pipelined for ALU and operands, because the operands are immediately available in the top of stack buffer registers. Access to the on-CPU stack RAM can be completely hidden by pipelining. Access to off-chip memory is typically not pipelined in current implementations, but can be (P. Koopman, "Some Ideas for Stack Computer Design", 1991 Rochester Forth Conference, Pg. 58). It makes sense that the false dependencies introduced by stack addressing could be overcome with a superscalar implementation if one were so inclined (but, I'm not). Stack Size and Interrupts On-chip stack buffers only need to be about 16 deep. Spilling can be done by stack overflow interrupts (or, for that matter, statically scheduled by the compiler the same as register spills). Cost for interrupt-driven overflows is less than 1% for only 16 registers and essentially 0% for 32 registers for reasonable programs (P. Koopman, Stack Computers, pp. 139-146). A neat thing about stack CPUs is that context switching for interrupts takes essentially zero time -- no registers need to be saved; you just put the ISR values onto the top of the stack and clean them off when you're done (presumes enough stack space is available -- no big deal to arrange). (P. Koopman, Stack Computers, pp. 146-152.) Program Size Program size doesn't matter (much) for workstations. But, for embedded control it matters a lot, especially when you're limited to on-CPU chip memory, and the CPU has to cost less than $5-$10. Anecdotal evidence indicates stack computer program size can be smaller than CISC programs by a factor of 2.5 to 8 (and, another factor of 1.5 to 2.5 smaller than RISC, depending whom you want to believe). This comes not just from compact opcodes, but also from reuse of short code segments and implicit argument passing with subroutine calls. Code size comparisons I've seen don't take this into account. (P. Koopman, Stack Computers, pg. 118-121.) Compilers Stack compilers aren't currently very efficient -- but that's because no-one has really tried all that hard. I've published an algorithm and experimental results that suggest that stacks can be made about as efficient as registers in terms of keeping local variables at the top level of the memory hierarchy. The work is based on GNU C intermediate code (P. Koopman, A preliminary exploration of optimized stack code generation", Journal of Forth Applications and Research, 6(4), 1994.) Applications Overall, I'd say that stack machines are an excellent fit for high performance in a low cost system (not necessarily highest performance given unlimited cost). They should do especially well in embedded applications.

To: bob who wrote (4093)	12/29/1997 8:57:00 PM
From: Jon Tara	Read Replies (2) \| Respond to of 8581

Bob, I beleive that you must have misunderstood what Clay told you. A certain percentage (don't know if it's 79% or not) of the instruction set of the PSC1000 is substantially identical in function to instructions in the JVM. However, they are NOT binary compatible - the bytecodes must be altered before executing on the PSC1000. Further, the remaining instructions must be emulated in software, and the PSC1000 does NOT provide any hardware solution to help with this. (The Sun Java processors do.) Any of the Sun Java processors will execute Java bytecode natively, without any translation. While they do not implement the full JVM instruction set, they include a hardware "trapping" mechenism that allows software to seamlessly take over. (The way this works is very similar to the way that early 808X processors that did not have a built-in numeric processor handled floating-point instructions if you did not have an NDP chip plugged in.) Repeating - the PSC1000 does NOT have this 'trap' mechenism - the Sun chips DO. In my opinion, ANY stack-based architecture will have a very high congruence with the JVM instruction set. This is because in a stack architecture, there are a large number of opcodes that are just required for any practical design, and that can basically only be done one way. So, any stack-architecture machine is going to have an ADD instruction (whether it is called ADD or AD or A or ADDTWOFRIGGINNUMBERS) and it is going to add the top two elements of the stack, remove those elements from the stack, and place the result on the stack. There are enough of these basic instructions in any stack machine that there is going to be high percentage of "hits". Remember that the PSC1000 was NOT DESIGNED FOR JAVA. It is simply a happy accident that it wound'up being well-suited for executing Java code (as would be any stack-architecture machine).