Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #42092 > unrolled thread
| Started by | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| First post | 2015-09-20 08:45 +0000 |
| Last post | 2015-11-09 13:21 -0800 |
| Articles | 20 on this page of 191 — 29 participants |
Back to article view | Back to comp.lang.forth
EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-20 08:45 +0000
Re: EuroForth 2015 paper deadline approaching Matthias Trute <matthias.trute@gmail.com> - 2015-09-20 06:34 -0700
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-21 20:11 +0200
Re: EuroForth 2015 paper deadline approaching Matthias Trute <matthias.trute@gmail.com> - 2015-09-23 11:29 -0700
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-23 21:03 +0200
Re: EuroForth 2015 paper deadline approaching Matthias Trute <matthias.trute@gmail.com> - 2015-09-27 03:02 -0700
Re: EuroForth 2015 paper deadline approaching Mark Wills <markwills1970@gmail.com> - 2015-09-21 01:13 -0700
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-21 09:26 +0000
Re: EuroForth 2015 paper deadline approaching JUERGEN <epldfpga@aol.com> - 2015-10-03 03:46 -0700
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-10-03 22:56 -0700
Re: EuroForth 2015 paper deadline approaching rickman <gnuarm@gmail.com> - 2015-10-04 02:44 -0400
Re: EuroForth 2015 paper deadline approaching JUERGEN <epldfpga@aol.com> - 2015-10-04 01:14 -0700
Re: EuroForth 2015 paper deadline approaching rickman <gnuarm@gmail.com> - 2015-10-04 05:08 -0400
Re: EuroForth 2015 paper deadline approaching JUERGEN <epldfpga@aol.com> - 2015-10-04 04:06 -0700
Re: EuroForth 2015 paper deadline approaching Richard Owlett <rowlett@cloud85.net> - 2015-10-04 07:25 -0500
Re: EuroForth 2015 paper deadline approaching JUERGEN <epldfpga@aol.com> - 2015-10-04 06:49 -0700
Re: EuroForth 2015 paper deadline approaching Mark Wills <markwills1970@gmail.com> - 2015-10-04 09:21 -0700
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-10-09 13:24 -0700
Re: EuroForth 2015 paper deadline approaching "WJ" <w_a_x_man@yahoo.com> - 2015-10-08 22:18 +0000
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-08 06:59 +0000
Re: EuroForth 2015 paper deadline approaching Mikael Nordman <oh2aun@gmail.com> - 2015-10-08 04:24 -0700
Re: EuroForth 2015 paper deadline approaching Mark Wills <markwills1970@gmail.com> - 2015-10-08 05:08 -0700
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-08 13:57 +0000
Re: EuroForth 2015 paper deadline approaching Mikael Nordman <oh2aun@gmail.com> - 2015-10-08 13:36 -0700
Re: EuroForth 2015 paper deadline approaching "Elizabeth D. Rather" <erather@forth.com> - 2015-10-08 13:50 -1000
Re: EuroForth 2015 paper deadline approaching Jason Damisch <jasondamisch@yahoo.com> - 2015-10-10 12:10 -0700
Re: EuroForth 2015 paper deadline approaching Paul Rubin <no.email@nospam.invalid> - 2015-10-08 18:10 -0700
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-10 14:10 +0000
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-10-10 23:12 -0700
Re: EuroForth 2015 paper deadline approaching visualforth@rocketmail.com - 2015-10-12 10:18 -0700
Re: EuroForth 2015 paper deadline approaching rickman <gnuarm@gmail.com> - 2015-10-12 14:02 -0400
Re: EuroForth 2015 paper deadline approaching "Elizabeth D. Rather" <erather@forth.com> - 2015-10-12 08:03 -1000
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-10-12 14:58 -0700
Re: EuroForth 2015 paper deadline approaching Coos Haak <chforth@hccnet.nl> - 2015-10-13 01:25 +0200
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-10-12 17:38 -0700
Re: EuroForth 2015 paper deadline approaching "Elizabeth D. Rather" <erather@forth.com> - 2015-10-12 16:39 -1000
Re: EuroForth 2015 paper deadline approaching rickman <gnuarm@gmail.com> - 2015-10-10 19:12 -0400
Re: EuroForth 2015 paper deadline approaching JUERGEN <epldfpga@aol.com> - 2015-10-08 07:31 -0700
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-17 22:44 +0200
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-10-17 21:47 -0700
Re: EuroForth 2015 paper deadline approaching rickman <gnuarm@gmail.com> - 2015-10-18 01:51 -0400
Re: EuroForth 2015 paper deadline approaching "Elizabeth D. Rather" <erather@forth.com> - 2015-10-17 20:26 -1000
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-18 21:34 +0200
Re: EuroForth 2015 paper deadline approaching stephen@mpeforth.com (Stephen Pelc) - 2015-10-19 17:00 +0000
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-20 01:51 +0200
Re: EuroForth 2015 paper deadline approaching "Elizabeth D. Rather" <erather@forth.com> - 2015-10-19 16:24 -1000
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-10-20 02:44 -0700
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-20 13:01 +0000
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-10-20 22:59 -0700
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-10-20 23:57 -0700
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-10-21 10:58 -0700
Re: EuroForth 2015 paper deadline approaching krishna.myneni@ccreweb.org - 2015-11-11 14:06 -0800
Re: EuroForth 2015 paper deadline approaching JUERGEN <epldfpga@aol.com> - 2015-11-11 14:48 -0800
Re: EuroForth 2015 paper deadline approaching Paul Rubin <no.email@nospam.invalid> - 2015-11-11 14:59 -0800
Re: EuroForth 2015 paper deadline approaching JUERGEN <epldfpga@aol.com> - 2015-11-12 05:28 -0800
Re: EuroForth 2015 paper deadline approaching Paul Rubin <no.email@nospam.invalid> - 2015-11-12 18:18 -0800
Re: EuroForth 2015 paper deadline approaching krishna.myneni@ccreweb.org - 2015-11-11 15:12 -0800
Re: EuroForth 2015 paper deadline approaching JUERGEN <epldfpga@aol.com> - 2015-11-12 05:35 -0800
Re: EuroForth 2015 paper deadline approaching krishna.myneni@ccreweb.org - 2015-11-12 06:24 -0800
Re: EuroForth 2015 paper deadline approaching Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-12 14:44 +0000
Re: EuroForth 2015 paper deadline approaching Paul Rubin <no.email@nospam.invalid> - 2015-11-11 15:18 -0800
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-20 12:36 +0000
Re: EuroForth 2015 paper deadline approaching JUERGEN <epldfpga@aol.com> - 2015-10-18 12:54 -0700
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-19 02:47 +0200
Re: EuroForth 2015 paper deadline approaching JUERGEN <epldfpga@aol.com> - 2015-10-08 07:24 -0700
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-08 15:10 +0000
Re: EuroForth 2015 paper deadline approaching JUERGEN <epldfpga@aol.com> - 2015-10-08 09:15 -0700
Re: EuroForth 2015 paper deadline approaching "WJ" <w_a_x_man@yahoo.com> - 2015-11-02 20:35 +0000
Re: EuroForth 2015 paper deadline approaching Ilya Tarasov <ilya74.tarasov@gmail.com> - 2015-10-13 17:30 -0700
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-10-13 19:36 -0700
Re: EuroForth 2015 paper deadline approaching lehs <skydda.barnen@gmail.com> - 2015-10-13 23:54 -0700
Re: EuroForth 2015 paper deadline approaching lehs <skydda.barnen@gmail.com> - 2015-10-14 00:04 -0700
Re: EuroForth 2015 paper deadline approaching lehs <skydda.barnen@gmail.com> - 2015-10-14 00:09 -0700
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-14 09:45 +0000
Re: EuroForth 2015 paper deadline approaching Hannu Vuolasaho <vuokkosetae@gmail.com> - 2015-10-14 14:54 +0300
Re: EuroForth 2015 paper deadline approaching Brad Eckert <hwfwguy@gmail.com> - 2015-10-28 10:13 -0700
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-10-28 11:38 -0700
Re: EuroForth 2015 paper deadline approaching Brad Eckert <hwfwguy@gmail.com> - 2015-10-30 22:03 -0700
Re: EuroForth 2015 paper deadline approaching JUERGEN <epldfpga@aol.com> - 2015-10-31 02:10 -0700
Re: EuroForth 2015 paper deadline approaching Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-10-31 02:50 -0700
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-31 18:58 +0100
Re: EuroForth 2015 paper deadline approaching JUERGEN <epldfpga@aol.com> - 2015-10-31 14:18 -0700
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-31 23:43 +0100
Re: EuroForth 2015 paper deadline approaching JUERGEN <epldfpga@aol.com> - 2015-11-07 10:44 -0800
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-07 23:02 +0100
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-10-31 14:48 -0700
Re: EuroForth 2015 paper deadline approaching Mark Wills <markwills1970@gmail.com> - 2015-11-02 01:03 -0800
Re: EuroForth 2015 paper deadline approaching Paul Rubin <no.email@nospam.invalid> - 2015-11-02 01:44 -0800
Re: EuroForth 2015 paper deadline approaching Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-02 01:59 -0800
Re: EuroForth 2015 paper deadline approaching Mark Wills <markwills1970@gmail.com> - 2015-11-02 02:19 -0800
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-11-02 17:32 -0800
Re: EuroForth 2015 paper deadline approaching Mark Wills <markwills1970@gmail.com> - 2015-11-02 02:14 -0800
Re: EuroForth 2015 paper deadline approaching "Elizabeth D. Rather" <erather@forth.com> - 2015-11-02 12:10 -1000
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-11-02 16:45 -0800
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-02 10:26 +0000
Re: EuroForth 2015 paper deadline approaching Paul Rubin <no.email@nospam.invalid> - 2015-11-02 02:57 -0800
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-02 16:06 +0000
Re: EuroForth 2015 paper deadline approaching Paul Rubin <no.email@nospam.invalid> - 2015-11-02 09:36 -0800
Re: EuroForth 2015 paper deadline approaching Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-02 21:18 +0100
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-03 11:56 +0000
Re: EuroForth 2015 paper deadline approaching Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-03 18:16 +0000
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-04 10:53 +0000
16-bit Forth for Linux Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-20 11:13 +0100
Re: 16-bit Forth for Linux Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-20 15:08 +0000
Re: 16-bit Forth for Linux Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-20 20:11 +0100
Re: EuroForth 2015 paper deadline approaching Mark Wills <markwills1970@gmail.com> - 2015-11-02 11:10 -0800
Re: EuroForth 2015 paper deadline approaching Paul Rubin <no.email@nospam.invalid> - 2015-11-02 12:43 -0800
Re: EuroForth 2015 paper deadline approaching Howerd <howerdo@yahoo.co.uk> - 2015-11-03 03:05 -0800
Re: EuroForth 2015 paper deadline approaching Paul Rubin <no.email@nospam.invalid> - 2015-11-03 11:11 -0800
Re: EuroForth 2015 paper deadline approaching Howerd <howerdo@yahoo.co.uk> - 2015-11-03 03:07 -0800
Re: EuroForth 2015 paper deadline approaching Paul Rubin <no.email@nospam.invalid> - 2015-11-03 11:15 -0800
Re: EuroForth 2015 paper deadline approaching "Elizabeth D. Rather" <erather@forth.com> - 2015-11-02 12:18 -1000
Re: EuroForth 2015 paper deadline approaching "Elizabeth D. Rather" <erather@forth.com> - 2015-11-02 12:07 -1000
Re: EuroForth 2015 paper deadline approaching Paul Rubin <no.email@nospam.invalid> - 2015-11-02 15:41 -0800
Re: EuroForth 2015 paper deadline approaching "Elizabeth D. Rather" <erather@forth.com> - 2015-11-02 20:27 -1000
Re: EuroForth 2015 paper deadline approaching stephen@mpeforth.com (Stephen Pelc) - 2015-11-03 11:00 +0000
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-03 11:28 +0000
Re: EuroForth 2015 paper deadline approaching stephen@mpeforth.com (Stephen Pelc) - 2015-11-03 12:18 +0000
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-03 17:03 +0000
Re: EuroForth 2015 paper deadline approaching stephen@mpeforth.com (Stephen Pelc) - 2015-11-03 19:29 +0000
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-04 14:47 +0000
Re: EuroForth 2015 paper deadline approaching "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-11-04 21:15 -0500
Re: EuroForth 2015 paper deadline approaching Coos Haak <chforth@hccnet.nl> - 2015-11-05 03:19 +0100
Re: EuroForth 2015 paper deadline approaching "Elizabeth D. Rather" <erather@forth.com> - 2015-11-04 16:37 -1000
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-11-04 20:54 -0800
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-05 06:32 +0000
Re: EuroForth 2015 paper deadline approaching "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-11-04 21:17 -0500
Re: EuroForth 2015 paper deadline approaching "Elizabeth D. Rather" <erather@forth.com> - 2015-11-04 16:44 -1000
Re: EuroForth 2015 paper deadline approaching Mark Wills <markwills1970@gmail.com> - 2015-11-05 01:24 -0800
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-05 14:50 +0000
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-11-05 12:49 -0800
CMFORTH Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-06 08:43 +0100
Re: EuroForth 2015 paper deadline approaching Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-02 10:46 +0000
Re: EuroForth 2015 paper deadline approaching Mark Wills <markwills1970@gmail.com> - 2015-11-02 05:52 -0800
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-02 14:52 +0000
Re: EuroForth 2015 paper deadline approaching Mark Wills <markwills1970@gmail.com> - 2015-11-02 08:06 -0800
Re: EuroForth 2015 paper deadline approaching Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-02 08:32 -0800
Re: EuroForth 2015 paper deadline approaching Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-02 20:04 +0000
Re: EuroForth 2015 paper deadline approaching Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-02 22:31 -0800
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-11-03 18:49 -0800
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-03 12:24 +0000
Re: EuroForth 2015 paper deadline approaching Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-03 19:45 +0000
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-03 22:30 +0100
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-04 10:42 +0000
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-04 14:08 +0100
Re: EuroForth 2015 paper deadline approaching Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-04 14:07 +0000
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-04 14:34 +0000
Re: EuroForth 2015 paper deadline approaching stephen@mpeforth.com (Stephen Pelc) - 2015-11-04 17:32 +0000
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-05 23:00 +0100
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-06 07:27 +0000
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-06 22:04 +0100
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-07 16:07 +0000
Re: EuroForth 2015 paper deadline approaching Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-04 13:58 +0000
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-04 15:04 +0100
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-04 14:30 +0000
Re: EuroForth 2015 paper deadline approaching Ilya Tarasov <ilya74.tarasov@gmail.com> - 2015-11-04 11:57 -0800
Re: EuroForth 2015 paper deadline approaching "Elizabeth D. Rather" <erather@forth.com> - 2015-11-04 12:06 -1000
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-11-04 14:53 -0800
Re: EuroForth 2015 paper deadline approaching Ilya Tarasov <ilya74.tarasov@gmail.com> - 2015-11-07 14:44 -0800
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-08 00:02 +0100
Re: EuroForth 2015 paper deadline approaching Ilya Tarasov <ilya74.tarasov@gmail.com> - 2015-11-08 15:22 -0800
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-09 01:15 +0100
Re: EuroForth 2015 paper deadline approaching Ilya Tarasov <ilya74.tarasov@gmail.com> - 2015-11-08 17:06 -0800
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-11-08 22:12 -0800
Re: EuroForth 2015 paper deadline approaching Ilya Tarasov <ilya74.tarasov@gmail.com> - 2015-11-10 16:17 -0800
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-11 02:57 +0100
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-11-10 19:56 -0800
Re: EuroForth 2015 paper deadline approaching Ilya Tarasov <ilya74.tarasov@gmail.com> - 2015-11-11 10:13 -0800
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-12 01:53 +0100
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-11-12 09:19 -0800
Re: EuroForth 2015 paper deadline approaching Ilya Tarasov <ilya74.tarasov@gmail.com> - 2015-11-13 17:30 -0800
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-11-14 20:31 -0800
Re: EuroForth 2015 paper deadline approaching Ilya Tarasov <ilya74.tarasov@gmail.com> - 2015-11-15 14:50 -0800
Re: EuroForth 2015 paper deadline approaching Alfred Singlestone <vitonis@gmail.com> - 2015-11-17 05:07 -0800
Re: EuroForth 2015 paper deadline approaching Ilya Tarasov <ilya74.tarasov@gmail.com> - 2015-11-18 22:20 -0800
Re: EuroForth 2015 paper deadline approaching stephen@mpeforth.com (Stephen Pelc) - 2015-11-02 09:27 +0000
Re: EuroForth 2015 paper deadline approaching anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-02 10:51 +0000
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-02 14:37 +0100
Re: EuroForth 2015 paper deadline approaching franck.bensusan@gmail.com - 2015-11-02 23:20 -0800
Re: EuroForth 2015 paper deadline approaching Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-03 10:01 +0000
Re: EuroForth 2015 paper deadline approaching Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-03 02:30 -0800
Re: EuroForth 2015 paper deadline approaching Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-03 18:08 +0000
Re: EuroForth 2015 paper deadline approaching franck.bensusan@gmail.com - 2015-11-03 06:05 -0800
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-03 19:35 +0100
Re: EuroForth 2015 paper deadline approaching franck.bensusan@gmail.com - 2015-11-03 12:27 -0800
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-03 22:37 +0100
Re: EuroForth 2015 paper deadline approaching franck.bensusan@gmail.com - 2015-11-03 14:39 -0800
Re: EuroForth 2015 paper deadline approaching Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-04 14:54 +0100
Re: EuroForth 2015 paper deadline approaching Mark Wills <markwills1970@gmail.com> - 2015-11-04 06:21 -0800
Re: EuroForth 2015 paper deadline approaching hughaguilar96@gmail.com - 2015-10-31 15:00 -0700
Re: EuroForth 2015 paper deadline approaching Brad Eckert <hwfwguy@gmail.com> - 2015-11-09 13:21 -0800
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-10-31 18:58 +0100 |
| Message-ID | <n12vbb$jqe$1@dont-email.me> |
| In reply to | #43028 |
JUERGEN wrote: > But I have to clarify as it seems to be misinterpreted: No, you haven't, and you don't clarify. > I never suggested the vendors dominate Forth. But you see them as two extremes, which pull Forth into two completely different directions. E.g. Anton (I suppose he's clearly part of the "hobbyist" camp, as professor and co-author of a free system) wants to be able to run useful and complex standard programs on a wide variety of systems. That's one extreme, Stephen on the other end wants to have all of his 6 different ARM Cortex M4F floating point libraries stamped as "standard", though some are combined stack and some are separate stack libraries, and nobody successfully wrote a non-trivial program that runs on both variants. > They should be able to take their own business decisions if they want, > including how the product works. I don't see a problem here. If MPE decides that the ARM Cortex M4F needs a non-standard FP library for optimal code which gives a 2% overall performance gain, then they can do that. It's just non-standard and compatibility is not wanted. A standard program will not work with this FP library. > And if both think together to take a > slightly different route - it is for their requirements and Forth as a > language. The overall theme of your suggestion is still "the vendors are doing the right thing, and the rest of the community are idiots". > Even now there are probably 100 variants and nobody knows how much or if > there is any compatibility or wanted. There is a long tail of single-user Forth and Forth-like systems; that's not the community that is participating in the standard effort; some of these non-compatible communities like the Factor one is pretty big. There were three controversial contributions during this meeting: 1 CHARS = 1 (from Anton, coauthor of Gforth), Quotations (from Alex McDonald, maintainer of Win32Forth), and Recognizers (from Matthias Trute, author of amForth). All three Forths are quite popular, and likely each of them has more users than all the paying customers of the vendors - the market for Forth is not that big, the non-market of free systems for hobbyists is a lot bigger. These three suggestions are apparently moving Forth into a direction the vendors need more time to sleep over. So your suggestion is that we should shut up and let the vendors do their nothing, which is moving Forth forward (in time, but not in space) into the right direction? Or did you attent a meeting in a parallel universe, where the vendors were proposing progressive extensions, and the hobbyists did say "wait, wait, stop, we need some few more years to think about that"? The vendors are worried about change, because it may impact especially this customer with the 1.2 million lines of code. I understand why they are worried; on the other hand, this vendor is progressive e.g. in his code generator. But systems like iForth, which is commercial, but pursued much more like a hobbyist endeaver, have an excellent code generator, too. And Gforth will likely get a competitive one in the next years, too, based on Anton's PAF work. > At least with my view the difference would be between one extreme - the > hobbyists to the other extreme - the vendors. I think that view is not only problematic, but missing the point entirely. There are sume people here who better go to the killfile, but for the rest, hobbyists and vendors are sitting at the same table during Forth200x meetings, and not dragging Forth into different directions. The vendors often need a bit more time, because they worry about big legacy codebases. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | JUERGEN <epldfpga@aol.com> |
|---|---|
| Date | 2015-10-31 14:18 -0700 |
| Message-ID | <9797b486-fc73-433c-b27a-0eda18f15e16@googlegroups.com> |
| In reply to | #43048 |
On Saturday, October 31, 2015 at 5:58:09 PM UTC, Bernd Paysan wrote: > JUERGEN wrote: > > > But I have to clarify as it seems to be misinterpreted: > > No, you haven't, and you don't clarify. > > > I never suggested the vendors dominate Forth. > > But you see them as two extremes, which pull Forth into two completely > different directions. E.g. Anton (I suppose he's clearly part of the > "hobbyist" camp, as professor and co-author of a free system) wants to be > able to run useful and complex standard programs on a wide variety of > systems. That's one extreme, Stephen on the other end wants to have all of > his 6 different ARM Cortex M4F floating point libraries stamped as > "standard", though some are combined stack and some are separate stack > libraries, and nobody successfully wrote a non-trivial program that runs on > both variants. > > > They should be able to take their own business decisions if they want, > > including how the product works. > > I don't see a problem here. If MPE decides that the ARM Cortex M4F needs a > non-standard FP library for optimal code which gives a 2% overall > performance gain, then they can do that. It's just non-standard and > compatibility is not wanted. A standard program will not work with this FP > library. > > > And if both think together to take a > > slightly different route - it is for their requirements and Forth as a > > language. > > The overall theme of your suggestion is still "the vendors are doing the > right thing, and the rest of the community are idiots". > > > Even now there are probably 100 variants and nobody knows how much or if > > there is any compatibility or wanted. > > There is a long tail of single-user Forth and Forth-like systems; that's not > the community that is participating in the standard effort; some of these > non-compatible communities like the Factor one is pretty big. > > There were three controversial contributions during this meeting: 1 CHARS = > 1 (from Anton, coauthor of Gforth), Quotations (from Alex McDonald, > maintainer of Win32Forth), and Recognizers (from Matthias Trute, author of > amForth). All three Forths are quite popular, and likely each of them has > more users than all the paying customers of the vendors - the market for > Forth is not that big, the non-market of free systems for hobbyists is a lot > bigger. These three suggestions are apparently moving Forth into a > direction the vendors need more time to sleep over. > > So your suggestion is that we should shut up and let the vendors do their > nothing, which is moving Forth forward (in time, but not in space) into the > right direction? Or did you attent a meeting in a parallel universe, where > the vendors were proposing progressive extensions, and the hobbyists did say > "wait, wait, stop, we need some few more years to think about that"? > > The vendors are worried about change, because it may impact especially this > customer with the 1.2 million lines of code. I understand why they are > worried; on the other hand, this vendor is progressive e.g. in his code > generator. But systems like iForth, which is commercial, but pursued much > more like a hobbyist endeaver, have an excellent code generator, too. And > Gforth will likely get a competitive one in the next years, too, based on > Anton's PAF work. > > > At least with my view the difference would be between one extreme - the > > hobbyists to the other extreme - the vendors. > > I think that view is not only problematic, but missing the point entirely. > There are sume people here who better go to the killfile, but for the rest, > hobbyists and vendors are sitting at the same table during Forth200x > meetings, and not dragging Forth into different directions. The vendors > often need a bit more time, because they worry about big legacy codebases. > > -- > Bernd Paysan > "If you want it done right, you have to do it yourself" > net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* > http://bernd-paysan.de/ The black and white painting you are trying to put is is even worse that last time - reading glasses again. You seem to know only on and off - but i talked about a range from to to make it easier for you - there is an infinite number of steps between them - even more than there are Forthers on this planet. I met Anton here and if you say he is a hobbyist - this is your opinion - notmine , I saw his competence. FP sort out with Stephen - I am not owned be either vendor - but without them Forth would even slip further into the noise. If Stephen wants it as a standard - fine for me. Are there any other packages of the same quality - show your competence here. > The overall theme of your suggestion is still "the vendors are doing the > right thing, and the rest of the community are idiots". Your English has obviously gotten worse over the years as I never said anything similar. > The overall theme of your suggestion is still "the vendors are doing the > right thing, and the rest of the community are idiots". Please go back to how this started - open Google and try to understand the difference between the words right and different. I would not dare to judge who is righter than right. > So your suggestion is that we should shut up You really need to use a better translation programme - this was never said either.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-10-31 23:43 +0100 |
| Message-ID | <n13g1h$rel$1@dont-email.me> |
| In reply to | #43061 |
JUERGEN wrote: > The black and white painting you are trying to put is is even worse that > last time - reading glasses again. You seem to know only on and off Well, I've heard that on Fefe's blog recently, it's a collision between the world view of scientists and hackers and the rest of mankind: For us there is an objective reality, in which "true" and "false" makes sense. For the rest of mankind, apparently, there isn't. We are more than mildly confused with the idea that there isn't. I think you definitely picked the wrong word with "hobbyist": Quite a number of competent people in the Forth community would considder themselves hobbyists, including most of those who do the FOSS stuff, because they are not monetarily compensated for their work. If it's not for money or primarly work-related, it's hobby. As said, even Marcel Hendrix, who's selling his Forth, is not doing that as primary job; he doesn't want much money for his system and he doesn't make much marketing for it. > - but > i talked about a range from to to make it easier for you - there is an > infinite number of steps between them - even more than there are Forthers > on this planet. I met Anton here and if you say he is a hobbyist - this is > your opinion - notmine , I saw his competence. Well, that's one interesting point, you see "hobbyist" as derogative, and it collides with the possibility of being competent. > FP sort out with Stephen - > I am not owned be either vendor - but without them Forth would even slip > further into the noise. If Stephen wants it as a standard - fine for me. > Are there any other packages of the same quality - show your competence > here. > >> The overall theme of your suggestion is still "the vendors are doing the >> right thing, and the rest of the community are idiots". > Your English has obviously gotten worse over the years as I never said > anything similar. You use the term "hobbyists" as if you mean "idiots", and you don't understand that a significant part of the community considders themselves as "hobbyist" or "amateurs" in the dictionary sense of that term, i.e non- professional in the sense of not-for-profit, not in the sense of incompetent. We have a long history of vendors shouting at hobbyists and vice versa, especially in the 1980s, with the Forth Interrest Group on the hobbyist side, and vendors like Forth Inc. (and many others, most of them are no more) on the professional side. This sort of turf war is over, and I don't want you to start it again. That turf war was really bad for Forth. Hobbyists and professionals (both equally competent) get along quite well in the current standard committee, although we sometimes accidently end up on different sides of the tables, and some faint memories of these turf wars show up. Without you knowing that history, my reaction to your comment doesn't make sense to you. >> The overall theme of your suggestion is still "the vendors are doing the >> right thing, and the rest of the community are idiots". > Please go back to how this started - open Google and try to understand the > difference between the words right and different. I would not dare to > judge who is righter than right. I think we have explained why we don't like a pseudo-standard where everybody can do it different, but it is still "right" according to the standard. I want to write a program or library and run it ideally without changes on many Forth systems; that's a standard which actually is useful. That means nailing down things; real things, and nailing down the academic things like 2th complement and 1 CHARS = 1 is just a start to see if that will work. Stephen also really wants such a standard (he just doesn't always realize it), because he wants standard libraries; and the good thing is that such standard libraries will benefit both the vendors camp *and* the FOSS camp. These only will happen if important things are nailed down and not arbitrarily different between systems. This means we either do things the same way (maybe with some abstraction if necessary), or differently, but in the latter case, someone is doing it right, and the others are doing it wrong. Who's right and who's wrong needs to be sorted out in these cases. Not negotiated away, with a "compromise" that you can do it either way. >> So your suggestion is that we should shut up > You really need to use a better translation programme - this was never > said either. I suggest you try to use better words. I just translated what you wrote in words you understand. I suggest you consult Wikipedia about what a hobby is: https://en.wikipedia.org/wiki/Hobby Especially: "By continually participating in a particular hobby, one can acquire substantial skill and knowledge in that area." "While an amateur may be as skilled as a professional, a professional receives compensation while an amateur generally does not." That's the essential difference between hobbyist and vendor: The vendor gets money for his Forth, the hobbyist not. That is why my interpretation of your words is that the non-selling part of the community is in the hobbyist corner... and they are idiots, because you use "hobbyist" as antagonist of competence. And we had that turf war 30 years ago. You give me the worst flashbacks by suggesting to restart this turf war. So do you understand why I don't understand you? And why this distinction into "vendors" and "hobbyists" as the two extremes is a really, really bad way of saying it? -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | JUERGEN <epldfpga@aol.com> |
|---|---|
| Date | 2015-11-07 10:44 -0800 |
| Message-ID | <4e25fb80-031f-490c-b259-1fbbad7621f2@googlegroups.com> |
| In reply to | #43066 |
On Saturday, October 31, 2015 at 10:43:02 PM UTC, Bernd Paysan wrote: > JUERGEN wrote: > > The black and white painting you are trying to put is is even worse that > > last time - reading glasses again. You seem to know only on and off > > Well, I've heard that on Fefe's blog recently, it's a collision between the > world view of scientists and hackers and the rest of mankind: For us there > is an objective reality, in which "true" and "false" makes sense. For the > rest of mankind, apparently, there isn't. We are more than mildly confused > with the idea that there isn't. > > I think you definitely picked the wrong word with "hobbyist": Quite a number > of competent people in the Forth community would considder themselves > hobbyists, including most of those who do the FOSS stuff, because they are > not monetarily compensated for their work. If it's not for money or > primarly work-related, it's hobby. As said, even Marcel Hendrix, who's > selling his Forth, is not doing that as primary job; he doesn't want much > money for his system and he doesn't make much marketing for it. > > > - but > > i talked about a range from to to make it easier for you - there is an > > infinite number of steps between them - even more than there are Forthers > > on this planet. I met Anton here and if you say he is a hobbyist - this is > > your opinion - notmine , I saw his competence. > > Well, that's one interesting point, you see "hobbyist" as derogative, and it > collides with the possibility of being competent. > > > FP sort out with Stephen - > > I am not owned be either vendor - but without them Forth would even slip > > further into the noise. If Stephen wants it as a standard - fine for me. > > Are there any other packages of the same quality - show your competence > > here. > > > >> The overall theme of your suggestion is still "the vendors are doing the > >> right thing, and the rest of the community are idiots". > > Your English has obviously gotten worse over the years as I never said > > anything similar. > > You use the term "hobbyists" as if you mean "idiots", and you don't > understand that a significant part of the community considders themselves as > "hobbyist" or "amateurs" in the dictionary sense of that term, i.e non- > professional in the sense of not-for-profit, not in the sense of > incompetent. > > We have a long history of vendors shouting at hobbyists and vice versa, > especially in the 1980s, with the Forth Interrest Group on the hobbyist > side, and vendors like Forth Inc. (and many others, most of them are no > more) on the professional side. This sort of turf war is over, and I don't > want you to start it again. That turf war was really bad for Forth. > Hobbyists and professionals (both equally competent) get along quite well in > the current standard committee, although we sometimes accidently end up on > different sides of the tables, and some faint memories of these turf wars > show up. > > Without you knowing that history, my reaction to your comment doesn't make > sense to you. > > >> The overall theme of your suggestion is still "the vendors are doing the > >> right thing, and the rest of the community are idiots". > > Please go back to how this started - open Google and try to understand the > > difference between the words right and different. I would not dare to > > judge who is righter than right. > > I think we have explained why we don't like a pseudo-standard where > everybody can do it different, but it is still "right" according to the > standard. I want to write a program or library and run it ideally without > changes on many Forth systems; that's a standard which actually is useful. > That means nailing down things; real things, and nailing down the academic > things like 2th complement and 1 CHARS = 1 is just a start to see if that > will work. Stephen also really wants such a standard (he just doesn't > always realize it), because he wants standard libraries; and the good thing > is that such standard libraries will benefit both the vendors camp *and* the > FOSS camp. These only will happen if important things are nailed down and > not arbitrarily different between systems. > > This means we either do things the same way (maybe with some abstraction if > necessary), or differently, but in the latter case, someone is doing it > right, and the others are doing it wrong. Who's right and who's wrong needs > to be sorted out in these cases. Not negotiated away, with a "compromise" > that you can do it either way. > > >> So your suggestion is that we should shut up > > You really need to use a better translation programme - this was never > > said either. > > I suggest you try to use better words. I just translated what you wrote in > words you understand. I suggest you consult Wikipedia about what a hobby > is: > > https://en.wikipedia.org/wiki/Hobby > > Especially: > > "By continually participating in a particular hobby, one can acquire > substantial skill and knowledge in that area." > > "While an amateur may be as skilled as a professional, a professional > receives compensation while an amateur generally does not." > > That's the essential difference between hobbyist and vendor: The vendor gets > money for his Forth, the hobbyist not. That is why my interpretation of > your words is that the non-selling part of the community is in the hobbyist > corner... and they are idiots, because you use "hobbyist" as antagonist of > competence. And we had that turf war 30 years ago. You give me the worst > flashbacks by suggesting to restart this turf war. > > So do you understand why I don't understand you? And why this distinction > into "vendors" and "hobbyists" as the two extremes is a really, really bad > way of saying it? > > -- > Bernd Paysan > "If you want it done right, you have to do it yourself" > net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* > http://bernd-paysan.de/ Bernd, thanks for this. I makes clear that you attributed value to vendor and hobbyist which i did not - I used them as two extreme options like I could say Vendor - lives of it - not always fun, especially with customers Hobbyist - does it as a hobby - probably for fun - no money involved really. I used them as the extremes with a lot of Fuzzy options between FORTH or NOT - to use your binary starting point view. I never put a value to either, it does definitely not exclude the possibility of the hobbyist with more knowledge compared to the others - always case related. I would put myself as a hobbyist regarding Forth Programming - in contrast to the professional work I do - in many other areas where Forth is not even known or of interest.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-11-07 23:02 +0100 |
| Message-ID | <n1ls8u$62k$1@dont-email.me> |
| In reply to | #43320 |
JUERGEN wrote: > I used them as the extremes with a lot of Fuzzy options between FORTH or > NOT - to use your binary starting point view. The view I'm objecting is "extremes" on a single axis. This is polarizing - and it's not me polarizing, it's you. I just re-formulate what you say in words that make it obvious, which you say is "binary". That's my formulation of what you say, making it obvious what you really said. As said, there had been people who polarized (in the sense of digging trenches between the camps) between hobbyists and vendors. This was bad, we will not repeat it. When you say, "I didn't say that" while you clearly did, I must now object: My starting point is not binary. My starting point is that competence and hobby/professional is mostly unrelated, while you use the word "hobbyist" in a derogative way as if there's a strong correlation. I object this. For me, the axis "hobbyist/professional" and the competence axis are two dimensions to categorize people. I've seen more incompetent professionals and competent hobbyists than the other way round - money attracts people who really don't have that much of a clue, and programming languages as a hobby are so difficult that they drive away the inept, because for them, it's not fun; at most, it's hard work they want to be paid for. So there migth be some weak correlation between the hobbyist/vendor axis and the competence axis, but it's not necessarily the one you think of. It's not that I think "binary", it's that I reject your one-dimensional view. The vendors have to deal with the "stupid" customers, the hobbyists not. We don't need to, it's much more fun to deal with the smart people, and since we didn't take money, we have no obligations. If you misbehave, we simply won't do anything for you. Maybe two dimensions are already too difficult. Doc Brown always says "Marty, you must think four-dimensional!" (one of the running gags ;-). To confuse you some more: Free software is in fact a different business model. Most of the time, however, it's not about money. How can a business be not about money? If you can't answer that question, you won't understand what free software is about. Money is only one axis of what we desire, and our desires are the driving forces to do things. If money is your only desire, you are a poor chap, as you lack the riches of the other dimensions; worse, you don't even know what other riches there are. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-10-31 14:48 -0700 |
| Message-ID | <d021e133-65a4-41bd-8c60-01195c8ca79e@googlegroups.com> |
| In reply to | #43048 |
On Saturday, October 31, 2015 at 10:58:09 AM UTC-7, Bernd Paysan wrote: > There were three controversial contributions during this meeting: > ... Quotations (from Alex McDonald maintainer of Win32Forth) ... You have said that you were "assigned" to do the quotations. I assume that it was Leon Wagner who assigned this task to you. Anyway, you wrote the fake-quotation package which is just :NONAME with some syntactic sugar. You then had Alex McDonald write the RfD for it, rather than have your own name attached to it, despite the fact that it was your assignment and you wrote the code. The only explanation for why you dumped this on Alex McDonald is that you felt ashamed of having faked the code --- you knew that quotations are supposed to have access to the parent function's local variables --- you failed to provide this essential feature. Your quotations are not "controversial." Your quotations can be trivially implemented in ANS-Forth because they use :NONAME that is in ANS-Forth. There was no need to add anything to the Forth-200x standard that wasn't already in ANS-Forth. For the most part, what Leon Wagner wants is for Forth-200x to be exactly the same as ANS-Forth, so he only approves trivial additions that can be written in ANS-Forth without any change being made to ANS-Forth, and he declines to approve any addition that would require SwiftForth to be modified or upgraded in any way. So, where is the controversy? Your quotations meet Leon Wagner's two criteria (#1 that they can be trivially implemented in ANS-Forth, and #2 that they have zero practical value) --- so your quotations are a slam-dunk into Forth-200x --- the only controversial aspect is that I called you a fake and you responded by dumping the assignment on Alex McDonald so that your own name would not be attached to such blatant fakery. Bernd Paysan is upset with Juergen Pintaske's suggestion that Leon Wagner and Stephen Pelc be declared the benevolent dictators of Forth and everybody else be required to bow before them. He would have liked the suggestion a lot better if he had been nominated to be the benevolent dictator! So, here is a suggestion to Juergen. Modify your proposal slightly: Leon Wagner will be the king of the world for 364 days on even-numbered years, Stephen Pelc will be the king of the world for 364 days on odd-numbered years, and Bernd Paysan will be the king of the world on February 29th. If you do this, Bernd will be happy and Forth-200x can march forward into the future without any further complaints from the peasants. :-)
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-11-02 01:03 -0800 |
| Message-ID | <5b6cea81-03f7-4619-b8ec-6e691a2e21bf@googlegroups.com> |
| In reply to | #43048 |
On Saturday, 31 October 2015 17:58:09 UTC, Bernd Paysan wrote: > > There were three controversial contributions during this meeting: 1 CHARS = > 1 (from Anton, coauthor of Gforth), Quotations (from Alex McDonald, > maintainer of Win32Forth), and Recognizers (from Matthias Trute, author of > amForth). All three Forths are quite popular, and likely each of them has > more users than all the paying customers of the vendors - the market for > Forth is not that big, the non-market of free systems for hobbyists is a lot > bigger. These three suggestions are apparently moving Forth into a > direction the vendors need more time to sleep over. > Quotations and recognisers are cool, but IMO it is misguided for the standards committee to be debating whether or not to add them to the langauge. There are *much* more fundamental portability issues to be resolved before adding any new features at all. If I were chairman, my first effort would be to sit the committee down and try (note: try!) to get some consensus on a mission statement for then next, say, five years. IMO, the committe should be concentrating on resolving the current crop of contentious portability issues before adding more features to the language that could potentially add yet more contentious portability issues. The chair should lead. The chair should say "Look, these are the issues that people are complaining about. Dear members of the committee, go away, confer, argue, squabble, hug, make-up, go for a beer together, and table your proposals for fixing these issues. Our timeline is 2020. We are to submit a modified standard in 2020." When ticking IF on a variety of systems leads to different behaviour on all of them, we have a very very serious problem guys. Wake up and smell the coffee. We CANNOT write (all but the most trivial) code in ANS Forth and *guarantee* that it will run on another system. That is a pity. The committee should be directing its efforts to resolving that issue. It will mean that some system owners will need to change their systems *at some point in the future*. So be it. Man up. Make the tough decisions. It *will* be for the better if we can get to a stage where we can write portable code more easily. There has been progress. Some great additions. Words such as COMPILE, are a brilliant step in the right direction. We're actually not that far away - there are just some corner cases, where, in the main, the wooly language of the standard permits different behaviours. The contention appears because people don't want to "break" their systems. I understand. So, set your sights on a *NEW* Forth 2020 standard, the principle purpose of which shall be to maximise the potential for portable code across different systems. I probably sound quite anti-committee. Honestly, I'm not. I fully respect the work you guys have put in for decades, long before I ever showed up, and I do appreciate that it's like herding cats. I take my hats off to you. You're nearly there.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-02 01:44 -0800 |
| Message-ID | <87lhagzqft.fsf@nightsong.com> |
| In reply to | #43087 |
Mark Wills <markwills1970@gmail.com> writes: > When ticking IF on a variety of systems leads to different behaviour > on all of them, we have a very very serious problem guys. Wake up > and smell the coffee. We CANNOT write (all but the most trivial) > code in ANS Forth and *guarantee* that it will run on another system. Are you serious that ticking IF is a frequent enough thing that it presents a real portability problem? It seems to me that one big under-discussed obstacle to Forth portability is not being able to control the cell size. If I write something on a 32-bit system relying on 32-bit arithmetic, I have to totally rewrite it if I want to run it on a 16-bit system, using doubles everywhere and lots more stack juggling. Or conversely, if my ultimate target is a 16-bit embedded device, I don't have any simple way to test and debug the program on my 32- or 64-bit development system. At least with Forth-83, the cell size was specified in the standard ;-). When coding in C, I just have to be careful to declare everything with specific types (int32_t or whatever), and the compiler takes care of generating the right (potentially messy) code for the target. There doesn't seem to be anything like that for Forth.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-11-02 01:59 -0800 |
| Message-ID | <83c105ff-ecf5-44fb-a194-90dd5e20d23f@googlegroups.com> |
| In reply to | #43091 |
luni, 2 noiembrie 2015, 11:44:14 UTC+2, Paul Rubin a scris: > Mark Wills <markwills1970@gmail.com> writes: > > When ticking IF on a variety of systems leads to different behaviour > > on all of them, we have a very very serious problem guys. Wake up > > and smell the coffee. We CANNOT write (all but the most trivial) > > code in ANS Forth and *guarantee* that it will run on another system. > > Are you serious that ticking IF is a frequent enough thing that it > presents a real portability problem? > > It seems to me that one big under-discussed obstacle to Forth > portability is not being able to control the cell size. If I write > something on a 32-bit system relying on 32-bit arithmetic, I have to > totally rewrite it if I want to run it on a 16-bit system, using doubles > everywhere and lots more stack juggling. Or conversely, if my ultimate > target is a 16-bit embedded device, I don't have any simple way to test > and debug the program on my 32- or 64-bit development system. At least > with Forth-83, the cell size was specified in the standard ;-). > > When coding in C, I just have to be careful to declare everything with > specific types (int32_t or whatever), and the compiler takes care of > generating the right (potentially messy) code for the target. There > doesn't seem to be anything like that for Forth. You just cannot have that in Forth, that's the language. A solution is to have a cell size big enough for the worst case - for example 32bit even for a 16bit target. I've done that, a 32bit forth for an 8bit microcontroller (an AVR). Quite interesting and quite efficient too. I have discussed that in an older thread here. My system was almost ans standard, except the fact that I implemented the pictured numeric output as single cell (which was normal because the cell was 32bit - a 64bit pictured numeric output for the poor avr have had been really too much, just for the sake of being standard...) The C has types, and a + can add any sized numbers (well, almost, but usually from 8bit to 32bit or even 64bit - long long). In forth you need different words. + D+ Q+ ...
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-11-02 02:19 -0800 |
| Message-ID | <a3ad663e-7c4d-451b-8a80-acb00c0782e2@googlegroups.com> |
| In reply to | #43094 |
On Monday, 2 November 2015 09:59:21 UTC, Raimond Dragomir wrote: > luni, 2 noiembrie 2015, 11:44:14 UTC+2, Paul Rubin a scris: > > Mark Wills <markwills1970@gmail.com> writes: > > > When ticking IF on a variety of systems leads to different behaviour > > > on all of them, we have a very very serious problem guys. Wake up > > > and smell the coffee. We CANNOT write (all but the most trivial) > > > code in ANS Forth and *guarantee* that it will run on another system. > > > > Are you serious that ticking IF is a frequent enough thing that it > > presents a real portability problem? > > > > It seems to me that one big under-discussed obstacle to Forth > > portability is not being able to control the cell size. If I write > > something on a 32-bit system relying on 32-bit arithmetic, I have to > > totally rewrite it if I want to run it on a 16-bit system, using doubles > > everywhere and lots more stack juggling. Or conversely, if my ultimate > > target is a 16-bit embedded device, I don't have any simple way to test > > and debug the program on my 32- or 64-bit development system. At least > > with Forth-83, the cell size was specified in the standard ;-). > > > > When coding in C, I just have to be careful to declare everything with > > specific types (int32_t or whatever), and the compiler takes care of > > generating the right (potentially messy) code for the target. There > > doesn't seem to be anything like that for Forth. > > You just cannot have that in Forth, that's the language. Yes, since words such as + operate on the native cell size, you're kind of screwed. On my system, + works with 16-bit cells. On an ARM based system, it's 32-bit cells. The only way to fix that is to introduce types: Specific words that operate on specific number of bits, regardless of processor size. Even the Double word-set won't get you there. On my system, doubles are 32-bit (because my CPU is 16-bit) whereas on most Pentium derived systems they are 64-bit. So you would need a new cell size agnostic word set. 8bit+ 16bit+ 32bit+ 32bit+ 64bit+ and the like.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-11-02 17:32 -0800 |
| Message-ID | <19f80f3a-7f0c-45b9-b765-f7a86089e575@googlegroups.com> |
| In reply to | #43094 |
On Monday, November 2, 2015 at 2:59:21 AM UTC-7, Raimond Dragomir wrote: > luni, 2 noiembrie 2015, 11:44:14 UTC+2, Paul Rubin a scris: > > Mark Wills <markwills1970@gmail.com> writes: > > > When ticking IF on a variety of systems leads to different behaviour > > > on all of them, we have a very very serious problem guys. Wake up > > > and smell the coffee. We CANNOT write (all but the most trivial) > > > code in ANS Forth and *guarantee* that it will run on another system. > > > > Are you serious that ticking IF is a frequent enough thing that it > > presents a real portability problem? > > > > It seems to me that one big under-discussed obstacle to Forth > > portability is not being able to control the cell size. If I write > > something on a 32-bit system relying on 32-bit arithmetic, I have to > > totally rewrite it if I want to run it on a 16-bit system, using doubles > > everywhere and lots more stack juggling. Or conversely, if my ultimate > > target is a 16-bit embedded device, I don't have any simple way to test > > and debug the program on my 32- or 64-bit development system. At least > > with Forth-83, the cell size was specified in the standard ;-). > > > > When coding in C, I just have to be careful to declare everything with > > specific types (int32_t or whatever), and the compiler takes care of > > generating the right (potentially messy) code for the target. There > > doesn't seem to be anything like that for Forth. > > You just cannot have that in Forth, that's the language. A solution is to > have a cell size big enough for the worst case - for example 32bit even for > a 16bit target. I've done that, a 32bit forth for an 8bit microcontroller > (an AVR). Quite interesting and quite efficient too. I have discussed that > in an older thread here. My system was almost ans standard, except the > fact that I implemented the pictured numeric output as single cell (which > was normal because the cell was 32bit - a 64bit pictured numeric output > for the poor avr have had been really too much, just for the sake of being > standard...) I think this is a good idea. Your LFTforth can be defined to be 32-bit. The 16-bit processors are fading into obscurity; it is common nowadays to use ARM Cortex even for small applications that could be done on a 16-bit processor. 20 years ago there was a gigantic price difference between 16-bit systems and 32-bit systems, so 32-bit systems were only used when it was really not possible to fit the application into 64KB and/or the data had a range to wide for 16-bit cells --- nowadays a 16-bit micro-controller is not necessarily less expensive than a 32-bit micro-controller --- similarly, a 32-bit desktop-computer is not necessarily less expensive than a 64-bit desktop-computer. In the rare cases in which a 16-bit micro-controller is less expensive than a 32-bit micro-controller, you can run LFTforth on the 16-bit micro-controller and make it act like a 32-bit micro-controller in that it has a 32-bit wide data-stack and works with 32-bit data. OTOH, why do we really need a 32-bit processor in a micro-controller? Most data coming from an ADC or going to a DAC is 16-bit. My understanding of what Raimond is doing, is that he needs a 32-bit processor because the 64KB limitation of 16-bit processors is a problem. This is both for code and for data. A possible solution here, would be to have a multi-core system, with each core being 16-bit. For example, the Stundurd allows 32KB of RAM and 32KB of non-volatile (an upgraded version of the Stundurd could be made that supports 64KB of RAM and 64KB of non-volatile). If each task can get by with this memory limitation, then you are good to go. Rather than have a 32-bit processor with 128KB of RAM and 128KB of non-volatile, you would have a dual-core 16-bit system still with 128KB of RAM and 128KB of non-volatile but not linearly addressed. The big memory hog is TCP/IP --- that can be given its own core. The laser-etcher from Testra used a dual-processor board. It had an 8032 with 64MB of RAM (not a typo: that is 64MB) and it had the MiniForth with 64KW of RAM and 64KW of non-volatile. The 8032 communicated with the desktop-computer by a serial line. It needed so much RAM to hold multiple files of images to be etched. The MiniForth couldn't hold an entire file in RAM, so the 8032 would feed the data to it on-the-fly as it etched the image. Also, the 8032 was needed for helping the MiniForth to get going when the whole system powered up (I called it a "pony processor" because it was like the pony-motor that is used to start up gigantic diesel engines). Back when I interested in Factor, asked Slava if Factor could be made to run on the eZ80. My idea was that the eZ80 could be used for communicating with the desktop-computer via TCP/IP, and the small fast PIC24 could be used for motion-control --- I would write a Forth for the PIC24 system. Unfortunately, Slava said that Factor couldn't run on the eZ80; he said that the ColfFire was the smallest processor he could conceive of Factor running on --- if you are going to have such a big expensive 32-bit processor however, then you might as well make it the only processor on the board and have it do the motion-control too. For the most part, I think that a multi-core 16-bit system is better than a single-core 32-bit system --- with a single-core system you have a complicated mess of interrupts and you can't be totally sure that you will never lose any data --- with a multi-core system each core can be tested in isolation and this pretty much guarantees that they will all work together. > The C has types, and a + can add any sized numbers (well, almost, but > usually from 8bit to 32bit or even 64bit - long long). In forth you > need different words. + D+ Q+ ... I'm opposed to polymorphism in Forth --- Charles Moore said: "Let the dictionary do the deciding." --- it is better to have distinct dictionary entries for + D+ M+ Q+ etc., because they are distinct concepts --- they are related in that they all perform addition, but they are not the same and hence they shouldn't have the same name.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-11-02 02:14 -0800 |
| Message-ID | <99ba13a9-15a0-4beb-ba83-11ea000448c7@googlegroups.com> |
| In reply to | #43091 |
On Monday, 2 November 2015 09:44:14 UTC, Paul Rubin wrote: > Mark Wills <markwills1970@gmail.com> writes: > > When ticking IF on a variety of systems leads to different behaviour > > on all of them, we have a very very serious problem guys. Wake up > > and smell the coffee. We CANNOT write (all but the most trivial) > > code in ANS Forth and *guarantee* that it will run on another system. > > Are you serious that ticking IF is a frequent enough thing that it > presents a real portability problem? > Hi Paul I do agree that it is quite infrequent. Perhaps even very infrequent. However, when three systems give a different behaviour, *and all three systems claim compliance with the standard* then you can't blame the systems. You *have* to blame the standard for providing the wriggle room in the text of the standard. :-)
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-11-02 12:10 -1000 |
| Message-ID | <wtmdnciEyNrCQqrLnZ2dnUU7-UUAAAAA@supernews.com> |
| In reply to | #43096 |
On 11/2/15 12:14 AM, Mark Wills wrote: > On Monday, 2 November 2015 09:44:14 UTC, Paul Rubin wrote: >> Mark Wills <markwills1970@gmail.com> writes: >>> When ticking IF on a variety of systems leads to different behaviour >>> on all of them, we have a very very serious problem guys. Wake up >>> and smell the coffee. We CANNOT write (all but the most trivial) >>> code in ANS Forth and *guarantee* that it will run on another system. >> >> Are you serious that ticking IF is a frequent enough thing that it >> presents a real portability problem? >> > > Hi Paul > > I do agree that it is quite infrequent. Perhaps even very infrequent. > However, when three systems give a different behaviour, *and all three > systems claim compliance with the standard* then you can't blame the > systems. You *have* to blame the standard for providing the wriggle > room in the text of the standard. :-) The standard says, in effect, "don't do that." It's good advice, in this case. 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 | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-11-02 16:45 -0800 |
| Message-ID | <b0cd7f17-65e4-43cc-9084-27b6ce0e638d@googlegroups.com> |
| In reply to | #43144 |
On Monday, November 2, 2015 at 3:10:41 PM UTC-7, Elizabeth D. Rather wrote: > On 11/2/15 12:14 AM, Mark Wills wrote: > > On Monday, 2 November 2015 09:44:14 UTC, Paul Rubin wrote: > >> Mark Wills <markwills1970@gmail.com> writes: > >>> When ticking IF on a variety of systems leads to different behaviour > >>> on all of them, we have a very very serious problem guys. Wake up > >>> and smell the coffee. We CANNOT write (all but the most trivial) > >>> code in ANS Forth and *guarantee* that it will run on another system. > >> > >> Are you serious that ticking IF is a frequent enough thing that it > >> presents a real portability problem? > >> > > > > Hi Paul > > > > I do agree that it is quite infrequent. Perhaps even very infrequent. > > However, when three systems give a different behaviour, *and all three > > systems claim compliance with the standard* then you can't blame the > > systems. You *have* to blame the standard for providing the wriggle > > room in the text of the standard. :-) > > The standard says, in effect, "don't do that." It's good advice, in this > case. > > Cheers, > Elizabeth ANS-Forth makes it "ambiguous" to tick over 50 of the words in the standard (such as IF etc.), in effect saying "don't do that." The only purpose of this bizarre restriction was to prevent ANS-Forth programmers from writing cross-compilers, by preventing them from writing their own custom outer-interpreter --- this is only a benefit to Forth Inc. and MPE who make money by selling cross-compilers and who don't want competition from the peasants. Elizabeth Rather calls this "good advice" --- well, only a fool would take advice from a corporate sales-person!
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-11-02 10:26 +0000 |
| Message-ID | <2015Nov2.112640@mips.complang.tuwien.ac.at> |
| In reply to | #43091 |
Paul Rubin <no.email@nospam.invalid> writes:
>It seems to me that one big under-discussed obstacle to Forth
>portability is not being able to control the cell size. If I write
>something on a 32-bit system relying on 32-bit arithmetic, I have to
>totally rewrite it if I want to run it on a 16-bit system, using doubles
>everywhere and lots more stack juggling. Or conversely, if my ultimate
>target is a 16-bit embedded device, I don't have any simple way to test
>and debug the program on my 32- or 64-bit development system. At least
>with Forth-83, the cell size was specified in the standard ;-).
>
>When coding in C, I just have to be careful to declare everything with
>specific types (int32_t or whatever), and the compiler takes care of
>generating the right (potentially messy) code for the target.
And yet, my experience is that Forth code has much fewer portability
problems between 32-bit and 64-bit platforms than C code (also from
16-bit platforms, but I don't have that much experience with that. So
I think that, wrt portability, the Forth approach is better than the C
approach. And anyway, the C approach is not workable in Forth,
because with a big zoo of integer types, you need type-based
overloading resolution to deal with it, and as the portability
problems show, that alone is not sufficient.
Concerning your problem: If you have values that does not fit in 16
bits, but you want to write a program that ports to 16-bit platforms,
use doubles for these values.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-02 02:57 -0800 |
| Message-ID | <87egg8zn0o.fsf@nightsong.com> |
| In reply to | #43098 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > the C approach is not workable in Forth, because with a big zoo of > integer types, you need type-based overloading resolution I guess it might be ok to treat the additional integer types like floating point, i.e. separate stacks. Or to just implement a 32-bit Forth that runs on the 16-bit target, as Raimond suggested. Hey, now I have an excuse to write a Forth ;-). I guess if it's STC, there's not even much of a bloat problem from the bigger cell size vs the machine word size. > Concerning your problem: If you have values that does not fit in 16 > bits, but you want to write a program that ports to 16-bit platforms, > use doubles for these values. Specifically I want to run the SHA1 hash function in order to use an MSP430 Launchpad (the one with the RTC and LCD) as a TOTP token. SHA1 requires a lot of 32-bit wraparound additions and xors. Doing it all with doubles might or might not work; and I'd much rather debug the code with Gforth and then run it on the target, than deal with debugging on a tiny embedded Forth. And doing it with doubles makes the code a heck of a lot more complicated.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-11-02 16:06 +0000 |
| Message-ID | <2015Nov2.170605@mips.complang.tuwien.ac.at> |
| In reply to | #43100 |
Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> the C approach is not workable in Forth, because with a big zoo of
>> integer types, you need type-based overloading resolution
>
>I guess it might be ok to treat the additional integer types like
>floating point, i.e. separate stacks.
I thought about that, too, when writing my posting, but I don't think
it's a good solution:
- You want to compute with these integers, and combine them with
integers from other integer stacks, so you would have to move them
between stacks quite a bit (in particular, you would have to move
evert literal to the appropriate stack before computation), making
the thing messy. The advantage would be, that, in contrast to C,
you would notice it easily if you forget to move between the right
stacks (whereas in C you have implicit conversion that may show up
as problems when porting).
- The C integer type zoo is extensible; in order to replicate this,
you would beed the ability to introduce new integer stacks, complete
with various operations. You certainly don't want this on your
16-bit system, and probably not elsewhere, either.
Of course, if you do one specific such stack for your application,
that's different, and you need to make your own evaluation.
>> Concerning your problem: If you have values that does not fit in 16
>> bits, but you want to write a program that ports to 16-bit platforms,
>> use doubles for these values.
>
>Specifically I want to run the SHA1 hash function in order to use an
>MSP430 Launchpad (the one with the RTC and LCD) as a TOTP token. SHA1
>requires a lot of 32-bit wraparound additions and xors. Doing it all
>with doubles might or might not work;
You could implement your wrapping 32-bit addition and xor as special
operations on doubles. Or you could do the cutoff to 32 bits only
before those operations where it makes a difference (or just implement
these as 32-bit operations).
>and I'd much rather debug the code
>with Gforth and then run it on the target, than deal with debugging on a
>tiny embedded Forth. And doing it with doubles makes the code a heck of
>a lot more complicated.
Sure, but if you go that way on the 16-bit platform, there is no point
in avoiding it on the 16-bit platform.
Of course, another option is to take Stephen Pelc' advice and use a
small ARM (32-bit) for the job.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-02 09:36 -0800 |
| Message-ID | <877fm0z4jo.fsf@nightsong.com> |
| In reply to | #43125 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >>I guess it might be ok to treat the additional integer types like >>floating point, i.e. separate stacks. > I thought about that, too, when writing my posting, but I don't think > it's a good solution: > - You want to compute with these integers, and combine them with > integers from other integer stacks.... Yes you're right. I'm liking the idea of a Forth that lets you choose the cell size at build time, independently of the hardware. Do you think it would be feasible to modify Gforth for 16 bit cells? I mean for use on Linux, not on a 16 bit target. > You could implement your wrapping 32-bit addition and xor as special > operations on doubles. I guess normal d+ already wraps, and dxor is fairly simple to code, so then there's just a bunch of messiness implementing everything with doubles. > Sure, but if you go that way on the 16-bit platform, there is no point > in avoiding it on the 16-bit platform. True, though I can't help thinking there's some better approach. > Of course, another option is to take Stephen Pelc' advice and use a > small ARM (32-bit) for the job. Well, I've always felt Forth started on 16 bit systems and was always a natural fit. And there is this very nice, fairly cheap (used to be even cheaper), super low power Launchpad board that seems like an almost perfect host for a small Forth enviroment: http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430FR6989.html I don't know of anything comparable with an ARM processor.
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2015-11-02 21:18 +0100 |
| Message-ID | <86oafc17gl.fsf@vps34351.public.cloudvps.com> |
| In reply to | #43130 |
Paul Rubin <no.email@nospam.invalid> writes: > I've always felt Forth started on 16 bit systems and was always a > natural fit. Early versions of Forth also ran on Univac and Burroughs mainframes.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-11-03 11:56 +0000 |
| Message-ID | <2015Nov3.125612@mips.complang.tuwien.ac.at> |
| In reply to | #43130 |
Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>I guess it might be ok to treat the additional integer types like
>>>floating point, i.e. separate stacks.
>> I thought about that, too, when writing my posting, but I don't think
>> it's a good solution:
>> - You want to compute with these integers, and combine them with
>> integers from other integer stacks....
>
>Yes you're right. I'm liking the idea of a Forth that lets you choose
>the cell size at build time, independently of the hardware. Do you
>think it would be feasible to modify Gforth for 16 bit cells? I mean
>for use on Linux, not on a 16 bit target.
Feasible, yes, but not easy: You would have to somehow make do with a
16-bit address space; in particular, the engine code would have to
reside there, or you would have a separate address space for "code
addresses" that is actually a jump table for jumping to the code in a
larger address space. Fitting the image in a 16-bit address space
will require cutting a number of things off. The kernl will probably
fit, but not much more. We used to build 16-bit kernls, but no longer
do.
>> You could implement your wrapping 32-bit addition and xor as special
>> operations on doubles.
>
>I guess normal d+ already wraps, and dxor is fairly simple to code
Yes, if these are the only operations, you can just do them at full
length, and not worry about the bits beyond 32 bits. If there are
other operations, you will have to make them work on the lower 32
bits.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
Back to top | Article view | comp.lang.forth
csiph-web