Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #38115 > unrolled thread
| Started by | lehs <skydda.barnen@gmail.com> |
|---|---|
| First post | 2015-04-11 01:16 -0700 |
| Last post | 2015-04-30 02:35 -0700 |
| Articles | 20 on this page of 169 — 23 participants |
Back to article view | Back to comp.lang.forth
How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-11 01:16 -0700
Re: How efficient are locals? How portable? stephen@mpeforth.com (Stephen Pelc) - 2015-04-11 15:56 +0000
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-11 15:48 -0700
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-11 17:43 -0700
Re: How efficient are locals? How portable? "HAA" <someone@microsoft.com> - 2015-04-14 18:40 +1000
Re: How efficient are locals? How portable? empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> - 2015-04-22 19:23 +0000
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-22 13:28 -0700
Re: How efficient are locals? How portable? empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> - 2015-04-22 22:29 +0000
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-22 16:01 -0700
Re: How efficient are locals? How portable? empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> - 2015-04-22 23:20 +0000
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-23 00:28 -0700
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-23 02:30 -0700
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-23 09:57 +0000
Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-23 11:28 +0000
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-23 09:31 -0400
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-23 13:32 +0000
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-23 10:56 -0700
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-23 11:12 -0700
Re: How efficient are locals? How portable? Coos Haak <chforth@hccnet.nl> - 2015-04-23 22:44 +0200
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-23 23:24 -0700
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-24 09:21 +0000
Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-24 11:44 +0000
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-24 08:35 -0700
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-24 15:40 +0000
Re: How efficient are locals? How portable? mhx@iae.nl - 2015-04-24 10:28 -0700
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-24 17:43 +0000
Re: How efficient are locals? How portable? mhx@iae.nl - 2015-04-24 22:44 -0700
Re: How efficient are locals? How portable? empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> - 2015-04-24 15:00 +0000
Re: How efficient are locals? How portable? Paul Rubin <no.email@nospam.invalid> - 2015-04-24 09:07 -0700
Re: How efficient are locals? How portable? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-04-23 07:30 -0700
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-23 11:02 -0400
Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-23 16:30 +0100
Re: How efficient are locals? How portable? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-04-23 09:38 -0700
Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-24 15:57 +0100
Re: How efficient are locals? How portable? empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> - 2015-04-24 15:14 +0000
Re: How efficient are locals? How portable? rickman <gnuarm@gmail.com> - 2015-04-23 06:58 -0400
Re: How efficient are locals? How portable? Coos Haak <chforth@hccnet.nl> - 2015-04-23 14:47 +0200
Re: How efficient are locals? How portable? "Elizabeth D. Rather" <erather@forth.com> - 2015-04-23 08:34 -1000
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-13 12:32 +0000
Re: How efficient are locals? How portable? rickman <gnuarm@gmail.com> - 2015-04-13 21:57 -0400
Re: How efficient are locals? How portable? Paul Rubin <no.email@nospam.invalid> - 2015-04-13 19:25 -0700
Re: How efficient are locals? How portable? Mark Wills <markwills1970@gmail.com> - 2015-04-14 01:43 -0700
Re: How efficient are locals? How portable? Mark Wills <markwills1970@gmail.com> - 2015-04-14 01:45 -0700
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-14 10:12 -0700
Re: How efficient are locals? How portable? Mark Wills <markwills1970@gmail.com> - 2015-04-14 13:09 -0700
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-15 14:18 -0700
Re: How efficient are locals? How portable? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-04-15 22:13 -0700
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-15 23:14 -0700
Re: How efficient are locals? How portable? Mark Wills <markwills1970@gmail.com> - 2015-04-16 01:12 -0700
Re: How efficient are locals? How portable? Mark Wills <markwills1970@gmail.com> - 2015-04-16 01:23 -0700
Re: How efficient are locals? How portable? rickman <gnuarm@gmail.com> - 2015-04-16 14:28 -0400
Re: How efficient are locals? How portable? rickman <gnuarm@gmail.com> - 2015-04-16 14:37 -0400
Re: How efficient are locals? How portable? Mark Wills <markwills1970@gmail.com> - 2015-04-17 04:43 -0700
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-14 14:53 +0000
Re: How efficient are locals? How portable? Julian Fondren <julian.fondren@gmail.com> - 2015-04-16 00:34 -0700
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-16 00:54 -0700
Re: How efficient are locals? How portable? Julian Fondren <julian.fondren@gmail.com> - 2015-04-16 01:07 -0700
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-16 12:22 +0000
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-16 08:32 -0700
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-16 20:42 -0700
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-17 00:14 -0400
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-16 22:14 -0700
Re: How efficient are locals? How portable? Bernd Linsel <bl1@gmx.com> - 2015-04-17 17:43 +0200
Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-17 20:46 +0000
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-18 06:54 +0000
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-18 06:52 -0400
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-18 22:14 -0700
Re: How efficient are locals? How portable? "WJ" <w_a_x_man@yahoo.com> - 2015-04-19 08:46 +0000
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-19 06:04 -0400
Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-19 10:12 +0000
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-19 10:43 -0700
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-19 16:28 -0400
Re: How efficient are locals? How portable? franck.bensusan@gmail.com - 2015-04-19 15:35 -0700
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-19 19:14 -0400
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-19 16:48 -0700
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-20 09:51 +0000
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-20 06:27 -0400
Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-20 13:04 +0000
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-20 14:09 +0000
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-21 07:17 -0400
Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-21 16:50 +0000
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-21 16:35 -0400
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-22 06:13 -0400
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-22 06:23 -0400
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-21 17:18 +0000
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-21 16:38 -0400
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-22 10:12 +0000
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-22 06:26 -0400
Re: How efficient are locals? How portable? "Elizabeth D. Rather" <erather@forth.com> - 2015-04-20 08:46 -1000
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-20 23:02 -0700
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-21 06:35 -0400
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-21 06:41 -0400
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-20 10:22 +0000
Re: How efficient are locals? How portable? franck.bensusan@gmail.com - 2015-04-20 23:28 -0700
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-21 11:03 +0000
Re: How efficient are locals? How portable? franck.bensusan@gmail.com - 2015-04-21 07:20 -0700
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-22 15:35 +0000
Re: How efficient are locals? How portable? franck.bensusan@gmail.com - 2015-04-23 10:55 -0700
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-24 07:15 +0000
Re: How efficient are locals? How portable? Bernd Linsel <bl1@gmx.com> - 2015-04-20 17:52 +0200
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-20 09:03 -0700
Re: How efficient are locals? How portable? Lars Brinkhoff <lars.spam@nocrew.org> - 2015-04-22 08:33 +0200
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-22 02:20 -0700
Re: How efficient are locals? How portable? Lars Brinkhoff <lars.spam@nocrew.org> - 2015-04-22 11:35 +0200
Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-20 17:50 +0000
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-17 01:45 -0700
Re: How efficient are locals? How portable? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-04-17 02:37 -0700
Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-17 10:14 +0000
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-17 10:18 +0000
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-17 09:38 -0700
Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-17 21:25 +0100
Re: How efficient are locals? How portable? "WJ" <w_a_x_man@yahoo.com> - 2015-04-18 07:51 +0000
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-19 08:45 -0700
Re: How efficient are locals? How portable? stephen@mpeforth.com (Stephen Pelc) - 2015-04-19 16:24 +0000
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-19 09:58 -0700
Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-19 19:00 +0100
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-19 12:27 -0700
Re: How efficient are locals? How portable? stephen@mpeforth.com (Stephen Pelc) - 2015-04-19 19:42 +0000
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-19 13:49 -0700
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-20 09:39 +0000
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-19 17:59 -0400
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-19 16:39 -0700
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-20 04:58 -0400
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-20 08:52 -0700
Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-20 18:04 +0100
Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-20 19:05 +0100
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-24 10:06 -0700
Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-24 19:18 +0100
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-24 11:43 -0700
Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-24 22:03 +0100
Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-26 20:05 +0100
Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-26 21:05 +0000
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-26 15:08 -0700
Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-27 00:17 +0000
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-27 03:55 -0400
Re: How efficient are locals? How portable? "Elizabeth D. Rather" <erather@forth.com> - 2015-04-26 22:25 -1000
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-29 08:53 -0400
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-29 09:35 -0700
Re: How efficient are locals? How portable? mhx@iae.nl - 2015-04-29 10:14 -0700
Re: How efficient are locals? How portable? "Elizabeth D. Rather" <erather@forth.com> - 2015-04-29 09:00 -1000
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-29 13:22 -0700
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-05-10 22:50 -0700
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-05-10 22:53 -0700
Re: How efficient are locals? How portable? "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-26 23:04 -0400
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-26 20:51 -0700
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-27 09:38 +0000
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-27 23:18 -0700
Re: How efficient are locals? How portable? "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-28 03:19 -0400
Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-27 12:33 +0100
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-27 23:31 -0700
Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-28 08:07 +0100
Re: How efficient are locals? How portable? Lars Brinkhoff <lars.spam@nocrew.org> - 2015-04-28 10:20 +0200
Re: How efficient are locals? How portable? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-04-28 12:17 +0100
Re: How efficient are locals? How portable? Lars Brinkhoff <lars.spam@nocrew.org> - 2015-04-28 14:04 +0200
Re: How efficient are locals? How portable? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-04-28 14:49 +0100
Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-28 22:56 +0100
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-20 23:22 -0700
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-17 13:44 -0700
Re: How efficient are locals? How portable? Coos Haak <chforth@hccnet.nl> - 2015-04-18 00:31 +0200
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-18 14:22 +0000
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-18 22:51 -0700
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-19 01:25 -0700
Re: How efficient are locals? How portable? Coos Haak <chforth@hccnet.nl> - 2015-04-19 21:12 +0200
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-19 12:56 -0700
Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-19 17:53 -0400
Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-20 11:59 +0000
Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-27 00:33 +0000
Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-19 08:31 -0700
Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-30 02:35 -0700
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-04-24 09:21 +0000 |
| Message-ID | <2015Apr24.112144@mips.complang.tuwien.ac.at> |
| In reply to | #38553 |
lehs <skydda.barnen@gmail.com> writes:
>Den torsdag 23 april 2015 kl. 22:56:02 UTC+2 skrev Coos Haak:
>> Op Thu, 23 Apr 2015 10:56:46 -0700 (PDT) schreef lehs:
>> > Yes, the pure stack version is better because it use only fast core wor=
>ds that presumably has an optimal implementation in most Forth systems.
Your assumption that CORE or extension wordset has anything to do with
how efficient they are implemented is wrong. CORE just means that
every standard Forth system must have it, not that it must be
efficient. E.g., DEPTH is a core word. I compared several quicksort
implementations, one of which used DEPTH; the version with DEPTH
turned out to be slowest on several
systems <2013Aug15.191549@mips.complang.tuwien.ac.at>.
>But I don't know how fast my words will run on other Forth systems.
You won't know whether you restrict yourself to CORE words or not.
The only way to know it is to measure it.
So I have measured different variants of your inv-mod example:
The variants are:
vfx: your original version with uninitialized locals, but replaced ->
with TO for portability. I called it vfx because VFX is limited to
running this version with locals and because uninitialized locals are
a workaround for the shortcomings of VFX.
gforth: my first rewrite, using multiple locals definitions and
instead of uninitialized locals and TOs. It is called gforth, because
multiple locals definitions (in particular inside control structures)
are a Gforth feature that VFX does not support yet.
stack: the pure-stack variant, but with the workaround for non-floored
mods.
*-f: the same variants as above, but replacing the MOD workaround with
a floored MOD (either the default MOD of the system, or one based on
FM/MOD).
You can find the code on
http://www.complang.tuwien.ac.at/forth/programs/inv-mod.fs
Here are timings on a 3GHz Core 2 Duo E8400:
for i in vfx vfx-f gforth gforth-f stack stack-f; do /usr/bin/time -f "%Uu $i" ~/gforth/gforth-fast -e "include inv-mod.fs ' inv-mod-$i bench cr bye" >/dev/null; done
1.78u vfx
1.74u vfx-f
1.55u gforth
1.58u gforth-f
1.10u stack
1.10u stack-f
so in Gforth the locals are quite a bit slower, with TO being
particularly slow. The difference between the -f and the non-f
version is small and in one case unexpected: The gforth-f version
should be faster, because it just misses the last part (MOD in Gforth
is floored), but according to the measurement it's slower. Maybe a
cache conflict hiccup or somesuch.
But if you care about performance, you are probably more interested in
a higher-performance system like VFX:
for i in vfx vfx-f stack stack-f; do /usr/bin/time -f "%Uu $i" vfxlin "include inv-mod.fs ' inv-mod-$i bench cr bye" >/dev/null; done
0.51u vfx
0.51u vfx-f
0.45u stack
0.45u stack-f
In VFX the performance difference between the locals and the stack
version is small, even though VFX still keeps locals in registers;
there is no difference between -f and non-f.
And here's another native-code compiler, SwiftForth:
for i in vfx vfx-f stack stack-f; do /usr/bin/time -f "%Uu $i" sf "include inv-mod.fs ' inv-mod-$i bench cr bye" >/dev/null; done
0.94u vfx
0.98u vfx-f
0.56u stack
0.59u stack-f
Slower than VFX, and a larger slowdown for locals. Here it seems that
the MOD workaround is faster than using FM/MOD (unless these are also
hiccups).
Another way to look at these measurements is to compare between Forth
systems: Locals on the fastest system are still faster than anything
on the second-fastest system, so if you care about performance, it may
be a good idea to be flexible in the system you choose (i.e., portable
programming), and it may be more fruitful to run the program on a
faster system than to rewrite it into pure-stack form.
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-04-24 11:44 +0000 |
| Message-ID | <553a2ca2$0$3037$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #38555 |
In article <2015Apr24.112144@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >lehs <skydda.barnen@gmail.com> writes: >>Den torsdag 23 april 2015 kl. 22:56:02 UTC+2 skrev Coos Haak: >>> Op Thu, 23 Apr 2015 10:56:46 -0700 (PDT) schreef lehs: >>> > Yes, the pure stack version is better because it use only fast core wor= >>ds that presumably has an optimal implementation in most Forth systems. > >Your assumption that CORE or extension wordset has anything to do with >how efficient they are implemented is wrong. CORE just means that >every standard Forth system must have it, not that it must be >efficient. E.g., DEPTH is a core word. I compared several quicksort >implementations, one of which used DEPTH; the version with DEPTH >turned out to be slowest on several >systems <2013Aug15.191549@mips.complang.tuwien.ac.at>. > >>But I don't know how fast my words will run on other Forth systems. > >You won't know whether you restrict yourself to CORE words or not. >The only way to know it is to measure it. > >So I have measured different variants of your inv-mod example: > >The variants are: > >vfx: your original version with uninitialized locals, but replaced -> >with TO for portability. I called it vfx because VFX is limited to >running this version with locals and because uninitialized locals are >a workaround for the shortcomings of VFX. > >gforth: my first rewrite, using multiple locals definitions and >instead of uninitialized locals and TOs. It is called gforth, because >multiple locals definitions (in particular inside control structures) >are a Gforth feature that VFX does not support yet. > >stack: the pure-stack variant, but with the workaround for non-floored >mods. > >*-f: the same variants as above, but replacing the MOD workaround with > a floored MOD (either the default MOD of the system, or one based on > FM/MOD). > >You can find the code on > >http://www.complang.tuwien.ac.at/forth/programs/inv-mod.fs > >Here are timings on a 3GHz Core 2 Duo E8400: > >for i in vfx vfx-f gforth gforth-f stack stack-f; do /usr/bin/time -f >"%Uu $i" ~/gforth/gforth-fast -e "include inv-mod.fs ' inv-mod-$i bench >cr bye" >/dev/null; done >1.78u vfx >1.74u vfx-f >1.55u gforth >1.58u gforth-f >1.10u stack >1.10u stack-f > >so in Gforth the locals are quite a bit slower, with TO being >particularly slow. The difference between the -f and the non-f >version is small and in one case unexpected: The gforth-f version >should be faster, because it just misses the last part (MOD in Gforth >is floored), but according to the measurement it's slower. Maybe a >cache conflict hiccup or somesuch. > >But if you care about performance, you are probably more interested in >a higher-performance system like VFX: > >for i in vfx vfx-f stack stack-f; do /usr/bin/time -f "%Uu $i" vfxlin >"include inv-mod.fs ' inv-mod-$i bench cr bye" >/dev/null; done >0.51u vfx >0.51u vfx-f >0.45u stack >0.45u stack-f > >In VFX the performance difference between the locals and the stack >version is small, even though VFX still keeps locals in registers; >there is no difference between -f and non-f. > >And here's another native-code compiler, SwiftForth: > >for i in vfx vfx-f stack stack-f; do /usr/bin/time -f "%Uu $i" sf >"include inv-mod.fs ' inv-mod-$i bench cr bye" >/dev/null; done >0.94u vfx >0.98u vfx-f >0.56u stack >0.59u stack-f > >Slower than VFX, and a larger slowdown for locals. Here it seems that >the MOD workaround is faster than using FM/MOD (unless these are also >hiccups). > >Another way to look at these measurements is to compare between Forth >systems: Locals on the fastest system are still faster than anything >on the second-fastest system, so if you care about performance, it may >be a good idea to be flexible in the system you choose (i.e., portable >programming), and it may be more fruitful to run the program on a >faster system than to rewrite it into pure-stack form. Thanks for making this subject a lot more tangible. I forgot to mention that my version has an algorithmic improvement that does away with half of the multiplications. (In solving A.X+B.Y=1 for input A B , most solutions calculate X Y in tandem. If you don't want locals, you discover that you only need to calculate X and at the very end you may retrieve Y in O(1) operations. Then, mostly you don't need Y.) > >- anton Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | lehs <skydda.barnen@gmail.com> |
|---|---|
| Date | 2015-04-24 08:35 -0700 |
| Message-ID | <6f33674e-2bfc-4b7a-ab3c-b8b4cac2700e@googlegroups.com> |
| In reply to | #38555 |
Den fredag 24 april 2015 kl. 13:19:44 UTC+2 skrev Anton Ertl: > lehs <skydda.barnen@gmail.com> writes: > >Den torsdag 23 april 2015 kl. 22:56:02 UTC+2 skrev Coos Haak: > >> Op Thu, 23 Apr 2015 10:56:46 -0700 (PDT) schreef lehs: > >> > Yes, the pure stack version is better because it use only fast core wor= > >ds that presumably has an optimal implementation in most Forth systems. > > Your assumption that CORE or extension wordset has anything to do with > how efficient they are implemented is wrong. CORE just means that > every standard Forth system must have it, not that it must be > efficient. E.g., DEPTH is a core word. I compared several quicksort > implementations, one of which used DEPTH; the version with DEPTH > turned out to be slowest on several > systems <2013Aug15.191549@mips.complang.tuwien.ac.at>. > > >But I don't know how fast my words will run on other Forth systems. > > You won't know whether you restrict yourself to CORE words or not. > The only way to know it is to measure it. > > So I have measured different variants of your inv-mod example: > > The variants are: > > vfx: your original version with uninitialized locals, but replaced -> > with TO for portability. I called it vfx because VFX is limited to > running this version with locals and because uninitialized locals are > a workaround for the shortcomings of VFX. > > gforth: my first rewrite, using multiple locals definitions and > instead of uninitialized locals and TOs. It is called gforth, because > multiple locals definitions (in particular inside control structures) > are a Gforth feature that VFX does not support yet. > > stack: the pure-stack variant, but with the workaround for non-floored > mods. > > *-f: the same variants as above, but replacing the MOD workaround with > a floored MOD (either the default MOD of the system, or one based on > FM/MOD). > > You can find the code on > > http://www.complang.tuwien.ac.at/forth/programs/inv-mod.fs > > Here are timings on a 3GHz Core 2 Duo E8400: > > for i in vfx vfx-f gforth gforth-f stack stack-f; do /usr/bin/time -f "%Uu $i" ~/gforth/gforth-fast -e "include inv-mod.fs ' inv-mod-$i bench cr bye" >/dev/null; done > 1.78u vfx > 1.74u vfx-f > 1.55u gforth > 1.58u gforth-f > 1.10u stack > 1.10u stack-f > > so in Gforth the locals are quite a bit slower, with TO being > particularly slow. The difference between the -f and the non-f > version is small and in one case unexpected: The gforth-f version > should be faster, because it just misses the last part (MOD in Gforth > is floored), but according to the measurement it's slower. Maybe a > cache conflict hiccup or somesuch. > > But if you care about performance, you are probably more interested in > a higher-performance system like VFX: > > for i in vfx vfx-f stack stack-f; do /usr/bin/time -f "%Uu $i" vfxlin "include inv-mod.fs ' inv-mod-$i bench cr bye" >/dev/null; done > 0.51u vfx > 0.51u vfx-f > 0.45u stack > 0.45u stack-f > > In VFX the performance difference between the locals and the stack > version is small, even though VFX still keeps locals in registers; > there is no difference between -f and non-f. > > And here's another native-code compiler, SwiftForth: > > for i in vfx vfx-f stack stack-f; do /usr/bin/time -f "%Uu $i" sf "include inv-mod.fs ' inv-mod-$i bench cr bye" >/dev/null; done > 0.94u vfx > 0.98u vfx-f > 0.56u stack > 0.59u stack-f > > Slower than VFX, and a larger slowdown for locals. Here it seems that > the MOD workaround is faster than using FM/MOD (unless these are also > hiccups). > > Another way to look at these measurements is to compare between Forth > systems: Locals on the fastest system are still faster than anything > on the second-fastest system, so if you care about performance, it may > be a good idea to be flexible in the system you choose (i.e., portable > programming), and it may be more fruitful to run the program on a > faster system than to rewrite it into pure-stack form. > > - 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 2014: http://www.euroforth.org/ef14/ There are systems that lack certain primitives. If there was a standard for the syntax that wouldn't say much about how fast it run, but if every system had (LOCAL) etc, I could try create a syntax in the search code and it would be possible to estimate the efficiency also in unknown systems. SP-Forth does not include (LOCAL) so any implementation of locals I do runs with unknown efficiency on unknown systems.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-04-24 15:40 +0000 |
| Message-ID | <2015Apr24.174028@mips.complang.tuwien.ac.at> |
| In reply to | #38563 |
lehs <skydda.barnen@gmail.com> writes:
>There are systems that lack certain primitives. If there was a standard for=
> the syntax that wouldn't say much about how fast it run, but if every syst=
>em had (LOCAL) etc, I could try create a syntax in the search code and it w=
>ould be possible to estimate the efficiency also in unknown systems.
(LOCAL) does not tell you how locals are implemented; are they in
registers or in memory, etc. Indeed, the standard does not tell you
anything about efficiency, i.e., efficiency is not standardized, it's
a quality-of-implementation issue, as they say. So you a certain
slowdown from locals on VFX, and significantly more slowdown from
SwiftForth and Gforth.
But it may interest you that I have now used the
forth200x/extensions/locals.fs implementation with VFX and it delivers
slighly slower results than VFX's builtin implementation of "{:":
0.54u vfx
0.54u vfx-f
0.54s instead of 0.51s for the builtin "{:". Still much less slowdown
than from SwiftForth or Gforth.
I also looked at the code SwiftForth produces. It seems that it uses
a locals pointer that resides in memory (probably in a user variable),
and that pointer is loaded on every locals access. This is what a
locals read looks like:
808389A 4 # EBP SUB update data stack pointer
808389D EBX 0 [EBP] MOV store current TOS to memory
80838A0 9C [ESI] EBX MOV get locals pointer
80838A6 4 [EBX] EBX MOV load local
So yes, not really efficient.
> SP-For=
>th does not include (LOCAL) so any implementation of locals I do runs with =
>unknown efficiency on unknown systems.
As discussed above, any implementation of locals or anything else runs
with unknown efficiency on unknown systems.
Anyway, if performance is really that important to you, and the
systems you are interested in have incompatible locals
implementations, run a benchmark on all of them, and select the one
that is fastest.
If, OTOH, you are really interested in portability, you should use
"{:" instead of "{" and TO instead of "->". Concerning SP-Forth, You
could ask their maintainers to implement {: or (LOCAL), or maybe
implement it yourself.
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2015-04-24 10:28 -0700 |
| Message-ID | <936b6ad1-d95d-49ba-a7e4-60e91481ec24@googlegroups.com> |
| In reply to | #38555 |
On Friday, April 24, 2015 at 1:19:44 PM UTC+2, Anton Ertl wrote: > lehs <skydda.barnen@gmail.com> writes: > >Den torsdag 23 april 2015 kl. 22:56:02 UTC+2 skrev Coos Haak: > >> Op Thu, 23 Apr 2015 10:56:46 -0700 (PDT) schreef lehs: [..] > So I have measured different variants of your inv-mod example: [..] > for i in vfx vfx-f gforth gforth-f stack stack-f; do /usr/bin/time -f "%Uu $i" ~/gforth/gforth-fast -e "include inv-mod.fs ' inv-mod-$i bench cr bye" >/dev/null; done > 1.78u vfx > 1.74u vfx-f > 1.55u gforth > 1.58u gforth-f > 1.10u stack > 1.10u stack-f [..] > for i in vfx vfx-f stack stack-f; do /usr/bin/time -f "%Uu $i" vfxlin "include inv-mod.fs ' inv-mod-$i bench cr bye" >/dev/null; done > 0.51u vfx > 0.51u vfx-f > 0.45u stack > 0.45u stack-f Here are the results for iForth64 (64bit): FORTH> in Redefining mod inv-mod-vfx : 4531099045726 0.671 seconds elapsed. inv-mod-stack : 4531099045726 0.533 seconds elapsed. inv-mod-vfx-f : 4531099045726 0.684 seconds elapsed. inv-mod-stack-f : 4531099045726 0.545 seconds elapsed. ok I guess the output is wrong. What is the expected result? -marcel
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-04-24 17:43 +0000 |
| Message-ID | <2015Apr24.194356@mips.complang.tuwien.ac.at> |
| In reply to | #38568 |
mhx@iae.nl writes:
>On Friday, April 24, 2015 at 1:19:44 PM UTC+2, Anton Ertl wrote:
>Here are the results for iForth64 (64bit):
>
>FORTH> in
>Redefining mod
>inv-mod-vfx : 4531099045726 0.671 seconds elapsed.
>inv-mod-stack : 4531099045726 0.533 seconds elapsed.
>inv-mod-vfx-f : 4531099045726 0.684 seconds elapsed.
>inv-mod-stack-f : 4531099045726 0.545 seconds elapsed. ok
>
>I guess the output is wrong. What is the expected result?
4531099045726, so the output is right. I guess 64-bits may cause some
slowdown for iForth and gforth (64-bit division is slower AFAIK).
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2015-04-24 22:44 -0700 |
| Message-ID | <d558be79-2c37-4db8-958a-f12934b6f31a@googlegroups.com> |
| In reply to | #38569 |
On Friday, April 24, 2015 at 7:45:48 PM UTC+2, Anton Ertl wrote: > mhx@iae.nl writes: > >On Friday, April 24, 2015 at 1:19:44 PM UTC+2, Anton Ertl wrote: > >Here are the results for iForth64 (64bit): > > > >FORTH> in > >Redefining mod > >inv-mod-vfx : 4531099045726 0.671 seconds elapsed. > >inv-mod-stack : 4531099045726 0.533 seconds elapsed. > >inv-mod-vfx-f : 4531099045726 0.684 seconds elapsed. > >inv-mod-stack-f : 4531099045726 0.545 seconds elapsed. ok > > > >I guess the output is wrong. What is the expected result? > > 4531099045726, so the output is right. I guess 64-bits may cause some > slowdown for iForth and gforth (64-bit division is slower AFAIK). > > - anton iForth32 still works (of course), so I tried it: Redefining mod inv-mod-vfx : 4531099045726 0.474 seconds elapsed. inv-mod-stack : 4531099045726 0.375 seconds elapsed. inv-mod-vfx-f : 4531099045726 0.488 seconds elapsed. inv-mod-stack-f : 4531099045726 0.381 seconds elapsed. ok Indeed, 64-bit division hurts (on present hardware). -marcel
[toc] | [prev] | [next] | [standalone]
| From | empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> |
|---|---|
| Date | 2015-04-24 15:00 +0000 |
| Message-ID | <slrnmjkq4j.77u.empty.buffersYOU-DONT-WANT-THIS@Ferrycy.localdomain> |
| In reply to | #38530 |
In comp.lang.forth, lehs wrote:
> If you really want an example, convert this one
>
>: INV_MOD { x y | q u v a c t -- n }
> x -> u y -> v 1 -> c \ 0 -> a
> BEGIN u
> WHILE v u / -> q
> c -> t a q c * - -> c t -> a
> u -> t v q u * - -> u t -> v
> REPEAT a y MOD DUP -> a 0<
> IF y a + ELSE a THEN ;
>
> which calculates the multiplicative inverse n of x(mod y), n*x = 1(mod y).
So your word takes either x y or q u v a c t from the stack (either 2 or 5
values)? This is an error, your word should expect always the same number of
values. Or perhaps stack description is erroneous?
Could you, please, write just the math your word should perform? But do it
properly, please: "mod y" means nothing, only "x mod y" means something.
Well I tried to paste your word into Gforth's command line - it doesn't work.
Instead of cleaning the above up I prefer to create it from the ground up.
It shall be easier.
--
- "I'll pulverize Trurl!" - said the machine - "But first, he'll tell me
how much two and two makes." [..]
- "Fo... that is, seven..."
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-04-24 09:07 -0700 |
| Message-ID | <87d22tmrwe.fsf@jester.gateway.sonic.net> |
| In reply to | #38561 |
empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com>
writes:
>>: INV_MOD { x y | q u v a c t -- n }
> So your word takes either x y or q u v a c t from the stack (either 2 or 5
> values)? This is an error, your word should expect always the same number of
> values. Or perhaps stack description is erroneous?
I think the idea is that INV_MOD allocates 8 locals (x,y,q,v,a,c,t)
and at the beginning of the function, it copies the top two stack slots
into x and y (the locals before the vertical bar). The other locals
become uninitialized cells that get written to with -> .
> Could you, please, write just the math your word should perform?
https://en.wikipedia.org/wiki/Extended_Euclidean_algorithm
> Well I tried to paste your word into Gforth's command line - it
> doesn't work.
gforth locals work differently.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-04-23 07:30 -0700 |
| Message-ID | <123cbf9d-eebe-4073-b1c1-4d190b9e0bed@googlegroups.com> |
| In reply to | #38520 |
> Forth _IS_ different to other languages - and why IYO it should be "more > similar" (apart of "attraction" aspect)? If you prefer other language's > syntax - you can use that other language. What's a problem? > What syntax has Forth? You seem to be a purist. You don't like locals or other things that are not "forth like". What is forth like then? Why does forth have VALUE and TO even for globals? Why does Forth have forward parsing (words that parse words) when it should be only postfix? IMO the locals in forth are a design mistake. They shouldn't been VALUES. They should have been like real variables. In this way you would have been able to have not only cell sized locals, but many different sizes. For example, I really have a need in an application to process a lot of 22 chars strings in reentrant functions (called from many different real time tasks). I need local strings of 22 bytes. How can I have that in Forth? Is this such a hard thing to ask for? Should I use C or whatever because in Forth is not possible to have flexible local storage? It's not about syntax. It's about not having anything. It's about not having local variables (forth locals are just named >R R@ R>), not having arrays of any kind, not having structured data. And I even don't care how fast this things should be for a start. They only should be there, ready to be used. A language with only a stack, a cheap procedure calling and a lot of hacking things like >R R> is not for 21st century, sorry.
[toc] | [prev] | [next] | [standalone]
| From | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2015-04-23 11:02 -0400 |
| Message-ID | <55390990$0$292$14726298@news.sunsite.dk> |
| In reply to | #38539 |
On 4/23/15 10:30 AM, Raimond Dragomir wrote:
> ... For example, I really have a need in an application
> to process a lot of 22 chars strings in reentrant functions (called
> from many different real time tasks). I need local strings of 22
> bytes. How can I have that in Forth?
variable cnt 0 cnt !
: foo
22 allocate throw { str }
s" 1234567890123456789012"
str swap move
cr str 22 type
1 cnt +!
cnt @ 5 < if recurse then
str free throw ;
-Doug
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-04-23 16:30 +0100 |
| Message-ID | <mhb35i$d3b$1@dont-email.me> |
| In reply to | #38539 |
on 23/04/2015 15:30:23, Raimond Dragomir wrote:
>> Forth _IS_ different to other languages - and why IYO it should be "more
>> similar" (apart of "attraction" aspect)? If you prefer other language's
>> syntax - you can use that other language. What's a problem?
>>
> What syntax has Forth? You seem to be a purist. You don't like locals
> or ot her things that are not "forth like". What is forth like then?
> Why does for th have VALUE and TO even for globals? Why does Forth
> have forward parsing (words that parse words) when it should be only
> postfix? IMO the locals in forth are a design mistake. They shouldn't
> been VALUES. T hey should have been like real variables. In this way
> you would have been a ble to have not only cell sized locals, but many
> different sizes. For examp le, I really have a need in an application
> to process a lot of 22 chars str ings in reentrant functions (called
> from many different real time tasks). I need local strings of 22
> bytes. How can I have that in Forth? Is this such a hard thing to ask
> for? Should I use C or whatever because in Forth is no t possible to
> have flexible local storage? It's not about syntax. It's about not
> having anything. It's about not havin g local variables (forth locals
> are just named >R R@ R>), not having arrays of any kind, not having
> structured data. And I even don't care how fast this things should be
> for a start. They only should be there, ready to be used.
> A language with only a stack, a cheap procedure calling and a lot of
> hackin g things like >R R> is not for 21st century, sorry.
>
Gforth extends the local syntax to include variables. w: c: and f: are
value based cells, chars and floats; w^, c^ and f^ are the equivalent
variables. It can be extended.
"The following ambiguous conditions exist when: – a local name ends in
“:”, “[”, “^”;".
STC Experimental 32bit: 0.06.07 Build: 285
: foo 3 {: w^ y :} y . y @ . ; ok
foo 1638220 3 ok
As to local strings, it doesn't require more than the standard value
type.
: bar 22 chars allocate abort" allocate failed"
{: str :} ( str is address of 22 char buffer ) ... ;
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-04-23 09:38 -0700 |
| Message-ID | <c713a599-803b-4088-8a38-1b4eb8cf8524@googlegroups.com> |
| In reply to | #38543 |
joi, 23 aprilie 2015, 18:30:56 UTC+3, Alex McDonald a scris:
> on 23/04/2015 15:30:23, Raimond Dragomir wrote:
> >> Forth _IS_ different to other languages - and why IYO it should be "more
> >> similar" (apart of "attraction" aspect)? If you prefer other language's
> >> syntax - you can use that other language. What's a problem?
> >>
> > What syntax has Forth? You seem to be a purist. You don't like locals
> > or ot her things that are not "forth like". What is forth like then?
> > Why does for th have VALUE and TO even for globals? Why does Forth
> > have forward parsing (words that parse words) when it should be only
> > postfix? IMO the locals in forth are a design mistake. They shouldn't
> > been VALUES. T hey should have been like real variables. In this way
> > you would have been a ble to have not only cell sized locals, but many
> > different sizes. For examp le, I really have a need in an application
> > to process a lot of 22 chars str ings in reentrant functions (called
> > from many different real time tasks). I need local strings of 22
> > bytes. How can I have that in Forth? Is this such a hard thing to ask
> > for? Should I use C or whatever because in Forth is no t possible to
> > have flexible local storage? It's not about syntax. It's about not
> > having anything. It's about not havin g local variables (forth locals
> > are just named >R R@ R>), not having arrays of any kind, not having
> > structured data. And I even don't care how fast this things should be
> > for a start. They only should be there, ready to be used.
> > A language with only a stack, a cheap procedure calling and a lot of
> > hackin g things like >R R> is not for 21st century, sorry.
> >
>
> Gforth extends the local syntax to include variables. w: c: and f: are
> value based cells, chars and floats; w^, c^ and f^ are the equivalent
> variables. It can be extended.
>
> "The following ambiguous conditions exist when: - a local name ends in
> ":", "[", "^";".
>
> STC Experimental 32bit: 0.06.07 Build: 285
> : foo 3 {: w^ y :} y . y @ . ; ok
> foo 1638220 3 ok
>
> As to local strings, it doesn't require more than the standard value
> type.
>
> : bar 22 chars allocate abort" allocate failed"
> {: str :} ( str is address of 22 char buffer ) ... ;
Sorry, I forgot to say: No dynamic memory please. I'm working in embedded systems world, and I'm not using dynamic allocation, ever.
The application is simple like that, I need some (flexible) local storage on the stack, unless I will be forced to write multiple copies of the same function, for every task.
This need is so simple that a simple locals implementation that makes the locals behaving like standard variables will do. The local will put it's address (offset + frame in fact) on the stack, and that can be @, c@, etc, computed with indexes, etc.
Very simple, done that in my system. Of course, my system is not forth anymore in some opinions, but who cares? Yes it is inspired from C. I have simple structs inspired from C also, even enums. But the syntax is no way C like. It's forth all the day long.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-04-24 15:57 +0100 |
| Message-ID | <mhdliv$vmh$1@dont-email.me> |
| In reply to | #38544 |
on 23/04/2015 17:38:24, Raimond Dragomir wrote:
> joi, 23 aprilie 2015, 18:30:56 UTC+3, Alex McDonald a scris:
>>
>> As to local strings, it doesn't require more than the standard value
>> type.
>>
>> : bar 22 chars allocate abort" allocate failed"
>> {: str :} ( str is address of 22 char buffer ) ... ;
>
> Sorry, I forgot to say: No dynamic memory please. I'm working in
> embedded systems world, and I'm not using dynamic allocation, ever.
: bar here 22 chars allot {: str :} ...
-22 chars allot ;
[toc] | [prev] | [next] | [standalone]
| From | empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> |
|---|---|
| Date | 2015-04-24 15:14 +0000 |
| Message-ID | <slrnmjkquk.77u.empty.buffersYOU-DONT-WANT-THIS@Ferrycy.localdomain> |
| In reply to | #38539 |
In comp.lang.forth, Raimond Dragomir wrote: > What syntax has Forth? You seem to be a purist. You don't like locals or > other things that are not "forth like". What is forth like then? Why > does forth have VALUE and TO even for globals? Why does Forth have > forward parsing (words that parse words) when it should be only postfix? Dear Raimond: as it has been stated earlier in this thread, "forth-like" is contrary to "algoholic-like". > IMO the locals in forth are a design mistake. They shouldn't been VALUES. > They should have been like real variables. In this way you would have > been able to have not only cell sized locals, but many different sizes. > For example, I really have a need in an application to process a lot of 22 > chars strings in reentrant functions (called from many different real time > tasks). I need local strings of 22 bytes. How can I have that in Forth? Maybe CREATE..DOES could help you? "Starting Forth", chapter 8. ( http://www.forth.com/starting-forth/sf11/sf11.html ) > Is this such a hard thing to ask for? Should I use C or whatever because > in Forth is not possible to have flexible local storage? It's not about > syntax. It's about not having anything. It's about not having local > variables You seem to have a lot Forth-related problems. Well I really sympathize. > (forth locals are just named >R R@ R>), not having arrays of any > kind, not having structured data. "Starting Forth", chapter 8. ( http://www.forth.com/starting-forth/sf8/sf8.html ) > And I even don't care how fast this > things should be for a start. They only should be there, ready to be > used. A language with only a stack, a cheap procedure calling and a lot > of hacking things like >R R> is not for 21st century, sorry. It depends on requirements. Maybe indeed some other language is better for you? So why you insist on using Forth, which doesn't meet your requirements? You can use some other tool, which probably suits your task better. I just don't need "local strings of 22 bytes" - and I usually avoid to transfer experiences from those "algoholic languages" to Forth. Instead I think: "I've got a set of tools provided by Forth. How can I achieve my goal?". If you'll still be "thinking C" - not "thinking Forth" - you'll be always complaining for "lack of local strings of 22 bytes", or the like. -- - "I'll pulverize Trurl!" - said the machine - "But first, he'll tell me how much two and two makes." [..] - "Fo... that is, seven..."
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-04-23 06:58 -0400 |
| Message-ID | <mhaj7c$ebg$1@dont-email.me> |
| In reply to | #38518 |
On 4/22/2015 6:29 PM, empty-buffers wrote: > > Back to original subject: if you really feel a need for locals, then most > probably your words are too big, or at least much too complicated - which > suggests bad factoring. I'm not sure that is always the case. There are times when the problem at hand is just unwieldy on a stack. For example if you are working with 3 dimensional coordinate and need to do an operation on two points, the data on the stack is unreachable without moving a lot of stuff around. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2015-04-23 14:47 +0200 |
| Message-ID | <8guiiv454z0m$.1kgoyet9zm934.dlg@40tude.net> |
| In reply to | #38532 |
Op Thu, 23 Apr 2015 06:58:41 -0400 schreef rickman: > On 4/22/2015 6:29 PM, empty-buffers wrote: >> >> Back to original subject: if you really feel a need for locals, then most >> probably your words are too big, or at least much too complicated - which >> suggests bad factoring. > > I'm not sure that is always the case. There are times when the problem > at hand is just unwieldy on a stack. For example if you are working > with 3 dimensional coordinate and need to do an operation on two points, > the data on the stack is unreachable without moving a lot of stuff around. Or use pointers to structures or records then. -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-04-23 08:34 -1000 |
| Message-ID | <C_GdnW5oMf2upqTInZ2dnUU7-IOdnZ2d@supernews.com> |
| In reply to | #38532 |
On 4/23/15 12:58 AM, rickman wrote: > On 4/22/2015 6:29 PM, empty-buffers wrote: >> >> Back to original subject: if you really feel a need for locals, then most >> probably your words are too big, or at least much too complicated - which >> suggests bad factoring. > > I'm not sure that is always the case. There are times when the problem > at hand is just unwieldy on a stack. For example if you are working > with 3 dimensional coordinate and need to do an operation on two points, > the data on the stack is unreachable without moving a lot of stuff around. > I have dealt with multi-dimensional operations a lot in the past, working with Chuck. We never attempt to deal with a lot of 2- and 3-vectors on the stack moving things around. In the context of the application, we have vector structures in memory and vector operators such as V+ and V*/ (multiplies a vector by a ratio of scalars), etc. It's not necessary to have everything on the stack. People are much too phobic about real variables. The cry, "They aren't re-entrant" simply means you have to look at the whole application and how it is organized. A well-designed application with a graphics component can avoid conflicts. 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]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-04-13 12:32 +0000 |
| Message-ID | <2015Apr13.143244@mips.complang.tuwien.ac.at> |
| In reply to | #38115 |
lehs <skydda.barnen@gmail.com> writes:
>I really, really like to use local variables. But not to the price of low efficiency and portability. What is the price?
>
>And if it is possible to make it run fast, shouldn't there be a standard?
Locals are standardized in Forth-94 and Forth-2012, and they are
portable between systems.
It is possible to make them fast, but some systems fail to do so yet.
This is somewhat of a chicken-and-egg problem: There is not that much
code that uses locals, yet, so system implementors have little
incentive to make them fast, so people avoid locals for
performance-critical code. As a result, there is not that much code
that uses locals, yet.
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-04-13 21:57 -0400 |
| Message-ID | <mghs3n$3ri$1@dont-email.me> |
| In reply to | #38169 |
On 4/13/2015 8:32 AM, Anton Ertl wrote: > lehs <skydda.barnen@gmail.com> writes: >> I really, really like to use local variables. But not to the price of low efficiency and portability. What is the price? >> >> And if it is possible to make it run fast, shouldn't there be a standard? > > Locals are standardized in Forth-94 and Forth-2012, and they are > portable between systems. > > It is possible to make them fast, but some systems fail to do so yet. > This is somewhat of a chicken-and-egg problem: There is not that much > code that uses locals, yet, so system implementors have little > incentive to make them fast, so people avoid locals for > performance-critical code. As a result, there is not that much code > that uses locals, yet. For those less familiar with the internals of how locals work could someone give me the nickel tour? I would have thought they could be addressed while on the stack, but I suppose they would be in the way of normal use of the stack. So they must be pulled off and stored somewhere. I suppose space is allocated in the dictionary without a header. But if something else is allocated while the local is in use, that space could not be freed up when the local scope is exited. So how dem do dat? -- Rick
[toc] | [prev] | [next] | [standalone]
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web