🚀 go-pugleaf

In article <17434@mindlink.bc.ca> Nick_Janow@mindlink.bc.ca (Nick Janow) writes:
>hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>
>> But I would object to any language which insists that we use a strictly
>> stack machine.  Pushing, popping, and calling are to be avoided unless
>> necessary. Otherwise things just run too slowly to be of more than
>> theoretical use.

>Why do you object to the use of a stack machine (on which those operations
>are fast)?  If a stack language on a stack machine will run n times as fast
>as a non-stack language on a non-stack machine of equal technology level, why
>not use a stack machine?

>Don't some languages insist (for reasonable performance) that the processor
>provide registers and addressing modes?

HOW can a stack machine be fast?  One of the features of an efficient program
is to have the quantities needed available in registers.  A dozen or two
registers are usually needed to get decent performance, and often it would
help to have hundreds.  On of my friends in the computing center here tells
me that the 256 registers on the CYBER 205 (more than 220 not tied up by
system operations) is not always enough.

But code such as push x; push y; push procedure Z; execute; pop result to w;
will not execute fast compared to 
		
	w = x Z y,

where registers are used.  Also, efficient programming should take into account
which addressing modes are available.

>> Getting any speed out of machines requires that we think of speed in
>> coding, rather than the fact that it is possible in principle to operate
>> with a stack machine with no registers.  This also ignores hardware, such
>> as vector machines, where the use of a control register or control stream
>> introduces basic bit operations which did not exist before, and which are
>> utterly stupid as a means of efficient computation on a stack machine.

>There's no reason why special hardware can't be added to a stack machine.
>You could, for example, add a pair of FIFO "stacks", which might be useful
>for signal processing operations.

It will still not help if more versatile register-type operatations are
appropriate.  

There is an ongoing discussion in comp.arch of the advantages and disadvantages
of stack machines.  
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@snap.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!snap.stat!hrubin(UUCP)

In <Bxns5v.5uJ@mentor.cc.purdue.edu>, hrubin@pop.stat.purdue.edu (Herman Rubin) wrote:
> In article <17434@mindlink.bc.ca> Nick_Janow@mindlink.bc.ca (Nick Janow) writes:
> >Why do you object to the use of a stack machine (on which those operations
> >are fast)?  If a stack language on a stack machine will run n times as fast
> >as a non-stack language on a non-stack machine of equal technology level, why
> >not use a stack machine?
>
> HOW can a stack machine be fast?  One of the features of an efficient program
> is to have the quantities needed available in registers.

Not quite - delete "registers", and replace it with "fastest available
memory". Most architechtures put that memory in a seperate address
space with special address modes, but neither is required.  There are
machines where the registers are just a particularly fast piece of
ram; there are machines where that address may be set by the
programmer; there are even machines that map the top of the stack into
high-speed memory. The latter would be quite appropriate for a being a
fast stack machine, even though it wasn't designed for that.

	<mike