On 6/23/07, Darren New <[EMAIL PROTECTED]> wrote:
Bob La Quey wrote:
> Clock speeds were ~ 10 Mhz. Chips could do an RTI in 2 clock cycles.
> i.e. 200 ns.

> If pigs had wings they could fly.

I'm not sure what that's supposed to imply...  All I was pointing out is
that getting rid of registers and pipelines without losing efficiency is
much easier when your memory is about the same speed as your CPU, which
is not the case in desktop machines any more.

And has not been for some time.

> The core problem for CISC and RISC emulating CISC is
> The interrupt response takes many clock cycles.

Except it's still faster than a 10MHz machine doing it in 2 clock
cycles, if I'm reading properly. :-)

No it is not faster. The x86 architecture and all of those things
that emulate it are, even with twenty years improvement in
technology, still slower at handling interrupts.

The x86 and pipelined RISC technologies are a lot like a freight
train, great at going fast in a straight line but they don't turn
worth a damn. These twenty year old stack architectures turn
on a dime.

Which is not to say the original author is wrong in what he wrote. He's
just addressing a different problem-space than the folks doing RISC (or,
for that matter, CISC) machines are addressing.

To some extent yes. But if you consider programing with more branches
and fewer long runs (lots of little but very hierarchical functions) then the
stack machines start to look very good. Why? Because using the stack
unnamed stack variables leads to very fast function calling and nesting.

I want to bring this back to functional programming. Pure Forth is very
close to being a functional language. The best Forth programs make
serious use of this fact. Factoring a program into a hierarchical collection
of functions is classic Forth style. This has been developed further in a
language like Joy, which is a direct descendant of Forth.

"The language Joy is a purely functional programming language. Whereas
all other functional programming languages are based on the
application of functions to arguments, Joy is based on the composition
of functions. All such functions take a stack as argument and produce
a stack as value. Consequently much of Joy looks like ordinary postfix
notation. However, in Joy a function can consume any number of
parameters from the stack and leave any number of results on the
stack."
http://www.latrobe.edu.au/philosophy/phimvt/joy/forth-joy.html

I note that Forth functions can also take an arbitrary number of of
parameters from
a stack and leave any number of results.

So let's get over this idea that functional languages must not use stacks.
Stack machines are the natural virtual machine for functional languages.
Thus building these machines in hardware holds forth the possibilities of
significant performance improvement.

It gets better. Moore's law is driving us toward many cpus per chip
now since we seem to be hitting limits in the improvements of clock
speed. That other Moore, Chuck is pushing architectures that exploit
this fact. See http://www.intellasys.net/products/seaforth/index.php

I suspect that it would be very easy to host parallel functional
languages on this architecture.

BobLQ

--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg

Reply via email to