From: eoahmad@ntuix.ntu.ac.sg (Othman Ahmad)
Newsgroups: comp.arch,comp.lang.forth
Subject: Re: What's RIGHT with stack machines (Was Re: What's wrong...)
Date: 5 Nov 92 05:06:40 GMT
Organization: Nanyang Technological University - Singapore
X-Newsreader: TIN [version 1.1 PL6]

Philip Koopman (koopman+@cs.cmu.edu) wrote:
: 
: 
: 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 who has actually
: made a living designing and selling them (first with
: WISC Technologies, later with Harris Semiconductor RTX family).
: 
: PIPELINING
: 
: Stack processors don't need to be pipelined for ALU & 
: operands, because the operands are immediately available
: in the top of stack buffer registers.  Access to the on-CPU

Pipelining is required for maximum performance but I do not foresee any
special problems with implementing stack based pipelined operations.
Just use invisilbe registers, and better still multiple stack architecture.
It is extremely attractive to me in DSP applications where lists are the
most common data structures used.

: embedded control it matters a lot, especially when you're limited
Refer to another posting on why code size is till important for the ultimate
performance. Basically it is the cache bottle-neck that I observe in 
current microprocessors running only still relatively simple programs.

: 
: 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, 1992
: Rochester Forth Conference, in press; uuencoded postscript
: copy of paper available upon request).
: 
: I'm currently working (at hobby level) on a GNU C stack-based compiler 
: that will generate very compact code.  Of course, one could
: always argue that trying to map C to a stack machine will
: necessarily be less efficient than mapping a stack-friendly
: language such as Forth to a stack machine.  The issue starts
: to have more to do with marketing than technology, but
: seems like a neat challenge.

I have not tried this yet but from my experience writing a "sissy
compiler", I  notice that my intermediate data structure is a linked list.
It may not be optimal but it is not optimal becaue the input is not 
optimal.
	After all the compiler just generate what we ask it to do.

The optimisation should be done at the source code level.

I also observe that the advantages of the 3 address opcode is exaggerated.
When I look at a "convolution code fragment", I do not recall any 3 address
instruction genereated by GCC for sparc.

What is the point of providing a 3 address when 99% of the cases need only
2 address? Tanenbaum had written a paper analysing the frequencies of the
number of operands.
	I do not pay particular attention because it is too dependent on the
test programs.

Someone will say that "convolution code is not frequent".
You can think of it as operations on link lists.
	Isn't that a very common operation. Of course it can be substituted
by the 3 address instructions, but isn't it more natural to use a special
stack machine for it?

I'm posting this article because I could be dead wrong. I'll try to
read Kopman's paper but I doubt it will address my suspicions.

Any comment is most appreciated.
: 
: APPLICATIONS
: 
: Overall, I'd say stack machines are now 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.  
: 
I believe you could be wrong. the T9000 is nothing compared to better 
designed stack machines.
	It is only waiting for better compilers and architectures. Admittedluy
it is harder but may be worth it to overcome the von-neuman limitations,
or rather optimizations of bandwidth.

--
Othman bin Ahmad, School of EEE,
Nanyang Technological University, Singapore 2263.
Internet Email: eoahmad@ntuix.ntu.ac.sg
Bitnet Email: eoahmad@ntuvax.bitnet