Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!news.stack.nl!aioe.org!.POSTED!not-for-mail
From: "Rod Pemberton" <dont_use_email@xnothavet.cqm>
Newsgroups: comp.lang.forth
Subject: Re: gforth too bloated ?
Date: Sat, 17 May 2014 20:30:21 -0400
Organization: Aioe.org NNTP Server
Lines: 74
Message-ID: <op.xf040vgo6zenlw@localhost>
References: <4b4ea6f6-3b09-434a-a501-ff31190b9f4a@googlegroups.com> <dYSdncZm_NehYvDOnZ2dnUVZ_rydnZ2d@supernews.com> <2014May10.123904@mips.complang.tuwien.ac.at> <7qadnesZfp6twfPOnZ2dnUVZ_qGdnZ2d@supernews.com> <2014May11.141024@mips.complang.tuwien.ac.at> <kv2dnZxzlai0Ge3OnZ2dnUVZ_hidnZ2d@supernews.com> <2014May13.184005@mips.complang.tuwien.ac.at> <47qdnXip89VGwe_OnZ2dnUVZ_jadnZ2d@supernews.com> <2014May14.140323@mips.complang.tuwien.ac.at> <yaqdnbUix53lHOnOnZ2dnUVZ_s2dnZ2d@supernews.com> <2014May16.183349@mips.complang.tuwien.ac.at> <XM2dnY8S6fTrw-rOnZ2dnUVZ_tGdnZ2d@supernews.com>
NNTP-Posting-Host: CNsg4fVcCsvs3UaOgZtQCw.user.speranza.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Opera Mail/12.16 (Linux)
X-Notice: Filtered by postfilter v. 0.8.2
Xref: csiph.com comp.lang.forth:30442

On Sat, 17 May 2014 09:04:54 -0400, Andrew Haley  
<andrew29@littlepinkcloud.invalid> wrote:

> Looking at your paper, it seems that to get good [performance]
> from Forth in C, you need a lot of primitives, so you need a
> primitive generator.

I think it's true of Forth in general that you need a lot of
primitives to get good performance.

I haven't been following this thread, so this reply may be
"out in left field" a bit ...

In Forths that use "primitives" (low-level) words, the primitives do
the work.  The high-level Forth words are just nesting overhead which
eventually call the primitives to do some work.

A high-level colon definition can call other high-level definitions
or low-level "primitives".

( >R R> DUP SWAP are primitives )


In C, that'd be something like:

void over(void)
{
   to_r();
   dup();
   r_from();
   swap();
}

void tuck(void)
{
   swap();
   over();
}

As you can see, the high-level definitions for TUCK and
OVER don't do any work.  They just call other high-level
words in Forth or other procedures in C.  This is unneeded
overhead.  to_r() dup() r_from() swap() do the low-level
work. (Not shown.)  These do the appropriate data and
return stack manipulations in C or assembly.

So, for Forth to be efficient, all high-level words,
TUCK and OVER in this example, need to be re-coded or
compiled as low-level words or "primitives" in C or
assembly.  This is true of a Forth with it's base code
in C or assembly.

So, instead of calling other functions, over() and tuck()
in C would contain inlined C functions, or the direct stack
operations coded in C similar to what's used to implement
to_r() dup() r_from() swap() etc, or inlined assembly.

In Forth, you'd start by expanding TUCK by replacing OVER
the only non-primitive in the definition:

: TUCK SWAP OVER ;
: TUCK SWAP >R DUP R> SWAP ;

At which point, since this was a simple definition, with
minimal nesting, we're done.  TUCK is now written in terms
of primitives.  The only other step that can be taken is
to code TUCK directly in assembly or C.

If this was a more complicated high-level word, you'd
keep unrolling until you're complete, then rewrite in C
or assembly, as appropriate.


Rod Pemberton