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

Groups > comp.lang.forth > #42204 > unrolled thread

New to the group

Back to article view | Back to comp.lang.forth

Contents

  New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-26 15:17 -0700
    Re: New to the group mentificium@gmail.com - 2015-09-26 17:35 -0700
    Re: New to the group hughaguilar96@gmail.com - 2015-09-26 21:16 -0700
      Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-27 07:27 -0700
        Re: New to the group rickman <gnuarm@gmail.com> - 2015-09-27 14:43 -0400
          Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-27 13:05 -0700
          Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-09-27 12:57 -1000
          Re: New to the group Paul Rubin <no.email@nospam.invalid> - 2015-09-27 17:00 -0700
            Re: New to the group hughaguilar96@gmail.com - 2015-09-27 17:16 -0700
              Re: New to the group rickman <gnuarm@gmail.com> - 2015-09-27 20:31 -0400
              Re: New to the group jfong@ms4.hinet.net - 2015-09-27 18:57 -0700
                Re: New to the group hughaguilar96@gmail.com - 2015-09-27 19:37 -0700
                  Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-27 20:53 -0700
                    Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-09-27 19:02 -1000
                      Re: New to the group hughaguilar96@gmail.com - 2015-09-27 23:33 -0700
                        Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-28 04:51 -0700
                          Re: New to the group rickman <gnuarm@gmail.com> - 2015-09-28 12:39 -0400
                    Re: New to the group Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-09-28 14:29 +0200
                      Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-28 07:18 -0700
                        Re: New to the group foxaudioresearch@gmail.com - 2015-09-28 08:07 -0700
                        Re: New to the group Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-09-28 17:23 +0200
                          Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-28 11:16 -0700
                            Re: New to the group rickman <gnuarm@gmail.com> - 2015-09-28 14:25 -0400
                              Re: New to the group anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-29 09:05 +0000
                            Re: New to the group Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-09-28 20:31 +0200
                              Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-28 13:20 -0700
                                Re: New to the group Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-09-28 22:52 +0200
                                  Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-28 16:40 -0700
                        Re: New to the group Alfred Singlestone <vitonis@gmail.com> - 2015-09-28 08:41 -0700
                        Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-09-28 11:41 -1000
                          Re: New to the group hughaguilar96@gmail.com - 2015-09-28 21:33 -0700
                      Re: New to the group jfong@ms4.hinet.net - 2015-09-28 19:13 -0700
                        Re: New to the group rickman <gnuarm@gmail.com> - 2015-09-29 00:51 -0400
                          Re: New to the group jfong@ms4.hinet.net - 2015-09-29 18:26 -0700
                            Re: New to the group rickman <gnuarm@gmail.com> - 2015-09-29 21:55 -0400
                            Re: New to the group Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-09-30 08:29 +0100
                          Re: New to the group jfong@ms4.hinet.net - 2015-09-29 18:52 -0700
                      Re: New to the group hughaguilar96@gmail.com - 2015-09-29 00:29 -0700
                        Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-29 04:40 -0700
                          Re: New to the group Mark Wills <markwills1970@gmail.com> - 2015-09-29 05:24 -0700
                          Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-29 07:33 -0700
                            Re: New to the group hughaguilar96@gmail.com - 2015-09-29 14:11 -0700
                      Re: New to the group "WJ" <w_a_x_man@yahoo.com> - 2015-09-29 16:46 +0000
                        Re: New to the group hughaguilar96@gmail.com - 2015-09-29 14:15 -0700
                          Re: New to the group rickman <gnuarm@gmail.com> - 2015-09-29 17:34 -0400
                      Re: New to the group "WJ" <w_a_x_man@yahoo.com> - 2015-09-30 00:07 +0000
      Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-27 10:54 -0700
    Re: New to the group Paul Rubin <no.email@nospam.invalid> - 2015-09-26 22:37 -0700
      Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-27 10:51 -0700
    Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-29 17:15 -0700
      Re: New to the group rickman <gnuarm@gmail.com> - 2015-09-29 21:58 -0400
        Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-09-29 22:03 -0700
          Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-09-29 21:32 -1000
            Re: New to the group Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-09-30 09:06 +0100
              Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-09-30 08:58 -1000
                Re: New to the group Mark Wills <markwills1970@gmail.com> - 2015-09-30 23:55 -0700
                  Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-09-30 21:28 -1000
                  Re: New to the group rickman <gnuarm@gmail.com> - 2015-10-01 08:25 -0400
                  Re: New to the group hughaguilar96@gmail.com - 2015-10-01 09:33 -0700
              Re: New to the group hughaguilar96@gmail.com - 2015-09-30 16:21 -0700
                Re: New to the group "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-30 21:03 -0400
                  Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-09-30 19:34 -1000
                    Re: New to the group hughaguilar96@gmail.com - 2015-09-30 23:47 -0700
                      Re: New to the group rickman <gnuarm@gmail.com> - 2015-10-01 08:31 -0400
                        Re: New to the group "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-02 00:30 -0400
                          Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-10-01 19:22 -1000
                            Re: New to the group hughaguilar96@gmail.com - 2015-10-01 23:52 -0700
                          Re: New to the group Mark Wills <markwills1970@gmail.com> - 2015-10-02 01:52 -0700
                            Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-10-02 08:36 -1000
                            Re: New to the group rickman <gnuarm@gmail.com> - 2015-10-02 17:00 -0400
                              Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-10-02 14:46 -0700
                                Re: New to the group rickman <gnuarm@gmail.com> - 2015-10-02 18:10 -0400
                                Re: New to the group Paul Rubin <no.email@nospam.invalid> - 2015-10-02 16:08 -0700
                                  Re: New to the group "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-02 20:44 -0400
                                    Re: New to the group David Thompson <dave.thompson2@verizon.net> - 2015-10-31 06:54 -0400
                                      Re: New to the group "Rod Pemberton" <too@zxcvfeqad.cdm> - 2015-11-02 02:34 -0500
                                        Re: New to the group David Thompson <dave.thompson2@verizon.net> - 2015-12-22 06:45 -0500
                                      Re: New to the group "Rod Pemberton" <too@zxcvfeqad.cdm> - 2015-11-02 02:34 -0500
                                  Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-10-02 15:16 -1000
                                    Re: New to the group Paul Rubin <no.email@nospam.invalid> - 2015-10-02 18:21 -0700
                                      Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-10-02 15:38 -1000
                                    Re: New to the group rickman <gnuarm@gmail.com> - 2015-10-02 22:13 -0400
                                      Re: New to the group Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-10-03 22:24 +0100
                                        Re: New to the group rickman <gnuarm@gmail.com> - 2015-10-03 17:33 -0400
            Re: New to the group hughaguilar96@gmail.com - 2015-09-30 17:00 -0700
              Re: New to the group "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-30 20:38 -0400
              Re: New to the group Walter Banks <walter@bytecraft.com> - 2015-10-02 14:37 -0400
                Re: New to the group rickman <gnuarm@gmail.com> - 2015-10-02 17:01 -0400
                Re: New to the group hughaguilar96@gmail.com - 2015-10-02 23:35 -0700
          Re: New to the group "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-09-30 18:11 -0400
            Re: New to the group Coos Haak <chforth@hccnet.nl> - 2015-10-01 02:13 +0200
      Re: New to the group Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-09-30 08:38 +0100
        Re: New to the group Walter Banks <walter@bytecraft.com> - 2015-09-30 10:58 -0400
    Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-10-01 06:04 -0700
      Re: New to the group rickman <gnuarm@gmail.com> - 2015-10-01 09:46 -0400
      Re: New to the group anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-08 06:07 +0000
        Re: New to the group Alfred Singlestone <vitonis@gmail.com> - 2015-10-09 04:04 -0700
          Re: New to the group rickman <gnuarm@gmail.com> - 2015-10-09 10:29 -0400
          Re: New to the group anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-09 15:30 +0000
    Re: New to the group lehs <skydda.barnen@gmail.com> - 2015-10-03 00:19 -0700
      Re: New to the group visualforth@rocketmail.com - 2015-10-03 17:01 -0700
      Re: New to the group anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-08 06:38 +0000
        Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-10-07 21:15 -1000
          Minimal wordset (was: New to the group) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-08 13:39 +0000
            Re: Minimal wordset (was: New to the group) JUERGEN <epldfpga@aol.com> - 2015-10-08 08:13 -0700
              Re: Minimal wordset (was: New to the group) Mark Wills <markwills1970@gmail.com> - 2015-10-09 00:55 -0700
                Re: Minimal wordset Lars Brinkhoff <lars.spam@nocrew.org> - 2015-10-09 10:43 +0200
                  Re: Minimal wordset Chris Curl <ccurl609@gmail.com> - 2015-10-09 06:56 -0700
                    Re: Minimal wordset Lars Brinkhoff <lars.spam@nocrew.org> - 2015-10-09 19:44 +0200
                      Re: Minimal wordset Paul Rubin <no.email@nospam.invalid> - 2015-10-09 14:02 -0700
                        Re: Minimal wordset Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-10-10 09:44 +0100
                        Re: Minimal wordset anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-10 11:36 +0000
                  Re: Minimal wordset lehs <skydda.barnen@gmail.com> - 2015-10-09 08:40 -0700
                    Re: Minimal wordset Lars Brinkhoff <lars.spam@nocrew.org> - 2015-10-09 19:53 +0200
                      Re: Minimal wordset lehs <skydda.barnen@gmail.com> - 2015-10-09 11:22 -0700
                        Re: Minimal wordset JUERGEN <epldfpga@aol.com> - 2015-10-09 11:33 -0700
                        Re: Minimal wordset Lars Brinkhoff <lars.spam@nocrew.org> - 2015-10-09 20:38 +0200
                        Re: Minimal wordset stephen@mpeforth.com (Stephen Pelc) - 2015-10-09 20:56 +0000
                          Re: Minimal wordset rickman <gnuarm@gmail.com> - 2015-11-01 20:10 -0500
                            Re: Minimal wordset Coos Haak <chforth@hccnet.nl> - 2015-11-02 03:05 +0100
                            Re: Minimal wordset "Elizabeth D. Rather" <erather@forth.com> - 2015-11-01 16:08 -1000
                            Re: Minimal wordset stephen@mpeforth.com (Stephen Pelc) - 2015-11-02 09:35 +0000
                              Re: Minimal wordset anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-02 12:42 +0000
                                Re: Minimal wordset humptydumpty <ouatubi@gmail.com> - 2015-11-08 23:22 -0800
                              Re: Minimal wordset rickman <gnuarm@gmail.com> - 2015-11-03 11:25 -0500
                                Re: Minimal wordset stephen@mpeforth.com (Stephen Pelc) - 2015-11-03 19:36 +0000
                              Re: Minimal wordset "HAA" <someone@microsoft.com> - 2015-11-08 12:56 +1100
                                Re: Minimal wordset stephen@mpeforth.com (Stephen Pelc) - 2015-11-08 16:14 +0000
                                  Re: Minimal wordset "HAA" <someone@microsoft.com> - 2015-11-09 11:55 +1100
                            Re: Minimal wordset anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-02 09:41 +0000
                              Re: Minimal wordset rickman <gnuarm@gmail.com> - 2015-11-03 11:29 -0500
                                Re: Minimal wordset anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-03 17:01 +0000
                  Re: Minimal wordset JUERGEN <epldfpga@aol.com> - 2015-10-09 11:27 -0700
              Re: Minimal wordset (was: New to the group) "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-09 23:11 -0400
                Re: Minimal wordset (was: New to the group) Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-10-10 08:38 +0100
        Re: New to the group dunno <dunno@dunno.dunno> - 2015-10-14 23:14 +0000
          Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-10-14 16:21 -1000
          Re: New to the group anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-15 08:46 +0000
    Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-10-03 09:23 -0700
      Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-10-03 09:19 -1000
    Re: New to the group lehs <skydda.barnen@gmail.com> - 2015-10-08 05:24 -0700
      Re: New to the group "Elizabeth D. Rather" <erather@forth.com> - 2015-10-08 08:22 -1000
        Re: New to the group lehs <skydda.barnen@gmail.com> - 2015-10-09 08:37 -0700
    Re: New to the group Chris Curl <ccurl609@gmail.com> - 2015-10-31 10:44 -0700

Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8  Next page →

#43077 — Re: Minimal wordset

On 11/1/15 3:10 PM, rickman wrote:
> On 10/9/2015 4:56 PM, Stephen Pelc wrote:
>> On Fri, 9 Oct 2015 11:22:01 -0700 (PDT), lehs
>> <skydda.barnen@gmail.com> wrote:
>>
>>> So you can build up i.e. an ANS Forth from these twelve primitives?
>>>
>>> An interesting experiment! If one goes for the other extrem, how
>>> many primitives are *needed* for optimal speed?
>>
>> I don't know what you mean by "optimal speed", but beyond straight
>> subroutine threaded code you need a code generator, not primitives.
>
> I don't recall the specifics, but I recall someone saying they had an
> ITC forth that was faster than an equivalent subroutine threaded forth.
>   Is that realistic?

It really depends on how well it's designed and coded, as well as the 
processor. NEXT (the code that gets from word to the next) can be faster 
than CALL/RET on some processors.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#43089 — Re: Minimal wordset

On Sun, 1 Nov 2015 20:10:46 -0500, rickman <gnuarm@gmail.com> wrote:

>I don't recall the specifics, but I recall someone saying they had an 
>ITC forth that was faster than an equivalent subroutine threaded forth. 
>  Is that realistic?

Some decades ago there were CPUs for which the Forth NEXT sequence
was faster than a RET/CALL instruction pair. However, you need
to include the effect of NEST/UNNEST as well and NEST/UNNEST
kills an ITC Forth compared to CALL/RET in subroutine threaded
Forths.

Whenever we *tested* DTC Forths against raw STC Forths, raw
STC (no optimisations) measures around 2.2 times as fast as
DTC.

Stephen


-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#43113 — Re: Minimal wordset

stephen@mpeforth.com (Stephen Pelc) writes:
>On Sun, 1 Nov 2015 20:10:46 -0500, rickman <gnuarm@gmail.com> wrote:
>
>>I don't recall the specifics, but I recall someone saying they had an 
>>ITC forth that was faster than an equivalent subroutine threaded forth. 
>>  Is that realistic?
>
>Some decades ago there were CPUs for which the Forth NEXT sequence
>was faster than a RET/CALL instruction pair. However, you need
>to include the effect of NEST/UNNEST as well and NEST/UNNEST
>kills an ITC Forth compared to CALL/RET in subroutine threaded
>Forths.

Given that only 24%-32% of the NEXTs are NEST or UNNEST (aka DOCOL and
;S), and they don't take that much time, I have my doubts that they
can kill an ITC Forth.

In particular, if they were really the main performance problem of
ITC, one would expect that a call-heavy benchmark like fib would have
more speedup on native-code Forth systems compared to ITC than other
benchmarks, but it's the other way 'round.  E.g., from the data for
<https://www.complang.tuwien.ac.at/forth/performance.html>:

Speedups of various native-code Forth systems over Gforth 0.4.9 (ITC)
on a 486-66:

 big-               NTForth        
Forth iForth mxForth   NCC         
 1.97   1.71   1.60  2.90   sieve  
 2.15   2.17   2.29  0.71   bubble 
 1.70   2.35   2.23  1.24   matmul 
 2.09   2.17   3.01  1.94   fib    

So, these systems do not excell on the fib benchmark (except mxForth).

>Whenever we *tested* DTC Forths against raw STC Forths, raw
>STC (no optimisations) measures around 2.2 times as fast as
>DTC.

Some more data: For the 486, see above.  But none of these are "raw
STC", they all inline many primitives and most (maybe all) do
additional optimizations (e.g., bigForth contains a peephole optimizer
that eliminates some inefficiencies between primitives); indeed, I
would not know where to find a "raw STC" system.  It seems that
everybody who does STC enhances it with inlining and maybe more.

Since the 486, we have had some interesting hardware developments:
Mixing code and data has become slow (and still is), CPUs started
predicting conditional branches and returns (aka return stack), and
(to a lesser degree), indirect branches; indirect branch prediction
progressed from BTBs (about 50% mispredictions with ITC) to what
Haswell has (nearly perfect indirect branch prediction for small
programs, and still good for big programs).

We see a result of this in Figure 10 of
<http://www.complang.tuwien.ac.at/papers/ertl%26gregg04pact.ps.gz>:
The Athlon (Thunderbird) uses a return stack and a BTB, and the
speedup of native code over threaded code (gforth-plain) can be quite
high: maximum factor 5.2 for matrix, median 2.7.  One native-code
compiler (bigForth) is slower by a factor of 3 on the CD16sim
benchmark because it mixes code with data.

These days, with the good indirect branch prediction in Haswell, ITC
is coming closer to more native-code oriented implementations: Here
are benchmark results on Haswell (Core i7-4790K):

 sieve bubble matrix   fib   fft
 0.104  0.152  0.092 0.156 0.052 gforth-fast --no-dynamic
 0.088  0.120  0.044 0.088 0.036 gforth-fast --dynamic
 0.088  0.120  0.052 0.088 0.036 gforth-fast --ss-number=0 --ss-states=0
 0.152  0.264  0.100 0.164 0.068 gforth --dynamic
 0.164  0.260  0.104 0.216 0.068 gforth --no-dynamic
 0.184  0.280  0.112 0.252 0.076 gforth-itc onebench.fs

This is a progression of optimizations; from bottom to top:

gforth-itc is indirect threaded code (and it stores IP to memory after
every primitive and keeps RP in memory in order to be able to produce
backtraces for debugging).

gforth --no-dynamic is direct threaded code with the same debugging
features.

gforth --dynamic forms dynamic superinstructions, the threaded-code
equivalent of the inlining that is usually done for STC.  This used to
be a huge win on CPUs with BTBs, but on Haswell it no longer is, at
least for small benchmarks.

gforth-fast --ss-number=0 --ss-states=0 keeps the TOS and RP in 
registers, and does not store IP to memory.

gforth-fast --dynamic combines some primitives into superinstructions
and keeps the TOS only in a register when it is beneficial (e.g., not
between "! 5").

gforth-fast --no-dynamic steps back to direct threaded code, in order
to see the difference between threaded and native code without the
overhead of the debugging stuff.  This is best compared to
"gforth-fast --ss-number=0 --ss-states=0", because the additional
optimiztions of "gforth-fast --dynamic" cannot be used with
--no-dynamic.

As can be seen, the step from threaded to native code is not as big as
it used to be in the Athlon days (only a factor 1.77 instead of 5.2
for matrix, less for others).  Maybe a "raw STC" system is faster on
the Haswell than "gforth-fast --ss-number=0 --ss-states=0", but I
doubt it.

I just did some microbenchmarking on an Intel Haswell and an ARM
Cortex-A9, and got the following results (for older results, see
<https://www.complang.tuwien.ac.at/forth/threading/>):

The results are cycles per NEXT:

sub-		in-	                repl.
routine	direct	direct	switch	call   switch CPU, Machine, gcc
 4.0     2.3     2.3     4.0     5.1     3.5  Core i7-4790K 4000MHz
13.6     8.9    11.0    22.0    24.5    11.8  Cortex A9 1.2GHz, OMAP 4430

So, at least for this benchmark and these CPUs, indirect threading is
faster than subroutine threading; however, this is a microbenchmark,
and may expose some issues that do not occur in real applications
(e.g., the Athlon subroutine threading results became faster after
inserting nops).

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

[toc] | [prev] | [next] | [standalone]

#43408 — Re: Minimal wordset

On Monday, November 2, 2015 at 4:38:24 PM UTC+2, Anton Ertl wrote:
> (Stephen Pelc) writes:
> >On Sun, 1 Nov 2015 20:10:46 -0500, rickman <> wrote:
> >
> >>I don't recall the specifics, but I recall someone saying they had an 
> >>ITC forth that was faster than an equivalent subroutine threaded forth. 
> >>  Is that realistic?
> >
> >Some decades ago there were CPUs for which the Forth NEXT sequence
> >was faster than a RET/CALL instruction pair. However, you need
> >to include the effect of NEST/UNNEST as well and NEST/UNNEST
> >kills an ITC Forth compared to CALL/RET in subroutine threaded
> >Forths.
> 
> Given that only 24%-32% of the NEXTs are NEST or UNNEST (aka DOCOL and
> ;S), and they don't take that much time, I have my doubts that they
> can kill an ITC Forth.
> 
> In particular, if they were really the main performance problem of
> ITC, one would expect that a call-heavy benchmark like fib would have
> more speedup on native-code Forth systems compared to ITC than other
> benchmarks, but it's the other way 'round.  E.g., from the data for
> <https://www.complang.tuwien.ac.at/forth/performance.html>:
> 
> Speedups of various native-code Forth systems over Gforth 0.4.9 (ITC)
> on a 486-66:
> 
>  big-               NTForth        
> Forth iForth mxForth   NCC         
>  1.97   1.71   1.60  2.90   sieve  
>  2.15   2.17   2.29  0.71   bubble 
>  1.70   2.35   2.23  1.24   matmul 
>  2.09   2.17   3.01  1.94   fib    
> 
> So, these systems do not excell on the fib benchmark (except mxForth).
> 
> >Whenever we *tested* DTC Forths against raw STC Forths, raw
> >STC (no optimisations) measures around 2.2 times as fast as
> >DTC.
> 
> Some more data: For the 486, see above.  But none of these are "raw
> STC", they all inline many primitives and most (maybe all) do
> additional optimizations (e.g., bigForth contains a peephole optimizer
> that eliminates some inefficiencies between primitives); indeed, I
> would not know where to find a "raw STC" system.  It seems that
> everybody who does STC enhances it with inlining and maybe more.
> 
> Since the 486, we have had some interesting hardware developments:
> Mixing code and data has become slow (and still is), CPUs started
> predicting conditional branches and returns (aka return stack), and
> (to a lesser degree), indirect branches; indirect branch prediction
> progressed from BTBs (about 50% mispredictions with ITC) to what
> Haswell has (nearly perfect indirect branch prediction for small
> programs, and still good for big programs).
> 
> We see a result of this in Figure 10 of
> <http://www.complang.tuwien.ac.at/papers/ertl%26gregg04pact.ps.gz>:
> The Athlon (Thunderbird) uses a return stack and a BTB, and the
> speedup of native code over threaded code (gforth-plain) can be quite
> high: maximum factor 5.2 for matrix, median 2.7.  One native-code
> compiler (bigForth) is slower by a factor of 3 on the CD16sim
> benchmark because it mixes code with data.
> 
> These days, with the good indirect branch prediction in Haswell, ITC
> is coming closer to more native-code oriented implementations: Here
> are benchmark results on Haswell (Core i7-4790K):
> 
>  sieve bubble matrix   fib   fft
>  0.104  0.152  0.092 0.156 0.052 gforth-fast --no-dynamic
>  0.088  0.120  0.044 0.088 0.036 gforth-fast --dynamic
>  0.088  0.120  0.052 0.088 0.036 gforth-fast --ss-number=0 --ss-states=0
>  0.152  0.264  0.100 0.164 0.068 gforth --dynamic
>  0.164  0.260  0.104 0.216 0.068 gforth --no-dynamic
>  0.184  0.280  0.112 0.252 0.076 gforth-itc onebench.fs
> 
> This is a progression of optimizations; from bottom to top:
> 
> gforth-itc is indirect threaded code (and it stores IP to memory after
> every primitive and keeps RP in memory in order to be able to produce
> backtraces for debugging).
> 
> gforth --no-dynamic is direct threaded code with the same debugging
> features.
> 
> gforth --dynamic forms dynamic superinstructions, the threaded-code
> equivalent of the inlining that is usually done for STC.  This used to
> be a huge win on CPUs with BTBs, but on Haswell it no longer is, at
> least for small benchmarks.
> 
> gforth-fast --ss-number=0 --ss-states=0 keeps the TOS and RP in 
> registers, and does not store IP to memory.
> 
> gforth-fast --dynamic combines some primitives into superinstructions
> and keeps the TOS only in a register when it is beneficial (e.g., not
> between "! 5").
> 
> gforth-fast --no-dynamic steps back to direct threaded code, in order
> to see the difference between threaded and native code without the
> overhead of the debugging stuff.  This is best compared to
> "gforth-fast --ss-number=0 --ss-states=0", because the additional
> optimiztions of "gforth-fast --dynamic" cannot be used with
> --no-dynamic.
> 
> As can be seen, the step from threaded to native code is not as big as
> it used to be in the Athlon days (only a factor 1.77 instead of 5.2
> for matrix, less for others).  Maybe a "raw STC" system is faster on
> the Haswell than "gforth-fast --ss-number=0 --ss-states=0", but I
> doubt it.
> 
> I just did some microbenchmarking on an Intel Haswell and an ARM
> Cortex-A9, and got the following results (for older results, see
> <https://www.complang.tuwien.ac.at/forth/threading/>):
> 
> The results are cycles per NEXT:
> 
> sub-		in-	                repl.
> routine	direct	direct	switch	call   switch CPU, Machine, gcc
>  4.0     2.3     2.3     4.0     5.1     3.5  Core i7-4790K 4000MHz
> 13.6     8.9    11.0    22.0    24.5    11.8  Cortex A9 1.2GHz, OMAP 4430
> 
> So, at least for this benchmark and these CPUs, indirect threading is
> faster than subroutine threading; however, this is a microbenchmark,
> and may expose some issues that do not occur in real applications
> (e.g., the Athlon subroutine threading results became faster after
> inserting nops).
> 
> - anton
> -- 
> M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
> comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
>      New standard: http://www.forth200x.org/forth200x.html
>    EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

Hi!
Some time ago I found that compiling with -Os and not with -O2
 give some more speed to gforth-itc.

Have a nice day,
humptydumpty

[toc] | [prev] | [next] | [standalone]

#43179 — Re: Minimal wordset

On 11/2/2015 4:35 AM, Stephen Pelc wrote:
> On Sun, 1 Nov 2015 20:10:46 -0500, rickman <gnuarm@gmail.com> wrote:
>
>> I don't recall the specifics, but I recall someone saying they had an
>> ITC forth that was faster than an equivalent subroutine threaded forth.
>>   Is that realistic?
>
> Some decades ago there were CPUs for which the Forth NEXT sequence
> was faster than a RET/CALL instruction pair. However, you need
> to include the effect of NEST/UNNEST as well and NEST/UNNEST
> kills an ITC Forth compared to CALL/RET in subroutine threaded
> Forths.
>
> Whenever we *tested* DTC Forths against raw STC Forths, raw
> STC (no optimisations) measures around 2.2 times as fast as
> DTC.

Sorry, the way this is worded, I can't tell which is faster.  So STC is 
faster than DTC by a factor of 2.2 by your measurements?

I believe in some complex processors a subroutine CALL can do stack ops 
which slow it down.  Many processors allow the user to manage the stack 
ops and a CALL is just one instruction cycle.  I guess on more complex 
processors the CALL can be rather slow compared to a small number of 
instructions that can all operate in parallel.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#43191 — Re: Minimal wordset

On Tue, 3 Nov 2015 11:25:01 -0500, rickman <gnuarm@gmail.com> wrote:

>Sorry, the way this is worded, I can't tell which is faster.  So STC is 
>faster than DTC by a factor of 2.2 by your measurements?

Yes, STC is faster than DTC by a factor about 2.2 for a small range
of embedded CPUs tested in the mid 1990s. No caches, no BTBs or other
desktop-isms.

I remember 68000 and 8051 being among the candidates, and I would
expect that we also tested H8300H, 80186, 80196 and Z180, but
the results are lost on an archive tape somewhere.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#43339 — Re: Minimal wordset

Stephen Pelc wrote:
> On Sun, 1 Nov 2015 20:10:46 -0500, rickman <gnuarm@gmail.com> wrote:
>
> >I don't recall the specifics, but I recall someone saying they had an
> >ITC forth that was faster than an equivalent subroutine threaded forth.
> >  Is that realistic?
>
> Some decades ago there were CPUs for which the Forth NEXT sequence
> was faster than a RET/CALL instruction pair. However, you need
> to include the effect of NEST/UNNEST as well and NEST/UNNEST
> kills an ITC Forth compared to CALL/RET in subroutine threaded
> Forths.
>
> Whenever we *tested* DTC Forths against raw STC Forths, raw
> STC (no optimisations) measures around 2.2 times as fast as
> DTC.
>
> Stephen

And on 16-bit systems as much as 50% larger since each CALL
was 3 bytes compared with 2 for DTC.

[toc] | [prev] | [next] | [standalone]

#43368 — Re: Minimal wordset

On Sun, 8 Nov 2015 12:56:46 +1100, "HAA" <someone@microsoft.com>
wrote:

>And on 16-bit systems as much as 50% larger since each CALL
>was 3 bytes compared with 2 for DTC.

The header is shorter for STC systems (0 vs 3 bytes), and the EXIT is
shorter, usually 1 byte vs 2. The size difference is extremely
dependent on coding style.

One one puts in the obvious and simple optimisations, let's call it
STC+, STC+ is very little larger than DTC for 16 bit systems.

We never did an STC+ system for 32 bit targets, always preferring
to do a full native code compiler (NCC). A 256 kb NCC app on a
68xxx CPU was 1% smaller than the DTC version of the same app.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#43397 — Re: Minimal wordset

Stephen Pelc wrote:
> On Sun, 8 Nov 2015 12:56:46 +1100, "HAA" <someone@microsoft.com>
> wrote:
>
> >And on 16-bit systems as much as 50% larger since each CALL
> >was 3 bytes compared with 2 for DTC.
>
> The header is shorter for STC systems (0 vs 3 bytes), and the EXIT is
> shorter, usually 1 byte vs 2. The size difference is extremely
> dependent on coding style.

The 50% figure came from an early 80's 16-bit commercial forth - the
first release being DTC or ITC and the second a non-optimized STC.

> One one puts in the obvious and simple optimisations, let's call it
> STC+, STC+ is very little larger than DTC for 16 bit systems.

For a cross-compiler such optimizations are practical.  Where the
host is the target and memory is limited to 64K it depends on whether
the code reduction obtained is enough to offset the larger compiler.

> We never did an STC+ system for 32 bit targets, always preferring
> to do a full native code compiler (NCC). A 256 kb NCC app on a
> 68xxx CPU was 1% smaller than the DTC version of the same app.
>
> Stephen

For 32-bit systems memory is rarely an issue, so it boils down to the
complexities of STC and native code.  Historically there have been
more free DTC/ITC sources and porting is relatively easy.

[toc] | [prev] | [next] | [standalone]

#43092 — Re: Minimal wordset

rickman <gnuarm@gmail.com> writes:
>I don't recall the specifics, but I recall someone saying they had an 
>ITC forth that was faster than an equivalent subroutine threaded forth. 
>  Is that realistic?

On CPUs without branch prediction, yes.  Subroutine-threaded code has
two branches per primitive, indirect threaded code only one.  You find
a number of CPUs where indirect threading is faster than subroutine
threading on the first version of my threaded-code microbenchmark
<https://www.complang.tuwien.ac.at/forth/threading-v1/>.  On more
modern CPUs this is rare, though, because they tend to predict direct
branches and returns better than indirect branches.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

[toc] | [prev] | [next] | [standalone]

#43180 — Re: Minimal wordset

On 11/2/2015 4:41 AM, Anton Ertl wrote:
> rickman <gnuarm@gmail.com> writes:
>> I don't recall the specifics, but I recall someone saying they had an
>> ITC forth that was faster than an equivalent subroutine threaded forth.
>>   Is that realistic?
>
> On CPUs without branch prediction, yes.  Subroutine-threaded code has
> two branches per primitive, indirect threaded code only one.

By two branches you mean the CALL and the RET?


> You find
> a number of CPUs where indirect threading is faster than subroutine
> threading on the first version of my threaded-code microbenchmark
> <https://www.complang.tuwien.ac.at/forth/threading-v1/>.  On more
> modern CPUs this is rare, though, because they tend to predict direct
> branches and returns better than indirect branches.

I usually am concerned with smaller, embedded CPUs, like ARMs and 
TMS430s.  I believe on both of these subroutine threading can be very 
fast.  On my custom stack CPU the CALL and RET were one cycle each and 
in some versions of the instruction set the RET could be paralleled with 
the main instruction if it didn't use the address stack.  Of course that 
has little to do with the rest of the world.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#43181 — Re: Minimal wordset

rickman <gnuarm@gmail.com> writes:
>On 11/2/2015 4:41 AM, Anton Ertl wrote:
>> rickman <gnuarm@gmail.com> writes:
>>> I don't recall the specifics, but I recall someone saying they had an
>>> ITC forth that was faster than an equivalent subroutine threaded forth.
>>>   Is that realistic?
>>
>> On CPUs without branch prediction, yes.  Subroutine-threaded code has
>> two branches per primitive, indirect threaded code only one.
>
>By two branches you mean the CALL and the RET?

Yes.

>I usually am concerned with smaller, embedded CPUs, like ARMs and 
>TMS430s.  I believe on both of these subroutine threading can be very 
>fast.

Don't believe!  Measure!

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

[toc] | [prev] | [next] | [standalone]

#42518 — Re: Minimal wordset

On Friday, October 9, 2015 at 9:43:51 AM UTC+1, Lars Brinkhoff wrote:
> Mark Wills <markwills1970@gmail.com> writes:
> > Ting spent years working on minimal Forths. I think he got the number
> > of primitives down to 16 or so.
> 
> Various sources on the net claim eForth version 1 has 30 or 31
> primitives.  Don't know about version 2.
> 
> My toy Forth has 12, but further reductions are possible.

Copied out of the file that comes with the code you buy for $25 from Offete:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

4.1  Forth Virtual Machine 

In the original eForth Model, Bill Muench identified 31 primitive commands in the kernel.  These commands were coded in machine instructions of the host microprocessor.  They allow the underlying microcontroller to become a Forth Virtual Machine.  All other commands were written as compound commands, containing lists of tokens which specify execution behavior of commands.  Compound commands are token lists of primitive commands and other compound commands.  This division of primitive and compound commands was very useful in porting eForth to many different microprocessors, because only primitive commands needed to be rewritten when moving eForth to a new microcontroller.

In 430eForth v4.3, I retained this division.  However, I tried optimize as many compound commands as possible, so that the system executes at the highest speed and occupies the least memory space.  All commands that can be optimized are re-coded in assembly. 

MSP430G2 is a 16-bit CPU with 16 16-bit registers.  The CPU registers R4-R6 are assigned specific functions required in a Forth Virtual Machine as follows:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

I reformatted the last version I bought from Ting and now have a nicely bound book in A5 and 218 pages. Very recommendable.

[toc] | [prev] | [next] | [standalone]

#42536 — Re: Minimal wordset (was: New to the group)

On Thu, 08 Oct 2015 11:13:12 -0400, JUERGEN <epldfpga@aol.com> wrote:

> If you factor out the existing word set to the max
> - the result should be a minimum list by definition.

Forths that build up from "primitives" usually need at least 35 for
a Forth which isn't abhorrently slow.  Some have gone as low as 9,
but this wasn't ANS or a complete Forth wordset.  These are usually
ITC Forths created after C.H. Ting and Bill E. Meunch popularized
this build-up idea with eForth.

> When I discussed this minimum wordset with others it was to find
> out about the possibilities of different levels for hardware conversion:

You can make an AND using NANDs, but if the hardware has
direct support for AND, then you'll AND for AND.  It's the
the lowest, supported functionality, i.e., the "primitive".
You can still reduce the wordset buy implementing NAND and
eliminating AND, but then you're doing extra work to get
AND from NAND, i.e., slower.

> Core set in assembler bow   - and conversion to VHDL
> [...]
> I am still not sure why nobody in the Forth community has
> tackled this.
> [...]
> Forth could compile to VHDL ( or Verilog ) / Gates directly.
> [...]
> This was my interest in the minimum wordset.
> Nothing to do with Forth as such.

Hasn't a basic minimum wordset which would work with VHDL already
been found by Charles Moore for his various microprocessors?

He has implemented Forth directly as the instruction set for
various microprocessors.  I would think that you'd start by
looking at his designs.  Whatever is present for most of them
is likely to be what you need.  You're probably going to find
some basic microprocessor functionality, some basic Forth words,
and maybe a few other things.

Forth processor instruction sets:

http://www.ultratechnology.com/mup21.html
http://www.ultratechnology.com/f21cpu.html#cpu
http://www.colorforth.com/inst.htm
http://users.ece.cmu.edu/~koopman/stack_computers/sec4_3.html
http://users.ece.cmu.edu/~koopman/stack_computers/sec4_4.html
http://users.ece.cmu.edu/~koopman/stack_computers/sec4_5.html
http://users.ece.cmu.edu/~koopman/stack_computers/sec5_3.html

These are Forth VHDL related:

http://www.ultratechnology.com/p16vhdl.htm
http://www.ultratechnology.com/4thvhdl.htm
http://web.archive.org/web/20041012145634/http://www.cse.cuhk.edu.hk/~phwl/msl16/msl16.html
  (last is one link)

You can find more links here:
http://www.ultratechnology.com/chips.htm

If the link is bad, try Wayback archive:
https://archive.org/web/


Rod Pemberton

-- 
Just how many texting and calendar apps does humanity need?
Just how many food articles from neurotic millenials do we need?

[toc] | [prev] | [next] | [standalone]

#42542 — Re: Minimal wordset (was: New to the group)

On Fri, 09 Oct 2015 23:11:42 -0400
"Rod Pemberton" <boo@fasdfrewar.cdm> wrote:

> You can make an AND using NANDs, but if the hardware has
> direct support for AND, then you'll AND for AND.  It's the
> the lowest, supported functionality, i.e., the "primitive".
> You can still reduce the wordset buy implementing NAND and
> eliminating AND, but then you're doing extra work to get
> AND from NAND, i.e., slower.

Agreed. Also, on a regular micro I would not call this reducing
of the word list "factoring" because:

1) Once you have AND working, you can copy&paste,and change one
instruction to get OR XOR and +,  so there is almost no design
effort or aditional testing required. 

2) Defining AND and others in terms of NAND
increases complexity, hence the resulting speed reduction.


> Hasn't a basic minimum wordset which would work with VHDL
> already been found by Charles Moore for his various
> microprocessors?

Yes, Chuck's F18A has just  NEGATE  +  AND  XOR [1], but because
he is designing hardware there are real benefits. By not
implementing OR and NEGATE the chip is simpler, transistor count
is reduced, and the opcode size is kept small, just 5 bits.

Interestingly, if Chuck's design tools were anything like VHDL
then he could also cut&paste to get the 'missing' instructions,
but unlike a processor hosted Forth, this would still increase
size and complexity.

@Rod, Thanks for the links, will have another good read
sometime. 

Jan Coombs
-- 
email valid, else fix dots and hyphen
jan4clf2014@murrayhyphenmicroftdotcodotuk

[1] F18A Technology Reference, GreenArrays, Inc  
Terminology note: In this manual XOR is called 'or', and
NEGATE is called "-" 
"Standards - everybody should have one" CM(?)

[toc] | [prev] | [next] | [standalone]

#42642

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> lehs <skydda.barnen@gmail.com> writes:
>> For example the idea that a forth st=
>> andard should be a minimal kernel without structures and all the other thin=
>> gs that easily can be added in each system. Then there might be a standard =
>> that doesn't change from year to year.
> 
> 1979 1983 1994 2012
> 
> The standard updates are not that frequent.  Structures were only
> added in the 2012 standard, but it does not seem that we are going to
> update the standard every year now. Indeed there was a suggestion that
> we should do more frequent updates at the standards meeting last year,
> but there were strong voices against this.
> 
> Concerning the idea of a minimal system and that all users then add
> their own structures and other things that can be added easily: That's
> an idea that comes up regularly (e.g., at this year's EuroForth), and
> there have been at least two occasions when people wanted to start a
> standard based on that idea.  So it is certainly an attractive idea.
> 
> But apparently not attractive enough to actually lead to any concrete
> outcome.  This year we at least got a list of words that were to be in
> the minimal set in the opinion of its author, and we played around
> with it (defined a number of them in terms of an even smaller set).
> 
> I think one problem here is that there are different concepts of
> minimalism, and this includes the effort of this year's EuroForth: It
> was intended to be a small set of words for education purposes, but
> there was also the idea of implementation minimalism (don't provide
> what you can easily define from the other provided words) in it.
> 
> Myself, I really don't want to define structures in every program, and
> I don't want to read through other people's structures definitions
> (and note the differences between them) every time I look at a
> program, and I also much prefer if people use field names instead of,
> e.g., CELL+ or nothing, which they often do if no structures are
> present.
> 
> - anton

It seems for me that standard should consists of two parts: language
standard, which describes low-level words, and standard set of libraries,
which describes high-level words and which are written using language
standard. Set of libraries in the best case would accompany the language
standard and be included in all standard-complying Forths.

Structures definitions, in my opinion, should belong to set of libraries.

-- 
dunno

[toc] | [prev] | [next] | [standalone]

#42643

On 10/14/15 1:14 PM, dunno wrote:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> lehs <skydda.barnen@gmail.com> writes:
>>> For example the idea that a forth st=
>>> andard should be a minimal kernel without structures and all the other thin=
>>> gs that easily can be added in each system. Then there might be a standard =
>>> that doesn't change from year to year.
>>
>> 1979 1983 1994 2012
>>
>> The standard updates are not that frequent.  Structures were only
>> added in the 2012 standard, but it does not seem that we are going to
>> update the standard every year now. Indeed there was a suggestion that
>> we should do more frequent updates at the standards meeting last year,
>> but there were strong voices against this.
>>
>> Concerning the idea of a minimal system and that all users then add
>> their own structures and other things that can be added easily: That's
>> an idea that comes up regularly (e.g., at this year's EuroForth), and
>> there have been at least two occasions when people wanted to start a
>> standard based on that idea.  So it is certainly an attractive idea.
>>
>> But apparently not attractive enough to actually lead to any concrete
>> outcome.  This year we at least got a list of words that were to be in
>> the minimal set in the opinion of its author, and we played around
>> with it (defined a number of them in terms of an even smaller set).
>>
>> I think one problem here is that there are different concepts of
>> minimalism, and this includes the effort of this year's EuroForth: It
>> was intended to be a small set of words for education purposes, but
>> there was also the idea of implementation minimalism (don't provide
>> what you can easily define from the other provided words) in it.
>>
>> Myself, I really don't want to define structures in every program, and
>> I don't want to read through other people's structures definitions
>> (and note the differences between them) every time I look at a
>> program, and I also much prefer if people use field names instead of,
>> e.g., CELL+ or nothing, which they often do if no structures are
>> present.
>>
>> - anton
>
> It seems for me that standard should consists of two parts: language
> standard, which describes low-level words, and standard set of libraries,
> which describes high-level words and which are written using language
> standard. Set of libraries in the best case would accompany the language
> standard and be included in all standard-complying Forths.
>
> Structures definitions, in my opinion, should belong to set of libraries.
>

That is sort of what the "core plus optional wordsets" tries to 
accomplish, but, as Anton says, there are widely differing opinions as 
to what the core or low-level words should be. Few of us feel that all 
the wordsets should be required (vs. optional) as many of them are only 
relevant in certain situations. For example, Forth is heavily used in 
embedded systems, and the Files wordset is almost never relevant there, 
although it's essential in Forths running in OS-hosted environments. I 
rarely use C-type structs, and it's a matter of tiny moments to add that 
capability when I encounter a situation in which I want them.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#42644

dunno <dunno@dunno.dunno> writes:
>It seems for me that standard should consists of two parts: language
>standard, which describes low-level words, and standard set of libraries,
>which describes high-level words and which are written using language
>standard. Set of libraries in the best case would accompany the language
>standard and be included in all standard-complying Forths.

You mean that the "set of libraries" consists of Forth source code
that has been blessed as "standard library" and that is already
included when you start a standard-complying Forth system.  Somewhat
like the fig-Forth standard.

There have been some discussions about standard libraries, and it has
been unclear to me what the advantage over other libraries would be.
If they were already included on startup, an advantage would be that a
standard program can really use them, while currently it cannot even
use the standard floating-point wordset on some standard systems that
have such a wordset, because there is no standard way to tell the
system to please load the floating-point words now (actually, there is
one, through ENVIRONMENT?, but these systems don't implement
ENVIRONMENT? in this way).

Given that there is no consensus on how to include libraries, and many
systems probably don't want to include all the standard libraries
already on startup, I see little point in standardizing a library.

>Structures definitions, in my opinion, should belong to set of libraries.

For the most part, yes.  However, in the standard we can only define
fields as children of a word like

: (field) create , does> @ + ;

or 

: (field) >r : r> postpoine literal postpone + postpone ; ;

On many systems, this is better implemented using something like
;CODE, and that's not portable.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

[toc] | [prev] | [next] | [standalone]

#42337

: smooth.ruffled.feathers ." Yes, it was loony. Believe it or not, 
  that was how I interpreted what you wrote. If you can't see how I 
  could have possibly interpreted those words the way I did, 
  then I'm sorry. " ;

: i.am.not.a.troll ." Even though it may seem that way at times, 
  I promise that I am not trolling this group." ;

: restate.thread.topic ." For the record, it was not my 
  intention to reopen a topic that people are clearly very 
  passionate about and has been hotly debated in the past. 
  I was just saying, 'hi' and introducing my self to the group." ;

: reset.thread 
  smooth.ruffled.feathers 
  i.am.not.a.troll 
  restate.thread.topic ;

: go.do.other.stuff ( this word is implementation defined and its 
  behavior is ambiguous ) ;

: check.back.later ( this word is implementation defined and its 
  behavior is ambiguous ) ;

reset.thread go.do.other.stuff check.back.later 

[toc] | [prev] | [next] | [standalone]

#42339

On 10/3/15 6:23 AM, Chris Curl wrote:
> : smooth.ruffled.feathers ." Yes, it was loony. Believe it or not,
>    that was how I interpreted what you wrote. If you can't see how I
>    could have possibly interpreted those words the way I did,
>    then I'm sorry. " ;
>
> : i.am.not.a.troll ." Even though it may seem that way at times,
>    I promise that I am not trolling this group." ;
>
> : restate.thread.topic ." For the record, it was not my
>    intention to reopen a topic that people are clearly very
>    passionate about and has been hotly debated in the past.
>    I was just saying, 'hi' and introducing my self to the group." ;
>
> : reset.thread
>    smooth.ruffled.feathers
>    i.am.not.a.troll
>    restate.thread.topic ;
>
> : go.do.other.stuff ( this word is implementation defined and its
>    behavior is ambiguous ) ;
>
> : check.back.later ( this word is implementation defined and its
>    behavior is ambiguous ) ;
>
> reset.thread go.do.other.stuff check.back.later
>

Welcome to comp.lang.forth! :-)

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8  Next page →

Back to top | Article view | comp.lang.forth

csiph-web