Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #21512

Re: Algorithm design: computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!)

Show all headers | View raw

Andrew Haley wrote:

> rickman <gnuarm@gmail.com> wrote:
>> On 3/20/2013 2:41 PM, Stephen Pelc wrote:
>>> In a private email, someone commented to me that stack machine
>>> hardware is a substitute for a good code generator.
>> 
>> Do you consider that to be true?  Is a code generator for a small,
>> register based CPU like one of the low end PICs really that
>> difficult?
> 
> Oh, yes.  Really difficult.  Getting anywhere close to what you would
> write by hand on such a machine is a huge effort.  Generating bad code
> is really easy, but there isn't much ocde space.

There used to be a time when there were more language-specific processors, 
and people spoke about "the semantic gap".  They created even Lisp 
processors!  At that time, about all CPUs were what we would consider 
"small" today.

That talk about the semantic gap silenced with the RISC processors.  Instead 
of trying to make the hardware do what the software wants, the CPU provides 
useful instructions for powerful code generators.

However, Forth CPUs are a bit odd in the "closing the semantic gap", as 
Forth already closes the semantic gap by providing an execution model that 
is particularly easy to implement in hardware directly, especially when you 
are resource constrained.  You can easily do a Forth CPU in the size of a 
PIC, and both the Forth CPU and the "code generator" are 200 lines of code 
or so.  Doing a Lisp CPU in the size of a PIC is certainly impossible, and 
the Common Lisp code for a Lisp CPU is still huge.

Something about the cost argument: If you do a high-volume product, 
integration is king.  What I did with my b16 chips were always "solutions", 
i.e. fully integrated chips that did solve a problem for which there was 
enough demand that a chip was cost effective.  If you build from components, 
you are going to lose.  The first b16 project, a exhaust valve controller, 
had a competitor which had this standard "assemble component" approach.  His 
board did cost about 20€, our board about 5€ (our chip plus an off-the-shelf 
half bridge, since a 20V+ half bridge can't reasonably be done on the same 
silicon as a CPU).  The result was that our customer, who first targeted a 
premium car maker (because this exhaust valve was supposed to be too 
expensive) got a higher volume contract first, before the premium car maker 
even completed his evaluation.  Price does matter, and only volume brings 
the price down.  And the key to volume is that your price is below the 
market elasticity point.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

Back to comp.lang.forth | Previous | Next — Previous in thread | Find similar

Thread

Re: Algorithm design:  computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) rickman <gnuarm@gmail.com> - 2013-04-05 10:44 -0400
  Re: Algorithm design:  computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-05 22:12 +0200
  Re: Algorithm design:  computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-04-06 02:46 -0500
    Re: Algorithm design:  computational cost of ordinary stack operations (dup, rot, over, swap, etc.) vs. cost of fetch (@) and store (!) Bernd Paysan <bernd.paysan@gmx.de> - 2013-04-08 17:53 +0200

csiph-web