Re: Stack based machines

Linus Thand <thand@pmail.net> wrote:
>> What is happening in the world of stack-based machines?
>> Are there any active groups working on processors or
>> compilers (I'm especially interested in functional languages).
>>
>> [Other than forth, not much I'm aware of. Registers give an architecture
>> a big performance boost, and it's hard to fake that by caching to top of
>> the stack. -John]


  plakal@cs.wisc.edu wrote:
> Well, there's the whole Java thing and Sun making
> those processor cores: {micro,pico,ultra}Java which
> I believe are all stack machines. I do remember
> reading a design document from Sun a long time back
> which described mapping the top elements of the stack
> to registers in at least one of these processors.
>
> Manoj
>[There have been lots of stack architectures that kept the top of the
>stack in registers, but it's my impression that performance is worse
>than real registers. Registers hold common subexpression values and
>hot loop variables as well as expression temporaries, and stack
>caching doesn't easily get either of those. -John]


I don't think Forth chips typically have too much support for this
feature, but Forth software often does. There are the words I and J
that read the top and second-to-top values from the return stack, so
if you want a couple register-like temporaries you can implement I and
J as instructions and have the return stack on chip. I'm not sure how
popular this is, but I know that all the forths I've used store loop
counters in I.


Another thing that negates some of the problem: when Forth heads (at
least Chuck Moore, Jeff Fox, et al) see a problem they tackle it
fundamentally differently than most people do, I think -- much more
application of KISS principles. Upon realizing that their language
doesn't really use registers, rather than making a registerizing
compiler (which is dificult with forth but not really any more
difficult than with any other language, it's just that everything else
in forth is so easy for them that they don't want to add complexity),
they want a stack chip. When they realize that designing a chip is
hard, they simplify it and do it entirely on their own (Chuck Moore
using OK/OKAD). When they realize that memory access is slow, they
ask why? It seems that most people need a lot of RAM and cannot
afford to have all of it as SRAM so they need caches. Well if you're
following KISS you can have 32k of SRAM and have that be your whole
system or if you need more you can have performance-critical code in
the 32k SRAM and have other code and data in cheaper DRAMs. It's much
simpler for a Forth head to put performance-critical code in the SRAM
than for them to design and test a high-performance cache. They see
that each instruction on their processor is so simple that often
they'll need a lot of them to do what other processors do in one
instruction, but this doesn't phase them because they know that their
instructions are simple and can be executed really quickly in a
non-pipelined machine.

Return to the comp.compilers page.
Search the comp.compilers archives again.