Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #40779 > unrolled thread
| Started by | rickman <gnuarm@gmail.com> |
|---|---|
| First post | 2015-07-24 12:19 -0400 |
| Last post | 2015-11-30 02:55 -0500 |
| Articles | 20 on this page of 178 — 30 participants |
Back to article view | Back to comp.lang.forth
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-24 12:19 -0400
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-24 10:15 -0700
Re: Which scripting for embedded automation? foxaudioresearch@gmail.com - 2015-07-24 10:32 -0700
Re: Which scripting for embedded automation? "WJ" <w_a_x_man@yahoo.com> - 2015-07-24 23:06 +0000
Re: Which scripting for embedded automation? Don Y <this@is.not.me.com> - 2015-07-24 17:00 -0700
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-24 20:52 -0400
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-07-25 01:28 -0700
Re: Which scripting for embedded automation? josv@planet.nl - 2015-07-25 07:15 -0700
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-25 10:19 -0400
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-25 10:26 -0700
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-07-27 00:42 -0700
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-26 22:07 -1000
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-07-27 01:44 -0700
Re: Which scripting for embedded automation? foxaudioresearch@gmail.com - 2015-07-27 05:57 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 14:02 +0100
Re: Which scripting for embedded automation? foxaudioresearch@gmail.com - 2015-07-27 08:41 -0700
Re: Which scripting for embedded automation? Julian Fondren <julian.fondren@gmail.com> - 2015-07-27 08:36 -0700
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-25 10:20 -0400
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-26 04:01 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-26 18:53 +0100
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-26 11:18 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-26 20:25 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-27 07:36 +0000
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-27 01:12 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-27 10:02 +0000
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 13:44 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-27 15:15 +0000
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-27 04:52 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 14:01 +0100
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-27 06:16 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 14:33 +0100
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 14:34 +0100
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-27 10:47 -0700
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-27 08:12 -1000
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-27 11:24 -0700
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-27 08:41 -1000
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-27 12:49 -0700
Re: Which scripting for embedded automation? Julian Fondren <julian.fondren@gmail.com> - 2015-07-27 14:38 -0700
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-27 12:02 -1000
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-07-27 11:16 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 20:11 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-27 13:50 +0000
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-27 08:56 -0700
Re: Which scripting for embedded automation? Doug Hoffman <glidedog@gmail.com> - 2015-08-09 09:32 -0400
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-08-09 16:30 -1000
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-09 22:56 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-10 08:53 +0000
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-08-10 08:28 -1000
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-11 15:17 +0000
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-10 14:14 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-10 16:29 -0700
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-08-11 01:44 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-08-11 11:09 +0100
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-08-11 11:03 -0400
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-08-11 08:08 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-08-11 17:21 +0100
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-11 22:05 -0700
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-08-12 05:50 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-08-12 18:02 +0100
Re: Which scripting for embedded automation? Mark Wills <markwills1970@gmail.com> - 2015-08-12 05:51 -0700
Re: Which scripting for embedded automation? mhx@iae.nl - 2015-08-12 10:18 -0700
Re: Which scripting for embedded automation? mhx@iae.nl - 2015-08-13 10:37 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-14 12:13 +0000
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-14 21:30 +0200
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-14 13:05 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-15 16:57 +0000
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-16 00:12 +0200
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-16 09:44 +0000
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-17 00:06 +0200
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-18 09:13 +0000
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-18 09:02 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-08-19 00:02 +0100
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-08-18 14:20 -1000
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-19 03:12 +0200
Re: Which scripting for embedded automation? mhx@iae.nl - 2015-08-14 13:09 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-14 13:43 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-15 17:10 +0000
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-12 21:16 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-12 21:31 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-12 21:39 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-13 13:43 -0700
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-08-13 10:55 +0100
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-14 12:06 -0700
Re: Which scripting for embedded automation? Alex McDonald <blog@rivadpm.com> - 2015-08-14 18:33 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-15 19:33 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-23 16:59 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-13 15:52 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-10 08:43 +0000
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-27 06:04 -0700
Re: Which scripting for embedded automation? Julian Fondren <ayrnieu@gmail.com> - 2015-07-26 13:49 -0700
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-26 14:56 -1000
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-26 14:20 -0400
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-26 17:29 -0700
Re: Which scripting for embedded automation? "WJ" <w_a_x_man@yahoo.com> - 2015-08-10 22:52 +0000
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-26 17:11 -0400
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-26 22:38 +0100
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-26 15:07 -1000
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-26 21:26 -0400
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-26 16:49 -1000
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-27 01:30 -0400
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-26 22:19 -1000
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-27 19:31 -0400
Re: Which scripting for embedded automation? Julian Fondren <julian.fondren@gmail.com> - 2015-07-27 16:44 -0700
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-27 20:32 -0400
Re: Which scripting for embedded automation? Bernd Linsel <bl1@gmx.com> - 2015-07-28 18:57 +0200
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-27 22:03 -1000
Re: Which scripting for embedded automation? stephen@mpeforth.com (Stephen Pelc) - 2015-07-27 09:12 +0000
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-07-27 11:02 -0700
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-27 14:14 -0400
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-27 20:17 +0100
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-27 19:33 -0400
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-27 22:05 -1000
Re: Which scripting for embedded automation? "Alex McDonald" <blog@rivadpm.com> - 2015-07-28 12:47 +0100
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-28 23:52 -0400
Re: Which scripting for embedded automation? awegel@arcor.de (Alexander Wegel) - 2015-07-29 12:24 +0200
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-27 19:32 -0400
Re: Which scripting for embedded automation? Bernd Linsel <bl1@gmx.com> - 2015-07-28 19:22 +0200
Re: Which scripting for embedded automation? Walter Banks <walter@bytecraft.com> - 2015-07-28 15:46 -0400
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-28 23:47 -0400
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-29 07:22 +0000
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-29 00:48 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-29 10:15 +0000
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-31 11:34 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-04 09:21 +0000
Re: Which scripting for embedded automation? Walter Banks <walter@bytecraft.com> - 2015-07-29 13:27 -0400
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-29 18:53 -0400
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-30 12:40 +0000
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-30 22:15 -0400
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-07-30 21:51 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-31 10:32 +0000
Re: Which scripting for embedded automation? David Thompson <dave.thompson2@verizon.net> - 2015-08-16 02:31 -0400
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-16 09:53 +0000
Re: Which scripting for embedded automation? Bernd Linsel <bl1@gmx.com> - 2015-07-29 17:50 +0200
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-30 13:14 +0000
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-29 10:28 +0000
Re: Which scripting for embedded automation? Bernd Linsel <bl1@gmx.com> - 2015-07-29 18:24 +0200
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-29 17:09 +0000
Re: Which scripting for embedded automation? Bernd Linsel <bl1@gmx.com> - 2015-07-30 02:01 +0200
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-07-29 17:58 -0700
Re: Which scripting for embedded automation? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-30 21:26 -0400
Re: Which scripting for embedded automation? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-31 00:06 -0700
Re: Which scripting for embedded automation? Hannu Vuolasaho <vuokkosetae@gmail.com> - 2015-07-31 13:35 +0300
Re: Which scripting for embedded automation? Mikael Nordman <oh2aun@gmail.com> - 2015-08-01 01:12 -0700
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-07-31 15:05 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-30 12:03 +0000
Re: Which scripting for embedded automation? Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-02 16:29 +0100
Re: Which scripting for embedded automation? Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-02 16:58 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-02 15:43 +0000
Re: Which scripting for embedded automation? Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-02 18:24 +0100
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-02 20:09 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-03 12:07 +0000
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-03 22:22 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-04 09:47 +0000
Re: Which scripting for embedded automation? Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-04 14:59 +0100
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-04 14:13 +0000
Re: Which scripting for embedded automation? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-02 20:29 +0000
Re: Which scripting for embedded automation? Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-05 12:02 +0100
Re: Which scripting for embedded automation? Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-11-05 15:57 +0100
Re: Which scripting for embedded automation? Walter Banks <walter@bytecraft.com> - 2015-07-28 15:32 -0400
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-07-29 16:35 -0700
Re: Which scripting for embedded automation? Walter Banks <walter@bytecraft.com> - 2015-08-01 22:50 -0400
Re: Which scripting for embedded automation? hughaguilar96@gmail.com - 2015-08-01 20:06 -0700
Re: Which scripting for embedded automation? humptydumpty <ouatubi@gmail.com> - 2015-07-26 22:56 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-27 07:32 +0000
Re: Which scripting for embedded automation? humptydumpty <ouatubi@gmail.com> - 2015-07-27 01:46 -0700
Re: Which scripting for embedded automation? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-27 07:54 +0000
Re: Which scripting for embedded automation? humptydumpty <ouatubi@gmail.com> - 2015-07-27 22:42 -0700
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-28 02:38 -0700
Re: Which scripting for embedded automation? humptydumpty <ouatubi@gmail.com> - 2015-07-28 05:28 -0700
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-28 05:41 -0700
Re: Which scripting for embedded automation? humptydumpty <ouatubi@gmail.com> - 2015-07-28 05:49 -0700
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-07-28 14:14 -0400
Re: Which scripting for embedded automation? "Elizabeth D. Rather" <erather@forth.com> - 2015-07-28 07:38 -1000
Re: Which scripting for embedded automation? glidedog@gmail.com - 2015-07-28 13:37 -0700
Re: Which scripting for embedded automation? "WJ" <w_a_x_man@yahoo.com> - 2015-11-28 18:06 +0000
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-11-29 02:45 -0500
Re: Which scripting for embedded automation? Paul Rubin <no.email@nospam.invalid> - 2015-11-29 23:02 -0800
Re: Which scripting for embedded automation? rickman <gnuarm@gmail.com> - 2015-11-30 02:55 -0500
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-07-29 00:48 -0700 |
| Message-ID | <87wpxjo14h.fsf@jester.gateway.sonic.net> |
| In reply to | #40886 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > Tail-call optimization? Neither guaranteed nor commonplace (in > general, not possible). Coroutining? Nope. Prolog-like backtracking? How do you do coroutines portably in ANS Forth?
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-07-29 10:15 +0000 |
| Message-ID | <2015Jul29.121553@mips.complang.tuwien.ac.at> |
| In reply to | #40888 |
Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> Tail-call optimization? Neither guaranteed nor commonplace (in
>> general, not possible). Coroutining? Nope. Prolog-like backtracking?
>
>How do you do coroutines portably in ANS Forth?
Not possible. But the comparison was with the capabilities of CPUs,
not with Forth.
PAF contains features to allow these things (in particular,
first-class labels and guaranteed tail-call optimization).
Coroutining is possible in PAF by implementing the stacks explicitly;
it might be a good idea to reify the implicit PAF stack for a more
efficient implementation.
- 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.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-07-31 11:34 -0700 |
| Message-ID | <87mvyckwgr.fsf@jester.gateway.sonic.net> |
| In reply to | #40891 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > PAF contains features to allow these things (in particular, > first-class labels and guaranteed tail-call optimization). > Coroutining is possible in PAF by implementing the stacks explicitly; > it might be a good idea to reify the implicit PAF stack for a more > efficient implementation. I wonder if this could be extended to implement coroutines: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.216.8043
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-08-04 09:21 +0000 |
| Message-ID | <2015Aug4.112100@mips.complang.tuwien.ac.at> |
| In reply to | #41023 |
Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> PAF contains features to allow these things (in particular,
>> first-class labels and guaranteed tail-call optimization).
>> Coroutining is possible in PAF by implementing the stacks explicitly;
>> it might be a good idea to reify the implicit PAF stack for a more
>> efficient implementation.
>
>I wonder if this could be extended to implement coroutines:
>
>http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.216.8043
Sure, why not? If you can convert calls and returns to jumps inside
one function, you can also do so with coroutine calls. But flattening
does not work for all kinds of code, e.g., not recursive code. So if
yoiur coroutines are, say recursive tree walks, flattening does not
work, just as any other fake form of coroutining.
- 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.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2015-07-29 13:27 -0400 |
| Message-ID | <mpb2eh$hpq$1@speranza.aioe.org> |
| In reply to | #40886 |
On 29/07/2015 3:22 AM, Anton Ertl wrote: > "Rod Pemberton" <boo@fasdfrewar.cdm> writes: >> Yes. Everything an 8-bit microprocessor can do, and the general >> purpose instructions of 16-bit processors, can be done directly in >> C without needing to use assembly. The only thing missing is a >> carry flag and an overflow flag. > > Yes, these are two things that you cannot express directly in C. > > Another big restriction of C is that you are limited in the kind of > control-flow you can do. Threaded code? Not in standard C. > Tail-call optimization? Neither guaranteed nor commonplace (in > general, not possible). Coroutining? Nope. Prolog-like backtracking? > Nope. Tail-call optimization is part of most current embedded C compilers. It for the most part almost eliminates the need for stack variables compilers targeting small embedded processors. Threaded code for small processors no common implementation. w..
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-07-29 18:53 -0400 |
| Message-ID | <op.x2j4ixevyfako5@localhost> |
| In reply to | #40886 |
On Wed, 29 Jul 2015 03:22:37 -0400, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> "Rod Pemberton" <boo@fasdfrewar.cdm> writes:
>> Yes. Everything an 8-bit microprocessor can do, and the general
>> purpose instructions of 16-bit processors, can be done directly in
>> C without needing to use assembly. The only thing missing is a
>> carry flag and an overflow flag.
>
> Yes, these are two things that you cannot express directly in C.
>
> Another big restriction of C is that you are limited in the kind
> of control-flow you can do.
This statement was in regards to threaded code, yes?
Or, was that meant as a general comment on C's control-flow?
> Threaded code? Not in standard C.
That's not true. I implemented my ITC Forth interpreter in pure
ANSI C, i.e., no special features. It works the exact same way
as a Forth interpreter in assembly, i.e.., it implements a virtual
machine with W, IP, SP, RP, etc, inner and outer interpreters,
dictionary with NFA, CFA, LFA, PFA, etc. The dictionary layout is
also identical, except for one additional pointer, to what would've
been needed if I had coded it in x86 assembly. The extra pointer
was because you don't have control of placement of stored data with
C. Of course, it requires a cast here and there, but not much
overriding of C's type system. I was working on a different layout
that wouldn't require some of the casts and the extra pointer, but
it would then require an additional pointer to the name field.
Lose one. Gain one. Although, I might be able to reduce the few
remaining casts down to one or a few. Most other implementations
in C use a switch() statement to effect threaded style code. They
don't use actual threaded code.
> Tail-call optimization? Neither guaranteed nor commonplace
> (in general, not possible).
That's up to the compiler ...
> Coroutining? Nope.
That's not true either. Again, it's just more difficult.
C was designed for a single entry to a procedure, i.e.,
structured code.
Simon Tathem's coroutines in C:
http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
Those are based off of Duff's device which he discusses.
Duff's device is an unstructured switch() statement, i.e.,
no body. It acts slightly differently from a normal C
switch() with body {} section.
> Prolog-like backtracking?
> Nope.
I'm not familiar with Prolog, so I have no idea what that is.
Clearly, it, like closures, aren't needed within C. Maybe,
they're needed within Forth ... ? Is that why you brought
them up?
Rod Pemberton
--
Scientists now say we'll experience a mini-ice in 2030.
So, I guess we need more global warming today ...
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-07-30 12:40 +0000 |
| Message-ID | <2015Jul30.144041@mips.complang.tuwien.ac.at> |
| In reply to | #40923 |
"Rod Pemberton" <boo@fasdfrewar.cdm> writes:
>On Wed, 29 Jul 2015 03:22:37 -0400, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>
>> "Rod Pemberton" <boo@fasdfrewar.cdm> writes:
>
>>> Yes. Everything an 8-bit microprocessor can do, and the general
>>> purpose instructions of 16-bit processors, can be done directly in
>>> C without needing to use assembly. The only thing missing is a
>>> carry flag and an overflow flag.
>>
>> Yes, these are two things that you cannot express directly in C.
>>
>> Another big restriction of C is that you are limited in the kind
>> of control-flow you can do.
>
>This statement was in regards to threaded code, yes?
>Or, was that meant as a general comment on C's control-flow?
As a general comment. I then gave several examples of what you cannot
do.
>> Threaded code? Not in standard C.
>
>That's not true. I implemented my ITC Forth interpreter in pure
>ANSI C, i.e., no special features. It works the exact same way
>as a Forth interpreter in assembly,
Show me the code, and I'll show you where it's not threaded code.
>> Tail-call optimization? Neither guaranteed nor commonplace
>> (in general, not possible).
>
>That's up to the compiler ...
Not really. The problem comes from the calling convention, and the C
calling conventions have to work for varargs and for calls to
functions without a prototype. So the caller has to remove stuff it
has put on the stack, and that means that
return foo(...);
is implemented as
call foo
stack cleanup
ret
i.e., not a tail call. If you turned the CALL into a JMP, the cleanup
would not happen. There are cases where C compilers manage to work
around these problems (e.g., gcc's sibcalls), but in general, it's not
possible.
>> Coroutining? Nope.
>
>That's not true either. Again, it's just more difficult.
>C was designed for a single entry to a procedure, i.e.,
>structured code.
>
>Simon Tathem's coroutines in C:
>http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
That's cute. But that's just calls and returns, not real coroutining.
And it's also restricted to just one function; you cannot use this
technique if the emit() happens in a function called by the top-level
"coroutine". Consider a recursive tree walk as a coroutine; not with
this technique.
>> Prolog-like backtracking?
>> Nope.
>
>I'm not familiar with Prolog, so I have no idea what that is.
>Clearly, it, like closures, aren't needed within C. Maybe,
>they're needed within Forth ... ? Is that why you brought
>them up?
No, I brought them up as examples of things that can be done in
assembly language, but not C. Concerning Prolog, you can point to
wamcc, which shows that it is possible, at some cost, to work around
the limitations of C.
- 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.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-07-30 22:15 -0400 |
| Message-ID | <op.x2l8jxuiyfako5@localhost> |
| In reply to | #40966 |
On Thu, 30 Jul 2015 08:40:41 -0400, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > "Rod Pemberton" <boo@fasdfrewar.cdm> writes: >> On Wed, 29 Jul 2015 03:22:37 -0400, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> "Rod Pemberton" <boo@fasdfrewar.cdm> writes: >>>> Yes. Everything an 8-bit microprocessor can do, and the general >>>> purpose instructions of 16-bit processors, can be done directly in >>>> C without needing to use assembly. The only thing missing is a >>>> carry flag and an overflow flag. >>> >>> Yes, these are two things that you cannot express directly in C. >>> >>> Another big restriction of C is that you are limited in the kind >>> of control-flow you can do. >> >> This statement was in regards to threaded code, yes? >> Or, was that meant as a general comment on C's control-flow? > > As a general comment. I then gave several examples of what you > cannot do. Ok. That answers it. I was wondering if you were calling "threaded code" a type of control-flow or not. >>> Threaded code? Not in standard C. >> >> That's not true. I implemented my ITC Forth interpreter in pure >> ANSI C, i.e., no special features. It works the exact same way >> as a Forth interpreter in assembly, > > Show me the code, No. It's not released. > and I'll show you where it's not threaded code. Funny... But, I seriously doubt that. What is your rationale or presumption for that statement? ... >>> Coroutining? Nope. >> >> That's not true either. Again, it's just more difficult. >> C was designed for a single entry to a procedure, i.e., >> structured code. >> >> Simon Tathem's coroutines in C: >> http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html > > That's cute. But that's just calls and returns, not real coroutining. > And it's also restricted to just one function; you cannot use this > technique if the emit() happens in a function called by the top-level > "coroutine". Consider a recursive tree walk as a coroutine; not with > this technique. I think you may be dismissing the technique too quickly ... IIRC, it's the basis of every threading and coroutine library for C. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-07-30 21:51 -0700 |
| Message-ID | <87y4hxkk04.fsf@jester.gateway.sonic.net> |
| In reply to | #40994 |
"Rod Pemberton" <boo@fasdfrewar.cdm> writes: >>> Simon Tathem's coroutines in C: >>> http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html >>... > I think you may be dismissing the technique too quickly ... > IIRC, it's the basis of every threading and coroutine library for C. Not at all--it's a cute and useful trick, but to properly do coroutines you need multiple stacks. Here's a library using setjmp and a few asm instructions to do that: http://www.embeddedrelated.com/showarticle/455.php I've seen a few others like it but don't feel like searching around for them. For C++ there is Boost::Coroutine which uses Boost::Context to do the stack switch, again using assembly code.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-07-31 10:32 +0000 |
| Message-ID | <2015Jul31.123217@mips.complang.tuwien.ac.at> |
| In reply to | #40994 |
"Rod Pemberton" <boo@fasdfrewar.cdm> writes:
>On Thu, 30 Jul 2015 08:40:41 -0400, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>
>> "Rod Pemberton" <boo@fasdfrewar.cdm> writes:
>>> On Wed, 29 Jul 2015 03:22:37 -0400, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> "Rod Pemberton" <boo@fasdfrewar.cdm> writes:
>
>>>>> Yes. Everything an 8-bit microprocessor can do, and the general
>>>>> purpose instructions of 16-bit processors, can be done directly in
>>>>> C without needing to use assembly. The only thing missing is a
>>>>> carry flag and an overflow flag.
>>>>
>>>> Yes, these are two things that you cannot express directly in C.
>>>>
>>>> Another big restriction of C is that you are limited in the kind
>>>> of control-flow you can do.
>>>
>>> This statement was in regards to threaded code, yes?
>>> Or, was that meant as a general comment on C's control-flow?
>>
>> As a general comment. I then gave several examples of what you
>> cannot do.
>
>Ok. That answers it.
>
>I was wondering if you were calling "threaded code" a type of
>control-flow or not.
Probably depends on context. In this context, I see it as an
application of indirect branches, and indirect branching is not
supported in standard C.
>>>> Threaded code? Not in standard C.
>>>
>>> That's not true. I implemented my ITC Forth interpreter in pure
>>> ANSI C, i.e., no special features. It works the exact same way
>>> as a Forth interpreter in assembly,
>>
>> Show me the code,
>
>No. It's not released.
>
>> and I'll show you where it's not threaded code.
>
>Funny... But, I seriously doubt that.
>
>What is your rationale or presumption for that statement? ...
There is no guaranteed way to perform (just) an indirect branch in
standard C.
>>> Simon Tathem's coroutines in C:
>>> http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
>>
>> That's cute. But that's just calls and returns, not real coroutining.
>> And it's also restricted to just one function; you cannot use this
>> technique if the emit() happens in a function called by the top-level
>> "coroutine". Consider a recursive tree walk as a coroutine; not with
>> this technique.
>
>I think you may be dismissing the technique too quickly ...
>IIRC, it's the basis of every threading and coroutine library for C.
Certainly not. E.g., POSIX threads are not implemented based on this
technique.
- 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.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2015-08-16 02:31 -0400 |
| Message-ID | <l7arsaph0lo16jo1ks9jlkf0n0csld3ch6@4ax.com> |
| In reply to | #40966 |
On Thu, 30 Jul 2015 12:40:41 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > "Rod Pemberton" <boo@fasdfrewar.cdm> writes: > >On Wed, 29 Jul 2015 03:22:37 -0400, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: <snip> > >> Tail-call optimization? Neither guaranteed nor commonplace > >> (in general, not possible). > > > >That's up to the compiler ... > > Not really. The problem comes from the calling convention, and the C > calling conventions have to work for varargs and for calls to > functions without a prototype. So the caller has to remove stuff it > has put on the stack, <snip> Varargs must be caller-cleans, yes, because callee isn't required to use or even be able to use all the arguments of any given call. Nonprototyped no; the standard does not require mismatched calls to a nonprototyped function to work, so callee can just pop (or whatever) the args the caller *must have* passed, and if the calller didn' do that too bad. A middle ground is Win32 stdcall: the linker name is decorated with @n where n is the size in bytes of the argument list; the callee pops n bytes in its RET instruction, and if the caller wasn't compiled to push n bytes it doesn't link (and can't run). This is why standard C requires varargs functions be declared with the ellipsis, unlike pre-standard forms which did usually (try to) make varargs work without a specific (or any) declaration.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-08-16 09:53 +0000 |
| Message-ID | <2015Aug16.115318@mips.complang.tuwien.ac.at> |
| In reply to | #41329 |
David Thompson <dave.thompson2@verizon.net> writes:
>On Thu, 30 Jul 2015 12:40:41 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>> "Rod Pemberton" <boo@fasdfrewar.cdm> writes:
>> >On Wed, 29 Jul 2015 03:22:37 -0400, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
><snip>
>> >> Tail-call optimization? Neither guaranteed nor commonplace
>> >> (in general, not possible).
>> >
>> >That's up to the compiler ...
>>
>> Not really. The problem comes from the calling convention, and the C
>> calling conventions have to work for varargs and for calls to
>> functions without a prototype. So the caller has to remove stuff it
>> has put on the stack, <snip>
>
>Varargs must be caller-cleans, yes, because callee isn't required to
>use or even be able to use all the arguments of any given call.
>
>Nonprototyped no; the standard does not require mismatched calls to a
>nonprototyped function to work, so callee can just pop (or whatever)
>the args the caller *must have* passed, and if the calller didn' do
>that too bad.
...
>This is why standard C requires varargs functions be declared with the
>ellipsis, unlike pre-standard forms which did usually (try to) make
>varargs work without a specific (or any) declaration.
Now most C calling conventions were designed before the C standard,
or, even if designed later, were designed to also work for programs
where varargs functions are called without prototypes (e.g., printf()
without #include <stdio.h>), so they leave the stack cleanup to the
caller not just for varargs functions. Result: very few tail-call
optimization opportunities.
I was wondering if that is true for the AArch64 calling convention,
and found a document for it that I could access
<http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf>,
but did not find the answer there in 10 minutes.
- 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.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | Bernd Linsel <bl1@gmx.com> |
|---|---|
| Date | 2015-07-29 17:50 +0200 |
| Message-ID | <mpasoh$ncd$1@newsreader4.netcologne.de> |
| In reply to | #40884 |
Am 29.07.2015 um 05:47 schrieb Rod Pemberton: > On Tue, 28 Jul 2015 13:22:48 -0400, Bernd Linsel <bl1@gmx.com> wrote: >> Nope. C works fine on machines with huge register sets, a hardware >> call stack, and a frame pointer. You're even better off if it supports >> indexed register-indirect addressing modes. > > Yes. Everything an 8-bit microprocessor can do, and the general > purpose instructions of 16-bit processors, can be done directly in > C without needing to use assembly. The only thing missing is a > carry flag and an overflow flag. > > While it's much easier to implement C on a machine with a hardware > stack, C was implemented on mainframes without them. That's why the > C standards don't require a stack. However, IIRC, it was Dennis > Ritchie who showed in one of his papers that a stack is the easiest > and cleanest way to implement recursion in C, which is required. > > Also, C works fine on machines with few registers. C works best on > microprocessors with addressable 8-bit bytes, contiguous memory, > two's complement arithmetic, a hardware stack, the largest integer > a multiple of the 8-bit byte, and pointers the same size as the > largest integers. The possibility to implement C on a certain processor doesn't automatically imply that this processor is suited well for C. Indeed, the PDP-7 and -11 were, while many contemporary parts weren't. But this may also be the reason why C was created like it is?! > Forth generally likes these too, but needs two stacks to implement > instead of one since it separates the data and control flow stack. > > Integers a multiple of the size of a byte is needed because C maps > every object onto an array of bytes. Pointers the same size as the > largest integer is convenient because of C's lossless type conversions, > i.e., pointer to integer to pointer. C is difficult to implement on > machines with a 16-bit word size, machines where the smallest > addressable unit is much larger than a character in size, machines > where the address pointer is greater in size than the largest integer. > All of these situations require constructing special code, e.g., to > save extra bits for pointer conversions or to extract characters > packed into larger integers. [Power of two] multiples of 8 bit-quantities are common since at least mid-80s, but that doesn't define genericity either. And this suits of course Forth as well as C, Java, Pascal, and so on. Only languages that abstract from machine integer sizes, or work with strange basic integers because they're tagging their data are above that [Lisp, Smalltalk...]. >> I wouldn't call that a "generic microprocessor". Look at the (vain) >> efforts to implement C on the 1980's common processors (8080/5, 8086, >> ...). Motorolas 68K was the first part decently usable for C. > > While it seems you're familiar with some stuff from the 1980's, it > seems you forgot about Ron Cain's SmallC. It was originally written > for the Intel 8080 and also ported to PDP-11. If it can run on 8080, > it can run on all other 8-bits. IIRC, the code emitted by the 8086 > port needed only *two* registers. I'd suspect it needed a few more > on the 8080. 8080 and 8086 were even in their time regarded as register-starved. And, as I stated above, the possibility of realizing a decent C compiler on these platforms doesn't define them as well-suited for C. Btw, the top performer for the '86 was Watcom C, still used today for x86-based embedded parts. >>>> Forth, instead, usually attempts to impose it's own virtual machine. >> >> Forth runs perfectly on stack machines, e.g. RTX 2000. > > The RTX 2000 was a dedicated Forth processor. Why would you need to > implement a virtual machine for it? ... > > More commonly, when Forth is implemented on a generic processor, > Forth is implemented as an interpreter which uses a virtual machine. > Specifically, it uses a virtual processor, generally with registers > W, IP, PSP, RSP, UP, and/or X, and/or TOS. At least W, IP, PSP, and RSP are needed. But you can do with a bunch less, see Rodriguez' CamelForth for 8051... On the other hand, optimal prerequisites for (a classic, interpreted) Forth are: >= 8 gp registers, predecrementing and postincrementing indirect addressing modes, at its best with an additional immediate and/or register offset, register- and memory-indirect jumps... Everything that makes up CISC in contrast to RISC's load-store philosophy. And, not to forget, a unified cache instead Von Neumann architecture would help. Naturally, you don't need everything of that. Then, however, you have to make compromises here or there. > If you're interested in > this, you can read Bradford J. Rodriguez's Forth code for various > 8-bit processors: > > Bradford J. Rodriguez, PHD > http://www.bradrodriguez.com/papers/ > > However, I'd assume that if you're familiar with Koopman then > you're likely familiar with Rodriguez. Certainly. > >> You should read Philip J. Koopman, Jr's publications: >> http://users.ece.cmu.edu/~koopman/stack_computers/ > > I'm quite familiar with some of his work, including portions of his > book, since I consulted it for my Forth interpreter, e.g., instruction > set frequencies and similar papers by Anton Ertl's too. These (Koopman, Rodriguez, Ertl & Co) are apperently the most familiar papers for anyone who wants to develop an optimizing Forth compiler. -- Best regards Bernd Linsel
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-07-30 13:14 +0000 |
| Message-ID | <2015Jul30.151405@mips.complang.tuwien.ac.at> |
| In reply to | #40905 |
Bernd Linsel <bl1@gmx.com> writes:
>The possibility to implement C on a certain processor doesn't
>automatically imply that this processor is suited well for C.
>Indeed, the PDP-7 and -11 were, while many contemporary parts weren't.
Actually Thompson and Ritchie implemented B for the PDP-7 (a
word-addressed machine). When they got a PDP-11, they extended it
with types in order to make use of the byte addressing feature of the
hardware, resulting in C.
- 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.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-07-29 10:28 +0000 |
| Message-ID | <2015Jul29.122836@mips.complang.tuwien.ac.at> |
| In reply to | #40875 |
Bernd Linsel <bl1@gmx.com> writes:
>After having implemented several Forth VMs and native compilers on MIPS
>and ARM embedded systems, I may remark that Forth on RISC machines tends
>to be rather clumsy, regarding load delay slots, missing diplaced
>indirect addressing, and so on.
>You have to optimize very carefully if you want to have a stall-free
>running Forth on a RISC.
>(Not even to mention cache thrashing and similar effects that nowadays
>also CISC processors suffer from if you're mixing code and data).
>
>An optimizing native compiler gains of course performance of a large
>register set, if you analyze the data flow on the stack and map it on
>the registers, eliminating nearly all DUPs, SWAPs, DROPs etc (with the
>exception that the stack/register mapping must be consistent on all
>junction points).
Inlining is also important, because otherwise calls and returns are
the most frequent control-flow operation and, more importantly the
most common register allocation boundary, which makes the large
register set and all the sophistication you mention above much less
effective; alternatively, interprocedural register allocation, but
that is harder and probably less effective.
>RISC is in my opinion just muscles without the brain; raw force without
>any sophistication.
The idea in RISC originally was that you design the architecture
together with the compiler (or at least with a view to what compilers
can do and actually do); so I guess the brains are then in the compiler.
>If directed (programmed) accurately, you may achieve
>great performance -- if not, you can fail epically.
Actually, the RISC-specific performance issues like branch or load
delay slots cannot produce epic wins or epic fails; the numbers I
remember are on the order of 10%.
Other things, like good register allocation, is also important on
CISCs. And combining several Forth words into instructions may be
more important on CISCs than on RISCs; e.g. "cells + @ +" can (and
probably should) be combined into one instruction on IA-32 and AMD64,
whereas translating each word into one instruction does not miss any
optimization opportunity on MIPS.
By contrast, avoiding cache misses can have a much bigger effect, but
caches are not RISC-specific. Indeed, the problem with mixing code
and data is, in a way, CISC-specific; not because of RISC design
principles, but because separate I and D caches were introduced at
about the same time as RISCs, so RISC architectures were designed for
them (and required that software synchronizes the caches explicitly),
whereas older (CISC) architectures did the synchonization in hardware,
sometimes more often than necessary, at a steep cost.
The overall design principle of general-purpose hardware has been to
make the common case fast. Another design principle is to make some
case very fast, and to leave it to software to make that case common;
this design principle is most common in supercomputing, but
occasionally hardware designers try to apply it elsewhere, mostly
unsuccessfully (e.g., IA-64 and the Cell architecture in PS3).
- 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.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | Bernd Linsel <bl1@gmx.com> |
|---|---|
| Date | 2015-07-29 18:24 +0200 |
| Message-ID | <mpaumt$opj$1@newsreader4.netcologne.de> |
| In reply to | #40893 |
Am 29.07.2015 um 12:28 schrieb Anton Ertl:> Bernd Linsel <bl1@gmx.com> writes: >> After having implemented several Forth VMs and native compilers on MIPS >> and ARM embedded systems, I may remark that Forth on RISC machines tends >> to be rather clumsy, regarding load delay slots, missing diplaced >> indirect addressing, and so on. >> You have to optimize very carefully if you want to have a stall-free >> running Forth on a RISC. >> (Not even to mention cache thrashing and similar effects that nowadays >> also CISC processors suffer from if you're mixing code and data). >> >> An optimizing native compiler gains of course performance of a large >> register set, if you analyze the data flow on the stack and map it on >> the registers, eliminating nearly all DUPs, SWAPs, DROPs etc (with the >> exception that the stack/register mapping must be consistent on all >> junction points). > > Inlining is also important, because otherwise calls and returns are > the most frequent control-flow operation and, more importantly the > most common register allocation boundary, which makes the large > register set and all the sophistication you mention above much less > effective; alternatively, interprocedural register allocation, but > that is harder and probably less effective. It's not just inlining, it's better to recompile (constraining the dictionary to its state at definition time of the 'inlined' word, otherwise you would produce "evaluate-macros"), because only then junction points are eliminated and the stack/register mapping at compile time unfolds its full power. So you save the efforts for indeed mostly not very effective and complex interprocedural register allocation, and achieve nice performance though. >> RISC is in my opinion just muscles without the brain; raw force without >> any sophistication. > > The idea in RISC originally was that you design the architecture > together with the compiler (or at least with a view to what compilers > can do and actually do); so I guess the brains are then in the compiler. Okay, but they designed mostly C-compilers, not Forths. And today it is common sense that the end-of-80s' goal of leaving the hard job of optimizing to the compiler has failed, or at least, hasn't been reached until today. But in the meantime we have undoubtedly learned a lot about compilation, program and data flow analysis, and code generation. >> If directed (programmed) accurately, you may achieve >> great performance -- if not, you can fail epically. > > Actually, the RISC-specific performance issues like branch or load > delay slots cannot produce epic wins or epic fails; the numbers I > remember are on the order of 10%. My own experience was at about 50%, when placed at the most crucial positions in a Forth interpreter: NEXT, DOCOL, SEMI-S. > Other things, like good register allocation, is also important on > CISCs. And combining several Forth words into instructions may be > more important on CISCs than on RISCs; e.g. "cells + @ +" can (and > probably should) be combined into one instruction on IA-32 and AMD64, > whereas translating each word into one instruction does not miss any > optimization opportunity on MIPS. > > By contrast, avoiding cache misses can have a much bigger effect, but > caches are not RISC-specific. Indeed, the problem with mixing code > and data is, in a way, CISC-specific; not because of RISC design > principles, but because separate I and D caches were introduced at > about the same time as RISCs, so RISC architectures were designed for > them (and required that software synchronizes the caches explicitly), > whereas older (CISC) architectures did the synchonization in hardware, > sometimes more often than necessary, at a steep cost. Mixing code and data is just as well expensive on RISCs, because cache synchronization always takes its time, regardless whether initiated from software or hardware. Doing it from software may be a bit more effective, because the programmer knows best when it is appropriate and needed. In both cases the programmer is responsible for avoiding thrashing effects. > The overall design principle of general-purpose hardware has been to > make the common case fast. Another design principle is to make some > case very fast, and to leave it to software to make that case common; > this design principle is most common in supercomputing, but > occasionally hardware designers try to apply it elsewhere, mostly > unsuccessfully (e.g., IA-64 and the Cell architecture in PS3). > > - anton > -- Best regards, Bernd Linsel
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-07-29 17:09 +0000 |
| Message-ID | <2015Jul29.190938@mips.complang.tuwien.ac.at> |
| In reply to | #40906 |
Bernd Linsel <bl1@gmx.com> writes:
>Am 29.07.2015 um 12:28 schrieb Anton Ertl:> Bernd Linsel <bl1@gmx.com>
>writes:
> > Inlining is also important, because otherwise calls and returns are
> > the most frequent control-flow operation and, more importantly the
> > most common register allocation boundary, which makes the large
> > register set and all the sophistication you mention above much less
> > effective; alternatively, interprocedural register allocation, but
> > that is harder and probably less effective.
>
>It's not just inlining, it's better to recompile (constraining the
>dictionary to its state at definition time of the 'inlined' word,
>otherwise you would produce "evaluate-macros"), because only then
>junction points are eliminated and the stack/register mapping at compile
>time unfolds its full power.
Sorry, you lost me here. The first part seems to point out that
source-based inlining is, in general, incorrect; of course that is the
case, and not just because of the state of the dictionary, but also
because of other state. It's not clear to me what the second part is
about. You can read more about how to do inlining in
@InProceedings{gregg&ertl04euroforth,
author = {David Gregg and M. Anton Ertl},
title = {Inlining in {Gforth}: Early Experiences},
booktitle = {EuroForth 2004 Conference Proceedings},
pages = {33--40},
year = {2004},
URL = {http://www.complang.tuwien.ac.at/papers/gregg%26ertl04euroforth.ps.gz},
OPTnote = {not refereed},
abstract = {Many optimizations are easier or more effective for
straight-line code (basic blocks). Straight-line
code in Forth is limited mainly by calls and
returns. Inlining eliminates calls and returns,
which in turn makes the basic blocks longer, and
increases the effectiveness of other
optimizations. In this paper we present a first
prototype implementation of ininlining for Gforth.}
}
> >> RISC is in my opinion just muscles without the brain; raw force without
> >> any sophistication.
> >
> > The idea in RISC originally was that you design the architecture
> > together with the compiler (or at least with a view to what compilers
> > can do and actually do); so I guess the brains are then in the compiler.
>
>Okay, but they designed mostly C-compilers, not Forths.
More like Pascal compilers AFAIK. Anyway, RISCs work nicely for
Forth.
>And today it is common sense that the end-of-80s' goal of leaving the
>hard job of optimizing to the compiler has failed, or at least, hasn't
>been reached until today.
Concerning the typical RISC features, it has succeeded. However, some
of the features, in particular architectural delay slots, were found
to be inappropriate for subsequent hardware generations. Having many
registers and a load/store architecture is still beneficial, although
the advantage of RISCs has dwindled as more transistors became
available. Where transistors are still an issue (e.g., for power
reasons), RISCs (in the form of ARM) still prevails.
> >> If directed (programmed) accurately, you may achieve
> >> great performance -- if not, you can fail epically.
> >
> > Actually, the RISC-specific performance issues like branch or load
> > delay slots cannot produce epic wins or epic fails; the numbers I
> > remember are on the order of 10%.
>
>My own experience was at about 50%, when placed at the most crucial
>positions in a Forth interpreter: NEXT, DOCOL, SEMI-S.
When you do it by hand, it's pretty easy to get close to optimal
performance for these. And when you let GCC at it (as we did in
Gforth), it was also pretty easy.
> > By contrast, avoiding cache misses can have a much bigger effect, but
> > caches are not RISC-specific. Indeed, the problem with mixing code
> > and data is, in a way, CISC-specific; not because of RISC design
> > principles, but because separate I and D caches were introduced at
> > about the same time as RISCs, so RISC architectures were designed for
> > them (and required that software synchronizes the caches explicitly),
> > whereas older (CISC) architectures did the synchonization in hardware,
> > sometimes more often than necessary, at a steep cost.
>
>Mixing code and data is just as well expensive on RISCs, because cache
>synchronization always takes its time, regardless whether initiated from
>software or hardware.
Just because you have code close to data, you don't need to
synchronize the caches. So on architectures that require software
synchronization, you only synchronize when you first generate the
code, but not later. In contrast, on architectures with hardware
synchronization, the hardware synchronizes whenever there is a write
to (on some hardware even a read from) a cache line followed by a code
execution from the same cache line (but different bytes). And that
has led to a slowdown by a factor of 8 of bigForth compared to Gforth
on one benchmark.
- 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.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | Bernd Linsel <bl1@gmx.com> |
|---|---|
| Date | 2015-07-30 02:01 +0200 |
| Message-ID | <mpbpgm$cf8$1@newsreader4.netcologne.de> |
| In reply to | #40913 |
On 29/07/2015 19:09, Anton Ertl wrote: > > Sorry, you lost me here. The first part seems to point out that > source-based inlining is, in general, incorrect; of course that is the > case, and not just because of the state of the dictionary, but also > because of other state. It's not clear to me what the second part is > about. You can read more about how to do inlining in > [snip] thank you, I know most of your publications regarding Forth. I suppose I didn't express it clearly. Of course is source-based inlining wrong. I wanted to point out that on the other side, compiled and fully optimized native machine code isn't suitable for inlining either. You have to keep an intermediate representation, e.g. the classic threaded Forth compilation result, otherwise you cannot benefit from eliminating junction points entering and leaving the inlined word. >>>> RISC is in my opinion just muscles without the brain; raw force without >>>> any sophistication. >>> >>> The idea in RISC originally was that you design the architecture >>> together with the compiler (or at least with a view to what compilers >>> can do and actually do); so I guess the brains are then in the compiler. >> >> Okay, but they designed mostly C-compilers, not Forths. > > More like Pascal compilers AFAIK. Anyway, RISCs work nicely for > Forth. > >> And today it is common sense that the end-of-80s' goal of leaving the >> hard job of optimizing to the compiler has failed, or at least, hasn't >> been reached until today. > > Concerning the typical RISC features, it has succeeded. However, some > of the features, in particular architectural delay slots, were found > to be inappropriate for subsequent hardware generations. Having many > registers and a load/store architecture is still beneficial, although > the advantage of RISCs has dwindled as more transistors became > available. Where transistors are still an issue (e.g., for power > reasons), RISCs (in the form of ARM) still prevails. > That's actually true. >>>> If directed (programmed) accurately, you may achieve >>>> great performance -- if not, you can fail epically. >>> >>> Actually, the RISC-specific performance issues like branch or load >>> delay slots cannot produce epic wins or epic fails; the numbers I >>> remember are on the order of 10%. >> >> My own experience was at about 50%, when placed at the most crucial >> positions in a Forth interpreter: NEXT, DOCOL, SEMI-S. > > When you do it by hand, it's pretty easy to get close to optimal > performance for these. And when you let GCC at it (as we did in > Gforth), it was also pretty easy. > You haven't apparently seen what I've already encountered, what some vendors call e.g. 'MIPS R4000 targeting compiler'. Could probably work for a DLX, but never in the 'real world' (and yes, they accounted for jump delays, generally stuffing a NOP in). >>> By contrast, avoiding cache misses can have a much bigger effect, but >>> caches are not RISC-specific. Indeed, the problem with mixing code >>> and data is, in a way, CISC-specific; not because of RISC design >>> principles, but because separate I and D caches were introduced at >>> about the same time as RISCs, so RISC architectures were designed for >>> them (and required that software synchronizes the caches explicitly), >>> whereas older (CISC) architectures did the synchonization in hardware, >>> sometimes more often than necessary, at a steep cost. >> >> Mixing code and data is just as well expensive on RISCs, because cache >> synchronization always takes its time, regardless whether initiated from >> software or hardware. > > Just because you have code close to data, you don't need to > synchronize the caches. So on architectures that require software > synchronization, you only synchronize when you first generate the > code, but not later. In contrast, on architectures with hardware > synchronization, the hardware synchronizes whenever there is a write > to (on some hardware even a read from) a cache line followed by a code > execution from the same cache line (but different bytes). And that > has led to a slowdown by a factor of 8 of bigForth compared to Gforth > on one benchmark. > OK, but the simpler approach is just separating code and data. When doing embedded stuff in Flash EEPROM, its almost always required anyway. -- Best regards, Bernd Linsel
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-07-29 17:58 -0700 |
| Message-ID | <1d28a376-1285-4d63-a365-31b9956aa218@googlegroups.com> |
| In reply to | #40928 |
On Wednesday, July 29, 2015 at 5:01:27 PM UTC-7, Bernd Linsel wrote: > ...the simpler approach is just separating code and data. When > doing embedded stuff in Flash EEPROM, its almost always required anyway. The standard should have required that code and data be separate, and provide separate versions of HERE --- such as CHERE and DHERE --- this would also allow code to be compiled without clashing with the data being comma'd. All desktop-computer processors had separate code and data caches in 1994 --- apparently nobody on the ANS-Forth committee knew enough assembly-language to be aware of this --- they were thinking in terms of late-1970s processors such as the PDP-11 that didn't have any cache at all. ANS-Forth came out in 1994, but it appears to be designed for processors of the late 1970s --- the whole thing looked anachronistic in 1994, and it looks even more anachronistic in 2015 --- ANS-Forth should just be discarded as a mistake, and we start over thinking in terms of modern technology.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-07-30 21:26 -0400 |
| Message-ID | <op.x2l599tsyfako5@localhost> |
| In reply to | #40932 |
On Wed, 29 Jul 2015 20:58:51 -0400, <hughaguilar96@gmail.com> wrote: > On Wednesday, July 29, 2015 at 5:01:27 PM UTC-7, Bernd Linsel wrote: >> ...the simpler approach is just separating code and data. When >> doing embedded stuff in Flash EEPROM, its almost always required anyway. > > The standard should have required that code and data be separate, > and provide separate versions of HERE --- such as CHERE and DHERE > --- this would also allow code to be compiled without clashing with > the data being comma'd. OMG! You just _don't_ see it do you? ... I.e., you're recreating C again. Hey, let me know when you've finished with your C language implementation. Sorry, I meant with your Forth clone of C implementation ... Rod Pemberton -- Scientists now say we'll experience a mini-ice in 2030. So, I guess we need more global warming today ...
[toc] | [prev] | [next] | [standalone]
Page 7 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