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 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2015-11-03 18:16 +0000 |
| Message-ID | <5638f9f4$0$23862$e4fe514c@news.xs4all.nl> |
| In reply to | #43171 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >Paul Rubin <no.email@nospam.invalid> writes: >>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. Then there is the problem of linking. It is hard to make the linker do your bidding, to include the 0-$10000 range in the executable elf image at a usable place. Anton has complained about the problems of random changes in the c-compiler. The situation with the unix linker is even worse (a c-compiler at least has to pay some tribute to a standard). >- anton -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-11-04 10:53 +0000 |
| Message-ID | <2015Nov4.115307@mips.complang.tuwien.ac.at> |
| In reply to | #43184 |
Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>Then there is the problem of linking. It is hard to make the
>linker do your bidding, to include the 0-$10000 range in
>the executable elf image at a usable place.
>
>Anton has complained about the problems of random changes
>in the c-compiler. The situation with the unix linker is
>even worse (a c-compiler at least has to pay some tribute to
>a standard).
Yes, we used to use a linker option on PowerPC to get the executable
code in the lower 32MB (IIRC), which was useful for direct-threaded
code, but IIRC that stopped working at some point; we switched to
hybrid direct/indirect threading shortly after, so we no longer needed
that.
- 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 | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2015-11-20 11:13 +0100 |
| Subject | 16-bit Forth for Linux |
| Message-ID | <86si41yo57.fsf_-_@vps34351.public.cloudvps.com> |
| In reply to | #43130 |
Paul Rubin wrote: > 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. I have almost finished a cross compiler which generates a 32-bit x86 Linux ELF binary. I don't think it would be very hard to modify the kernel primitives to use 16-bit operations. By setting vm.mmap_min_addr to 0, it's possible to run the image in the low 64K of virtual memory.
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2015-11-20 15:08 +0000 |
| Subject | Re: 16-bit Forth for Linux |
| Message-ID | <564f3768$0$23784$e4fe514c@news.xs4all.nl> |
| In reply to | #43592 |
Lars Brinkhoff <lars.spam@nocrew.org> writes:
>Paul Rubin wrote:
>> 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.
>I have almost finished a cross compiler which generates a 32-bit x86
>Linux ELF binary. I don't think it would be very hard to modify the
>kernel primitives to use 16-bit operations. By setting vm.mmap_min_addr
>to 0, it's possible to run the image in the low 64K of virtual memory.
My previous mail didn't sink in apparently.
Take ciforth generic system.
Replace lina32.cfg :
--------------------------------------
dnl $Id: lina.cfg,v 5.9 2013/04/27 13:26:12 albert Exp $
dnl Copyright(2000): Albert van der Horst, HCC FIG Holland by GNU Public License
divert(-1)dnl
CONFIGURATION FILE
FOR REGULAR LINUX VERSION
FOR NASM AND GNU as
include(prelude.m4)
define( {_LINUX_N_}, _yes )
define( {_BITS32_}, _yes)
dnl Do not increase to or above 0x80000000
dnl GNU-linux ungracefully mishandles this
dnl Problems have been observed for moderate large values
dnl too. Experience suggests a relation with the
dnl size of the swap space.
dnl 1 Mbyte
dnl define({M4_EM},(0x100000))
dnl 64 Mbyte
define({M4_EM},(0x4000000))
dnl 2 Gbyte
dnl define({M4_EM},(0x80000000))
define( {_TASK_}, _yes)dnl
define( {_ALIGNED_}, _yes)
define( {_THREADS_}, _yes)
dnl define( {_ISO_IN_}, _yes)dnl
dnl define( {_SECURITY_}, _no)dnl
dnl define( {_LOAD_}, _no)dnl
dnl define( {_SOURCEFIELD_}, _no)dnl
define( {_EXTRAFIELD_}, _yes)dnl
include(postlude.m4)dnl
dnl
dnl This only makes sense after the postlude
dnl define({_NEXT},{JMP NEXT})
--------------------------------------
by
lina16.cfg
--------------------------------------
dnl $Id: lina.cfg,v 5.9 2013/04/27 13:26:12 albert Exp $
dnl Copyright(2000): Albert van der Horst, HCC FIG Holland by GNU Public License
divert(-1)dnl
CONFIGURATION FILE
FOR REGULAR LINUX VERSION
FOR NASM AND GNU as
include(prelude.m4)
define( {_LINUX_N_}, _yes )
define( {_BITS16_}, _yes)
dnl Do not increase to or above 0x80000000
dnl GNU-linux ungracefully mishandles this
dnl Problems have been observed for moderate large values
dnl too. Experience suggests a relation with the
dnl size of the swap space.
dnl 1 Mbyte
dnl define({M4_EM},(0x100000))
dnl 64 Mbyte
define({M4_EM},(0x4000000))
dnl 2 Gbyte
dnl define({M4_EM},(0x80000000))
define( {_TASK_}, _yes)dnl
define( {_ALIGNED_}, _yes)
define( {_THREADS_}, _yes)
dnl define( {_ISO_IN_}, _yes)dnl
dnl define( {_SECURITY_}, _no)dnl
dnl define( {_LOAD_}, _no)dnl
dnl define( {_SOURCEFIELD_}, _no)dnl
define( {_EXTRAFIELD_}, _yes)dnl
include(postlude.m4)dnl
dnl
dnl This only makes sense after the postlude
dnl define({_NEXT},{JMP NEXT})
--------------------------------------
That's right the only difference is in the line
define( {_BITS16_}, _yes)
Now say
make ci86.lina16.asm
and you have a nasm assembler file ready for you to tackle the real
problems with running 16 bits on linux.
A piece of the difference file around 2DROP
=========================================
2552c2677
< ALIGN 2
---
> ALIGN 4
2554c2679
< DW 5
---
> DD 5
2556c2681
< ALIGN 2
---
> ALIGN 4
2558,2568c2683,2694
< DW TDROP+HEADSIZE
< DW TDROP+HEADSIZE
< DW 0x0
< DW NIP
< DW N_TDROP
< DW 0
< DW 0
<
< POP AX
< POP AX
< JMP NEXT
---
> DD TDROP+HEADSIZE
> DD TDROP+HEADSIZE
> DD 0x0
> DD NIP
> DD N_TDROP
> DD 0
> DD 0
>
> POP EAX
> POP EAX
> LODSD ; NEXT
> JMP LONG[EAX]
=========================================
Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2015-11-20 20:11 +0100 |
| Subject | Re: 16-bit Forth for Linux |
| Message-ID | <86lh9szdsg.fsf@vps34351.public.cloudvps.com> |
| In reply to | #43595 |
Albert van der Horst wrote: > Lars Brinkhoff wrote: >>Paul Rubin wrote: >>> I'm liking the idea of a Forth that lets you choose the cell size at >>> build time, independently of the hardware. >>I have almost finished a cross compiler which generates a 32-bit x86 >>Linux ELF binary. I don't think it would be very hard to modify the >>kernel primitives to use 16-bit operations. > > My previous mail didn't sink in apparently. No, I missed that. > Now say > make ci86.lina16.asm > and you have a nasm assembler file ready for you to tackle the real > problems with running 16 bits on linux. That's great!
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-11-02 11:10 -0800 |
| Message-ID | <f5be22da-cf04-4cad-b491-731b0bf5ed11@googlegroups.com> |
| In reply to | #43100 |
Paul TI has a free SHA implementation on their website. It's in C But you might be able to port it. http://www.ti.com/tool/sha-256 Also, some MSP430 parts have hardware AES encryption built in to the silicon. Mark
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-02 12:43 -0800 |
| Message-ID | <8737woyvx9.fsf@nightsong.com> |
| In reply to | #43135 |
Mark Wills <markwills1970@gmail.com> writes: > TI has a free SHA implementation on their website. It's in C But you > might be able to port it. http://www.ti.com/tool/sha-256 There's tons of C implementations around and I wrote one myself. It would be cool to have one in Forth. That Launchpad is just so perfect for an interactive Forth system, since it has 128KB of non-volatile FRAM. Avoids most of the headaches of flash vs. RAM. > Also, some MSP430 parts have hardware AES encryption built in to the silicon. The TOTP protocol requires SHA1.
[toc] | [prev] | [next] | [standalone]
| From | Howerd <howerdo@yahoo.co.uk> |
|---|---|
| Date | 2015-11-03 03:05 -0800 |
| Message-ID | <8d5d23f1-aa7b-41b6-a8c5-30bae2f0fb36@googlegroups.com> |
| In reply to | #43142 |
On Monday, 2 November 2015 20:43:15 UTC, Paul Rubin wrote: > Mark Wills <markwillxxxxgmail.com> writes: > > TI has a free SHA implementation on their website. It's in C But you > > might be able to port it. http://www.ti.com/tool/sha-256 > > There's tons of C implementations around and I wrote one myself. It > would be cool to have one in Forth. That Launchpad is just so perfect > for an interactive Forth system, since it has 128KB of non-volatile > FRAM. Avoids most of the headaches of flash vs. RAM. > > > Also, some MSP430 parts have hardware AES encryption built in to the silicon. > > The TOTP protocol requires SHA1. Hi Paul & Mark, This may be as close as we get in Forth to a library - some Forth source code : http://www.inventio.co.uk/SHA-256.f With thanks to Jabari Zakiya and Dick van Oudheusden :-) BTW a Google for SHA-256 "in Forth" got the comp.lang.forth link - three clicks to get to the source code... Best regards, Howerd
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-03 11:11 -0800 |
| Message-ID | <87pozqyk29.fsf@nightsong.com> |
| In reply to | #43163 |
Howerd <howerdo@yahoo.co.uk> writes: > This may be as close as we get in Forth to a library - some Forth > source code : > http://www.inventio.co.uk/SHA-256.f > With thanks to Jabari Zakiya and Dick van Oudheusden :-) Thanks, that might be useful for something someday, so I appreciate the link. But it's for 32-bit x86 and includes a fair amount of x86 assembly code, and it's SHA-256. The application I mentioned requires SHA-1, and the target cpu I had in mind is an MSP430.
[toc] | [prev] | [next] | [standalone]
| From | Howerd <howerdo@yahoo.co.uk> |
|---|---|
| Date | 2015-11-03 03:07 -0800 |
| Message-ID | <78096308-ca4f-4862-b094-4f28d79a9279@googlegroups.com> |
| In reply to | #43142 |
On Monday, 2 November 2015 20:43:15 UTC, Paul Rubin wrote: > Mark Wills <markwillsxxxxxgmail.com> writes: > > TI has a free SHA implementation on their website. It's in C But you > > might be able to port it. http://www.ti.com/tool/sha-256 > > There's tons of C implementations around and I wrote one myself. It > would be cool to have one in Forth. That Launchpad is just so perfect > for an interactive Forth system, since it has 128KB of non-volatile > FRAM. Avoids most of the headaches of flash vs. RAM. > > > Also, some MSP430 parts have hardware AES encryption built in to the silicon. > > The TOTP protocol requires SHA1. Hi Paul, Also SHA1 was easy to find : https://github.com/cthulhuology/sha1.fs Best regards, Howerd
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-03 11:15 -0800 |
| Message-ID | <87lhaeyjwo.fsf@nightsong.com> |
| In reply to | #43164 |
Howerd <howerdo@yahoo.co.uk> writes: > Also SHA1 was easy to find : > https://github.com/cthulhuology/sha1.fs Thanks! This seems to use 32-bit cells, though. Even 64-bit in a few places. I'll look around for a 16-bit implementation before actually writing one. Or if I write one, I'll post it here.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-11-02 12:18 -1000 |
| Message-ID | <Kc2dnf8h4eTcfKrLnZ2dnUU7-RudnZ2d@supernews.com> |
| In reply to | #43100 |
On 11/2/15 12:57 AM, Paul Rubin wrote: > 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. During the smart-card projects that FORTH, Inc. and MPE worked on in the 90's, we standardized on 32-bit Forth implementations, even on processors like the 8051. And we had very tight total memory constraints there, too. It's not as painful as you might think. It's all a matter of making design decisions that optimize for the constraint that's tightest for your particular need. >> 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. We actually coded this and some other crypto functions in the smart card project, but we abandoned the attempt to do them entirely in high level, writing some critical bits in code for each target. 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 | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-11-02 12:07 -1000 |
| Message-ID | <wtmdncmEyNoAQ6rLnZ2dnUU7-UWdnZ2d@supernews.com> |
| In reply to | #43091 |
On 11/1/15 11:44 PM, 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? I really can't think of an occasion when I've wanted to do that, or know anyone who did. Nor, when Forth94 was considering making it "ambiguous" (in public reviews) did we receive any protests or rationales from other people who felt they were losing an entitlement. > 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 ;-). We had quite a lot of experience with this issue over the years, and still maintain a considerable body of code that has to run on both 16-bit and 32-bit targets. The recommended approach is to rigorously use the CELL-words and logically code for the lowest cell-size you actually expect to encounter. This is why, for example, the number conversion words # #S etc. all deal with doubles on the stack. There is a cost on 32-bit targets, of course, but it isn't that great. So long as you avoid dependencies on cell size in this way it's quite easy to test programs intended for 16-bit targets on larger cell size hosts. > 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. Except, of course, for the human brain, which is perfectly capable of coding for a 16-bit target on a 32-bit system. You just abandon any attempt to make assumptions about a cell-size larger than the smallest you want to accommodate. It's really not difficult. 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-02 15:41 -0800 |
| Message-ID | <87y4egx94g.fsf@nightsong.com> |
| In reply to | #43143 |
"Elizabeth D. Rather" <erather@forth.com> writes: > Except, of course, for the human brain, which is perfectly capable of > coding for a 16-bit target on a 32-bit system. You just abandon any > attempt to make assumptions about a cell-size larger than the smallest > you want to accommodate. It's really not difficult. It sounds error prone to me. I couldn't imagine developing such code on a 32-bit system, getting it to work on the 32-bit system following every coding practice that you describe, and then shipping it for use on a 16 bit system without actually testing it on a 16 bit system--or even thinking it had a reasonable chance of passing the 16 bit tests without further debugging. > During the smart-card projects that FORTH, Inc. and MPE worked on in > the 90's, we standardized on 32-bit Forth implementations, even on > processors like the 8051. And we had very tight total memory > constraints there, too. It's not as painful as you might think. That's a reasonable approach if you had a configurable interpreter to start with, or the resources to write a new one. I'd hoped to use something like Mecrisp which on the MSP430 is a pure 16 bit system as is perfectly reasonable. > It's all a matter of making design decisions that optimize for the > constraint that's tightest for your particular need. ... We actually > coded [SHA1] and some other crypto functions in the smart card > project, but we abandoned the attempt to do them entirely in high > level, writing some critical bits in code for each target. The board actually has way more resources than the application needs. There's no speed requirement to speak of (if it takes as much as 1 second to do a SHA1 hash, that's fine), and total amount of data memory needed is probably in the 1 or 2 KB range. The board has 128KB of FRAM that can be shared between code and data.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-11-02 20:27 -1000 |
| Message-ID | <h_adnaZPG91ZzqXLnZ2dnUU7-d-dnZ2d@supernews.com> |
| In reply to | #43148 |
On 11/2/15 1:41 PM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> Except, of course, for the human brain, which is perfectly capable of >> coding for a 16-bit target on a 32-bit system. You just abandon any >> attempt to make assumptions about a cell-size larger than the smallest >> you want to accommodate. It's really not difficult. > > It sounds error prone to me. I couldn't imagine developing such code on > a 32-bit system, getting it to work on the 32-bit system following every > coding practice that you describe, and then shipping it for use on a 16 > bit system without actually testing it on a 16 bit system--or even > thinking it had a reasonable chance of passing the 16 bit tests without > further debugging. Good grief, of course you'd want to test it on a 16-bit system. That would be true even with whatever a C compiler would do. I'd never trust it without testing. I thought you were looking for a more convenient development path, not a way to avoid testing on all the platforms you need to support. >> During the smart-card projects that FORTH, Inc. and MPE worked on in >> the 90's, we standardized on 32-bit Forth implementations, even on >> processors like the 8051. And we had very tight total memory >> constraints there, too. It's not as painful as you might think. > > That's a reasonable approach if you had a configurable interpreter to > start with, or the resources to write a new one. I'd hoped to use > something like Mecrisp which on the MSP430 is a pure 16 bit system as is > perfectly reasonable. We developed a customized Forth kernel to support the project. Using something like Mecrisp on the MSP430 is perfectly reasonable, but you surely would want to test it on that configuration. >> It's all a matter of making design decisions that optimize for the >> constraint that's tightest for your particular need. ... We actually >> coded [SHA1] and some other crypto functions in the smart card >> project, but we abandoned the attempt to do them entirely in high >> level, writing some critical bits in code for each target. > > The board actually has way more resources than the application > needs. There's no speed requirement to speak of (if it takes as much as > 1 second to do a SHA1 hash, that's fine), and total amount of data > memory needed is probably in the 1 or 2 KB range. The board has 128KB > of FRAM that can be shared between code and data. That's certainly encouraging. 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 | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-11-03 11:00 +0000 |
| Message-ID | <563884c0.196799270@news.eternal-september.org> |
| In reply to | #43091 |
On Mon, 02 Nov 2015 01:44:06 -0800, Paul Rubin <no.email@nospam.invalid> 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? There are two problems exposed here 1) The fallacious idea that you are not allowed to tick IF - it's just that the result is ambiguous (unspecified). 2) The result of passing the xt of IF to EXECUTE is unspecified. Within a Forth, there are likely to be range of tools, e.g. LOCATE IF HELP IF SEE IF that require access to the internals of the word. In a Forth that treats an xt as a single point of contact, ticking IF is a useful thing to do. The result of ticking IF may be system-dependent, but system-dependent tools know what to do. Traditionally (or classically, perhaps), an xt is the address of the start of the executable portion of the word. It was done this way to improve the performance of EXECUTE as used in the text interpreter or by children of DEFER. In both ANS and Forth-2012, an xt is an opaque type - the standard does not say what the token for an xt represents. There is nothing to stop a particular implementation's xt being an address somewhere else in a word's header. What matters is that (internally) a system can convert an xt to any address that it needs to convert to. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-11-03 11:28 +0000 |
| Message-ID | <2015Nov3.122800@mips.complang.tuwien.ac.at> |
| In reply to | #43161 |
stephen@mpeforth.com (Stephen Pelc) writes:
>There are two problems exposed here
>1) The fallacious idea that you are not allowed to tick IF - it's
>just that the result is ambiguous (unspecified).
Which means that ' IF is not a standard program. What are you trying
to achieve by twisting words?
- 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 | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-11-03 12:18 +0000 |
| Message-ID | <5638a55e.205149348@news.eternal-september.org> |
| In reply to | #43169 |
On Tue, 03 Nov 2015 11:28:00 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >stephen@mpeforth.com (Stephen Pelc) writes: >>There are two problems exposed here >>1) The fallacious idea that you are not allowed to tick IF - it's >>just that the result is ambiguous (unspecified). > >Which means that ' IF is not a standard program. What are you trying >to achieve by twisting words? There's plenty of usefulness in non-standard programs. I gave three examples that require carnal knowledge of the Forth system. That the Forth 2012 standard does not have the tools to do these things does not mean that such things should not be done. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-11-03 17:03 +0000 |
| Message-ID | <2015Nov3.180326@mips.complang.tuwien.ac.at> |
| In reply to | #43173 |
stephen@mpeforth.com (Stephen Pelc) writes:
>On Tue, 03 Nov 2015 11:28:00 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>stephen@mpeforth.com (Stephen Pelc) writes:
>>>There are two problems exposed here
>>>1) The fallacious idea that you are not allowed to tick IF - it's
>>>just that the result is ambiguous (unspecified).
>>
>>Which means that ' IF is not a standard program. What are you trying
>>to achieve by twisting words?
>
>There's plenty of usefulness in non-standard programs.
Which is a red herring in the context of the present discussion, which
was about the shortcomings of the present standard.
>I gave three
>examples that require carnal knowledge of the Forth system. That
>the Forth 2012 standard does not have the tools to do these things
>does not mean that such things should not be done.
That's a fine attitude when you are a programmer confronted with a
weak standard and have a problem that needs to be solved.
However, when you are a committee member and the discussion is about
the shortcomings of the standard, these examples should inspire you to
work on adding the missing tools to the standard.
- 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 | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-11-03 19:29 +0000 |
| Message-ID | <56390681.17661902@news.eternal-september.org> |
| In reply to | #43182 |
On Tue, 03 Nov 2015 17:03:26 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >>There's plenty of usefulness in non-standard programs. > >Which is a red herring in the context of the present discussion, which >was about the shortcomings of the present standard. The three examples illustrate why being able to ' IF is useful. I have publicly stated before that it is useful to be able to tick all words that have a header. >>I gave three >>examples that require carnal knowledge of the Forth system. That >>the Forth 2012 standard does not have the tools to do these things >>does not mean that such things should not be done. > >That's a fine attitude when you are a programmer confronted with a >weak standard and have a problem that needs to be solved. > >However, when you are a committee member and the discussion is about >the shortcomings of the standard, these examples should inspire you to >work on adding the missing tools to the standard. A starting point is to acknowledge that ' and friends are used for purposes other than EXECUTE and COMPILE, - your refusal to accept this is itself a weakness in the standard process. You are very fond of pointing out other people's mistakes - please consider being a bit more humble in accepting your own. My view of mistakes is that if you don't make any, you aren't working hard enough. You should also realise that the tools being discussed have existed in many Forth systems for 20-30 years and more. They have *always* been non-standard. I'm not interested in micro-managing the Forth kernel, except where I consider the standard to be broken. What interests me now is mostly library management. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
Page 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
Back to top | Article view | comp.lang.forth
csiph-web