Path: utzoo!attcan!uunet!samsung!usc!rutgers!rochester!pt.cs.cmu.edu!a.gp.cs.cmu.edu!koopman
From: koopman@a.gp.cs.cmu.edu (Philip Koopman)
Newsgroups: comp.lang.forth
Subject: Re: Forth vs. C
Message-ID: <8458@pt.cs.cmu.edu>
Date: 17 Mar 90 15:43:29 GMT
Organization: Carnegie-Mellon University, CS/RI
Lines: 31

Here is a non-exhaustive list of some things I have noticed
when translating programs from C to Forth (your mileage will vary):

1) Translating C to Forth usually gives you a real mess -- you
  are best off starting from scratch.  Translating from Forth
  to C usually results in a well-modularized program (assuming
  you don't have to translate *too* many compile-time Forth
  tricks).  But, Forth->C usually runs slowly because of the
  awful C overhead for procedure calls.

2) Forth is really good for reducing the overhead for procedure
  calls, even when you are recursing and need to save state in
  memory on every cycle to avoid stack overflows.  This is mostly
  because Forth gives you access to the saving mechanism, and
  C compilers usually must be very conservative since they
  don't know what you really want to do.

3) Forth is pretty poor at juggling large numbers of stack elements,
  corresponding to large numbers of local variables.  I find that
  with more than 2 or 3 active stack elements it is often faster
  and clearer to use local variables, employing a C-like stack
  frame out in memory.  Most of the time, having more than 2-3
  active stack elements is a sign of a poorly written Forth program.
  But, sometimes that is not the case, especially when performing
  double-precision math or 3-D graphics.

  Phil Koopman                koopman@greyhound.ece.cmu.edu   Arpanet
  2525A Wexford Run Rd.
  Wexford, PA  15090
Senior Scientist at Harris Semiconductor, adjunct professor at CMU.
I don't speak for them, and they don't speak for me.