Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #1242 > unrolled thread
| Started by | gavino <gavcomedy@gmail.com> |
|---|---|
| First post | 2011-04-17 00:34 -0700 |
| Last post | 2011-04-21 18:33 -0700 |
| Articles | 20 on this page of 166 — 22 participants |
Back to article view | Back to comp.lang.forth
made it to page 4 of gforth tutorial gavino <gavcomedy@gmail.com> - 2011-04-17 00:34 -0700
Re: made it to page 4 of gforth tutorial "The Beez'" <hansoft@bigfoot.com> - 2011-04-17 02:29 -0700
Re: made it to page 4 of gforth tutorial alberto pasquale <alberto@hal-pc.org> - 2011-04-18 12:55 -0700
Re: made it to page 4 of gforth tutorial "The Beez'" <hansoft@bigfoot.com> - 2011-04-18 14:45 -0700
Re: made it to page 4 of gforth tutorial Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-19 09:06 +0000
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-18 20:30 -0700
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-18 20:33 -0700
Re: made it to page 4 of gforth tutorial David Kuehling <dvdkhlng@gmx.de> - 2011-04-19 13:04 +0200
Re: made it to page 4 of gforth tutorial mhx@iae.nl (Marcel Hendrix) - 2011-04-19 22:09 +0200
Re: made it to page 4 of gforth tutorial "The Beez'" <hansoft@bigfoot.com> - 2011-04-19 23:40 -0700
Re: made it to page 4 of gforth tutorial mhx@iae.nl (Marcel Hendrix) - 2011-04-20 21:27 +0200
Re: made it to page 4 of gforth tutorial alberto pasquale <alberto@hal-pc.org> - 2011-04-20 14:56 -0700
Re: made it to page 4 of gforth tutorial stephenXXX@mpeforth.com (Stephen Pelc) - 2011-04-20 22:42 +0000
Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-20 22:26 -0700
Re: made it to page 4 of gforth tutorial mhx@iae.nl (Marcel Hendrix) - 2011-04-21 20:51 +0200
Re: made it to page 4 of gforth tutorial Marc Olschok <nobody@nowhere.invalid> - 2011-04-26 16:40 +0000
Re: made it to page 4 of gforth tutorial Bernd Paysan <bernd.paysan@gmx.de> - 2011-04-26 22:23 +0200
Re: made it to page 4 of gforth tutorial Alex McDonald <blog@rivadpm.com> - 2011-04-26 13:34 -0700
Re: made it to page 4 of gforth tutorial anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-27 14:48 +0000
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-21 04:07 -0500
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-21 07:38 -0700
Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-21 08:10 -0700
Re: made it to page 4 of gforth tutorial Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-22 12:35 +0000
Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-22 08:51 -0700
Re: made it to page 4 of gforth tutorial Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-23 10:17 +0000
Re: made it to page 4 of gforth tutorial gavino <gavcomedy@gmail.com> - 2011-04-23 18:05 -0700
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-21 11:16 -0500
Re: made it to page 4 of gforth tutorial anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-23 11:26 +0000
Re: made it to page 4 of gforth tutorial gavino <gavcomedy@gmail.com> - 2011-04-23 18:07 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-24 00:10 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-21 11:38 -0700
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-21 15:13 -0500
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-21 14:07 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-21 15:05 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-21 15:24 -0700
Re: made it to page 4 of gforth tutorial Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-22 12:48 +0000
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-22 10:51 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-21 17:41 -0700
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-21 18:16 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-21 18:58 -0700
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-21 19:49 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-22 00:02 -0700
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-22 06:59 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-23 01:20 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-21 21:11 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-22 00:16 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-22 10:12 -0700
Re: made it to page 4 of gforth tutorial Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2011-04-23 07:38 +0100
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-25 00:05 -0700
Re: made it to page 4 of gforth tutorial Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2011-04-25 13:34 +0100
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-25 08:50 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-25 23:11 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-22 00:18 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-22 10:19 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-25 10:43 -0700
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-25 13:17 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-25 16:32 -0700
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-25 18:21 -0700
Re: made it to page 4 of gforth tutorial Charles G Montgomery <cgm@physics.utoledo.edu> - 2011-04-26 19:36 -0400
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-26 21:05 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-26 23:36 -0700
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-27 08:57 -0700
Re: made it to page 4 of gforth tutorial Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-28 11:53 +0000
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-29 22:21 -0700
Re: made it to page 4 of gforth tutorial Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2011-04-27 17:41 +0100
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-27 09:53 -0700
Re: made it to page 4 of gforth tutorial Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-26 11:39 +0000
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-25 23:22 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-26 17:51 -0700
Re: made it to page 4 of gforth tutorial Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-23 10:33 +0000
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-25 00:48 -0700
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-29 22:24 -0700
Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-22 09:44 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-22 11:36 -0700
Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-22 17:08 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-23 18:11 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-23 00:49 -0700
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-23 03:55 -0500
Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-23 14:47 -0700
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-23 11:12 -0700
Re: made it to page 4 of gforth tutorial Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2011-04-30 16:33 +0100
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-05-01 23:03 -0700
Re: made it to page 4 of gforth tutorial Bernd Paysan <bernd.paysan@gmx.de> - 2011-05-02 22:15 +0200
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-05-02 19:15 -0700
Re: made it to page 4 of gforth tutorial Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2011-05-04 08:14 +0100
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-05-04 00:51 -0700
Re: made it to page 4 of gforth tutorial Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2011-05-04 22:03 +0100
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-30 03:15 -0500
Re: made it to page 4 of gforth tutorial Elizabeth D Rather <erather@forth.com> - 2011-05-01 19:04 -1000
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-27 22:58 -0700
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-28 03:37 -0500
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-28 08:54 -0700
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-28 12:12 -0500
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-28 21:34 -0700
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-29 02:27 -0500
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-29 15:09 -0700
Re: made it to page 4 of gforth tutorial Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-05-02 21:47 -0700
Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-28 10:49 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-28 21:57 -0700
Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-05-03 13:28 -0700
Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-28 11:01 -0700
Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-23 14:02 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-25 07:08 -0700
Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-26 10:47 -0700
Re: made it to page 4 of gforth tutorial Alex McDonald <blog@rivadpm.com> - 2011-04-26 10:58 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-04-27 22:39 -0700
Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-28 10:43 -0700
Re: made it to page 4 of gforth tutorial David Thompson <dave.thompson2@verizon.net> - 2011-05-05 04:39 -0400
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-05-05 04:10 -0500
Re: made it to page 4 of gforth tutorial stephenXXX@mpeforth.com (Stephen Pelc) - 2011-04-23 09:53 +0000
Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-04-23 14:59 -0700
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-23 16:10 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-05-01 23:47 -0700
Re: made it to page 4 of gforth tutorial John Passaniti <john.passaniti@gmail.com> - 2011-05-03 14:23 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-05-04 01:48 -0700
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-05-04 05:23 -0500
Re: made it to page 4 of gforth tutorial John Passaniti <jpassaniti@ashly.com> - 2011-05-04 11:17 -0700
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-05-04 12:03 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-23 23:59 -0700
Re: made it to page 4 of gforth tutorial Paul Rubin <no.email@nospam.invalid> - 2011-05-01 23:48 -0700
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-22 03:22 -0500
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-22 10:28 -0700
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-22 12:37 -0500
Re: made it to page 4 of gforth tutorial David Kuehling <dvdkhlng@gmx.de> - 2011-04-22 20:07 +0200
Re: made it to page 4 of gforth tutorial anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-22 18:55 +0000
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-23 23:25 -0700
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-24 03:27 -0500
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-24 20:20 -0700
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-25 03:24 -0500
Re: made it to page 4 of gforth tutorial Elizabeth D Rather <erather@forth.com> - 2011-04-25 11:55 -1000
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-25 23:45 -0700
Re: made it to page 4 of gforth tutorial Elizabeth D Rather <erather@forth.com> - 2011-04-25 21:49 -1000
Re: made it to page 4 of gforth tutorial Alex McDonald <blog@rivadpm.com> - 2011-04-26 02:39 -0700
Re: made it to page 4 of gforth tutorial Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-04-26 03:19 -0700
Re: made it to page 4 of gforth tutorial anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-26 10:01 +0000
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-23 03:43 -0500
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-23 23:53 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-24 20:27 -0700
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-25 03:35 -0500
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-26 00:20 -0700
Re: made it to page 4 of gforth tutorial Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-26 04:02 -0500
Re: made it to page 4 of gforth tutorial Bernd Paysan <bernd.paysan@gmx.de> - 2011-04-26 22:40 +0200
Re: made it to page 4 of gforth tutorial Alex McDonald <blog@rivadpm.com> - 2011-04-25 14:16 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-25 23:25 -0700
Re: made it to page 4 of gforth tutorial Alex McDonald <blog@rivadpm.com> - 2011-04-26 02:47 -0700
Re: made it to page 4 of gforth tutorial anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-26 10:22 +0000
Re: made it to page 4 of gforth tutorial Alex McDonald <blog@rivadpm.com> - 2011-04-26 10:45 -0700
Re: made it to page 4 of gforth tutorial mhx@iae.nl (Marcel Hendrix) - 2011-04-26 22:19 +0200
Re: made it to page 4 of gforth tutorial mhx@iae.nl (Marcel Hendrix) - 2011-04-27 21:05 +0200
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-22 11:44 -0700
Re: made it to page 4 of gforth tutorial Elizabeth D Rather <erather@forth.com> - 2011-04-22 11:46 -1000
Re: made it to page 4 of gforth tutorial Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2011-04-23 08:02 +0100
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-23 23:46 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-24 01:32 -0700
Re: made it to page 4 of gforth tutorial Elizabeth D Rather <erather@forth.com> - 2011-04-24 08:36 -1000
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-24 19:43 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-24 21:07 -0700
Re: made it to page 4 of gforth tutorial Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-25 11:04 +0000
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-25 23:02 -0700
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-20 18:17 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-21 15:19 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-21 15:27 -0700
Re: made it to page 4 of gforth tutorial gavino <gavcomedy@gmail.com> - 2011-04-21 16:54 -0700
Re: made it to page 4 of gforth tutorial gavino <gavcomedy@gmail.com> - 2011-04-21 17:09 -0700
Re: made it to page 4 of gforth tutorial foxchip <fox@ultratechnology.com> - 2011-04-21 17:57 -0700
Re: made it to page 4 of gforth tutorial BruceMcF <agila61@netscape.net> - 2011-04-21 18:33 -0700
Page 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
| From | Jan Coombs <jan_2011-02@murray-microft.co.uk> |
|---|---|
| Date | 2011-04-30 16:33 +0100 |
| Message-ID | <LtidnbwuSORCtiHQnZ2dnUVZ8qKdnZ2d@brightview.co.uk> |
| In reply to | #1468 |
On 29/04/11 23:09, Paul Rubin wrote: > . . . > I spent a little while with the 8051 manual yesterday and it really is a > pretty neat processor, somewhat more powerful than I expected it to be. > Compared to really tiny controllers like the PIC 10F/12F series, it's > almost a supercomputer ;-). Perhaps it would be more progressive to consider the b16: "Purpose The b16 is intented as small microcontroller, and suitable if you need more processing power than a 8051, but less die space (or gate count) and power consumption." from http://www.jwdt.com/~paysan/b16.html Jan Coombs
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2011-05-01 23:03 -0700 |
| Message-ID | <7x7ha93ah0.fsf@ruckus.brouhaha.com> |
| In reply to | #1597 |
Jan Coombs <jan_2011-02@murray-microft.co.uk> writes: > The b16 is intented as small microcontroller, and suitable if you need > more processing power than a 8051, but less die space (or gate count) > and power consumption." > from http://www.jwdt.com/~paysan/b16.html Thanks, that is interesting, and good to know about if I ever get to build anything with an FPGA. The code for the "small" version is here: http://www.forth-ev.de/repos/b16-small/b16.v I can almost understand some parts of it, without knowing anything about verilog. It would be awesomely instructional to have a heavily commented version that explained what everything does.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2011-05-02 22:15 +0200 |
| Message-ID | <90g398-ttl.ln1@vimes.paysan.nom> |
| In reply to | #1692 |
Paul Rubin wrote: > http://www.forth-ev.de/repos/b16-small/b16.v > > I can almost understand some parts of it, without knowing anything > about > verilog. It would be awesomely instructional to have a heavily > commented version that explained what everything does. What's wrong with the PDF generated from the "real" source, the LyX noweb article? http://www.forth-ev.de/repos/b16-small/b16.pdf This is literate programming, b16.v is just the Verilog part, the "comments" (including schematics) are stripped out before. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2011-05-02 19:15 -0700 |
| Message-ID | <7xbozk1qdv.fsf@ruckus.brouhaha.com> |
| In reply to | #1704 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > http://www.forth-ev.de/repos/b16-small/b16.pdf > This is literate programming, b16.v is just the Verilog part, the > "comments" (including schematics) are stripped out before. Oh thanks, yes, that is a very good article, it's great at explaining the high level architecture. The issue is that I don't know anything about Verilog or hardware design, so it would be interesting to see a very closely annotated source listing that explained everything did. I should probably read a Verilog/VHDL book instead, one of these days.
[toc] | [prev] | [next] | [standalone]
| From | Jan Coombs <jan_2011-02@murray-microft.co.uk> |
|---|---|
| Date | 2011-05-04 08:14 +0100 |
| Message-ID | <a-WdncZsPPhzYV3QnZ2dnUVZ8vmdnZ2d@brightview.co.uk> |
| In reply to | #1692 |
On 02/05/11 07:03, Paul Rubin wrote: > > Thanks, that is interesting, and good to know about if I ever get to > build anything with an FPGA. The code for the "small" version is here: > > http://www.forth-ev.de/repos/b16-small/b16.v > > I can almost understand some parts of it, without knowing anything about > verilog. It would be awesomely instructional to have a heavily > commented version that explained what everything does. I'm also struggling with verilog, and Bernd's code is very terse. When(/if) I complete source code translation to MyHDL there will be a commented source available. For easy comprehension the J1 might be a better starting point. It is a much simpler Novix style processor. The complete and ready to run simulator is just 5 pages of python and has block comments. Docs here: www.excamera.com/sphinx/fpga-j1.html For MyHDL source please email me. (Note MyHDL provides a clock accurate simulator environment, and a route to real hardware via Verilog and VHDL code export. See myhdl.org) Jan Coombs
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2011-05-04 00:51 -0700 |
| Message-ID | <7xy62mvr83.fsf@ruckus.brouhaha.com> |
| In reply to | #1728 |
Jan Coombs <jan_2011-02@murray-microft.co.uk> writes:
> I'm also struggling with verilog, and Bernd's code is very
> terse. When(/if) I complete source code translation to MyHDL there
> will be a commented source available.
> For easy comprehension the J1 might be a better starting point. ...
> www.excamera.com/sphinx/fpga-j1.html
Thanks, this is cool. One thing I wonder is how much functionality is
defined by the verilog language and how much is left to the
compiler/synthesizer. For example, I thought addition in hardware was
done with an adder circuit, of which there are several types giving
space/performance trade-offs. But in verilog, it looks you can just say
"a+b"--how does the synthesizer know what circuit to use? Or in the j16
code, it says:
4'b1101: _st0 = st1 << st0[3:0];
That appears to be interpreting a logical shift instruction, but does it
mean the synthesizer plops a barrel shifter into the fpga? Why is the
return stack pointer 16 bits instead of 5 bits like the data stack
pointer?
> For MyHDL source please email me. (Note MyHDL provides a clock
> accurate simulator environment, and a route to real hardware via
> Verilog and VHDL code export. See myhdl.org)
I've been looking at myhdl a little, also lava
(http://www.raintown.org/lava/).
[toc] | [prev] | [next] | [standalone]
| From | Jan Coombs <jan_2011-02@murray-microft.co.uk> |
|---|---|
| Date | 2011-05-04 22:03 +0100 |
| Message-ID | <WbidnUud4cmDIlzQnZ2dnUVZ8t-dnZ2d@brightview.co.uk> |
| In reply to | #1730 |
On 04/05/11 08:51, Paul Rubin wrote: > . . . >> For easy comprehension the J1 might be a better starting point. ... >> www.excamera.com/sphinx/fpga-j1.html > > Thanks, this is cool. One thing I wonder is how much functionality is > defined by the verilog language and how much is left to the > compiler/synthesizer. For example, I thought addition in hardware was > done with an adder circuit, of which there are several types giving > space/performance trade-offs. But in verilog, it looks you can just say > "a+b"--how does the synthesizer know what circuit to use? Most FPGA's have dedicated carry logic, so this means that there is likely only one optimum solution to the adder requirement. Also, the synthesizer is aware of the target fabric, and where more than one option is available it may use timing or other design constraints to select an optimum solution. > Or in the j16 > code, it says: > > 4'b1101: _st0 = st1<< st0[3:0]; > > That appears to be interpreting a logical shift instruction, but does it > mean the synthesizer plops a barrel shifter into the fpga? Yes, and, like the adder, there will likely be one optimum solution for any given logic fabric. > Why is the > return stack pointer 16 bits instead of 5 bits like the data stack > pointer? The rsp is 5b wide, but the data paths are 16b. I have renamed some of the signal names that confused me, so I suggest: >> For MyHDL source please email me. (Note MyHDL provides a clock >> accurate simulator environment, and a route to real hardware via >> Verilog and VHDL code export. See myhdl.org) > > I've been looking at myhdl a little, also lava > (http://www.raintown.org/lava/). Lava is perhaps the fundamental Chuck Moor approach to FPGA design, I like it, thanks for the link. It is likely impractical for designs of any significant size, and of only novelty value to a novice! Jan Coombs.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-04-30 03:15 -0500 |
| Message-ID | <T-udnROEXP--WCbQnZ2dnUVZ8l6dnZ2d@supernews.com> |
| In reply to | #1468 |
Paul Rubin <no.email@nospam.invalid> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> There's nothing inherently crazy about it: "crazy" has to have a >> context. In this case, it's crazy precisely because it'll stop the >> compiler from statically allocating locals. Programming techniques >> have to be appropriate, and we're talking about a machine with 128-256 >> bytes of RAM and 4-8k of ROM. You can attach external memory, but >> it's relatively slow. > > I see. Yeah, my approach to such processors has basically been to plan > on giving up on C altogether (one reason I got interested in Forth, as > mentioned elsewhere). I now start to understand that it's possible to > use C in a constrained enough way to get that compactness, but it still > seems more like working against C than with it. Indeed. C was designed for programming UNIX, and it's fine for that. > I spent a little while with the 8051 manual yesterday and it really > is a pretty neat processor, somewhat more powerful than I expected > it to be. I really like it, and had a lot of fun programming it. It's not a great Forth target, though, especially if you want multi-tasking. And if you're doing embedded control, you probably do want multi-tasking. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Elizabeth D Rather <erather@forth.com> |
|---|---|
| Date | 2011-05-01 19:04 -1000 |
| Message-ID | <XaWdna6SLK32piPQnZ2dnUVZ_gednZ2d@supernews.com> |
| In reply to | #1599 |
On 4/29/11 10:15 PM, Andrew Haley wrote: > Paul Rubin<no.email@nospam.invalid> wrote: >> Andrew Haley<andrew29@littlepinkcloud.invalid> writes: >>> There's nothing inherently crazy about it: "crazy" has to have a >>> context. In this case, it's crazy precisely because it'll stop the >>> compiler from statically allocating locals. Programming techniques >>> have to be appropriate, and we're talking about a machine with 128-256 >>> bytes of RAM and 4-8k of ROM. You can attach external memory, but >>> it's relatively slow. >> >> I see. Yeah, my approach to such processors has basically been to plan >> on giving up on C altogether (one reason I got interested in Forth, as >> mentioned elsewhere). I now start to understand that it's possible to >> use C in a constrained enough way to get that compactness, but it still >> seems more like working against C than with it. > > Indeed. C was designed for programming UNIX, and it's fine for that. > >> I spent a little while with the 8051 manual yesterday and it really >> is a pretty neat processor, somewhat more powerful than I expected >> it to be. > > I really like it, and had a lot of fun programming it. It's not a > great Forth target, though, especially if you want multi-tasking. And > if you're doing embedded control, you probably do want multi-tasking. All true, but I do know of at least one application on an 8051 (don't know which of the hundreds of variants) with >100 tasks running! 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 | 2011-04-27 22:58 -0700 |
| Message-ID | <7xzknagbno.fsf@ruckus.brouhaha.com> |
| In reply to | #1468 |
BruceMcF <agila61@netscape.net> writes: > SDCC would be another alternative. It can select between stacking all > data and only stacking data for recursive functions, and has a '51 > option to only use the hardware stack for return addresses, using the > first 256 bytes of external memory for data. I've seen some not-so-favorable comments about SDCC but I guess the approach is basically reasonable. I haven't had occasion to program the 8051 but maybe I'll look at the avr-gcc assembly output sometime and see if there's obvious ways to improve it.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-04-28 03:37 -0500 |
| Message-ID | <rsSdnbq4RNunuiTQnZ2dnUVZ7tydnZ2d@supernews.com> |
| In reply to | #1608 |
Paul Rubin <no.email@nospam.invalid> wrote: > BruceMcF <agila61@netscape.net> writes: >> SDCC would be another alternative. It can select between stacking all >> data and only stacking data for recursive functions, and has a '51 >> option to only use the hardware stack for return addresses, using the >> first 256 bytes of external memory for data. > > I've seen some not-so-favorable comments about SDCC but I guess the > approach is basically reasonable. I haven't had occasion to program the > 8051 but maybe I'll look at the avr-gcc assembly output sometime and see > if there's obvious ways to improve it. The 8051 is (was?) a terrific little microcontroller, but it presents some major challenges to implementors of high-level languages. Access to memory other than the 256 bytes of internal RAM is something of an afterthought, and you can forget anything like a frame pointer. For that reason, statically allocating local variables makes perfect sense. Getting Forth to work well on the 8051 is a difficult job. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2011-04-28 08:54 -0700 |
| Message-ID | <7xiptyz801.fsf@ruckus.brouhaha.com> |
| In reply to | #1611 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > The 8051 is (was?) a terrific little microcontroller, but it presents > some major challenges to implementors of high-level languages. Access > to memory other than the 256 bytes of internal RAM is something of an > afterthought, and you can forget anything like a frame pointer. For > that reason, statically allocating local variables makes perfect > sense. It occurs to me that statically allocating locals may be hard to do if the code uses function pointers, say in a dispatch table. Recursion can also be hard to detect, for the same reason. Maybe it's possible to have some pragmas that advise the compiler about what might be running when, to help it with region inference. I wonder if SDCC attempts anything like that. I keep wanting to concoct a Haskell dialect for these tiny microcontrollers, just so I can call it Control-H and let the file extension be a backspace character ;-).
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-04-28 12:12 -0500 |
| Message-ID | <B9SdnUNJKpFpAiTQnZ2dnUVZ8q-dnZ2d@supernews.com> |
| In reply to | #1621 |
Paul Rubin <no.email@nospam.invalid> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> The 8051 is (was?) a terrific little microcontroller, but it presents >> some major challenges to implementors of high-level languages. Access >> to memory other than the 256 bytes of internal RAM is something of an >> afterthought, and you can forget anything like a frame pointer. For >> that reason, statically allocating local variables makes perfect >> sense. > > It occurs to me that statically allocating locals may be hard to do if > the code uses function pointers, say in a dispatch table. Absolutely: do that and your program won't fit. Use a switch, as god and nature intended. :-) > Recursion can also be hard to detect, for the same reason. If you're doing something truly crazy like recursion through function pointers, that's true. But if you do things straightfowardly, where the call graph can be determined at compile time, there really is no big problem. > Maybe it's possible to have some pragmas that advise the compiler > about what might be running when, to help it with region inference. > I wonder if SDCC attempts anything like that. Compilers for these samll systems tend to have tones of pragmas and/or switches that control code generation. > I keep wanting to concoct a Haskell dialect for these tiny > microcontrollers, just so I can call it Control-H and let the file > extension be a backspace character ;-). Excellent! Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2011-04-28 21:34 -0700 |
| Message-ID | <7x62px8ym5.fsf@ruckus.brouhaha.com> |
| In reply to | #1624 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> If you're doing something truly crazy like recursion through function
> pointers, that's true.
I don't see what's so crazy about that. I even do it in Forth:
: times ( xt n -- ) \ run an execution token n times
0 ?do dup execute loop drop ;
: blob ( -- ) ['] foo boo ['] moo 5 times ;
: frob ( -- ) mob ['] blob 4 times ;
In the above example, frob calls times, passing it blob as an xt. Times
calls blob through the xt, and blob calls times again, so it's indirect
recursion through function pointers.
I guess I'm open to hearing that my "times" word isn't really Forth-ish,
but I find it nicer than writing explicit loops.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-04-29 02:27 -0500 |
| Message-ID | <AsidnfjdiZjm9SfQnZ2dnUVZ8umdnZ2d@supernews.com> |
| In reply to | #1637 |
Paul Rubin <no.email@nospam.invalid> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> If you're doing something truly crazy like recursion through function >> pointers, that's true. > > I don't see what's so crazy about that. There's nothing inherently crazy about it: "crazy" has to have a context. In this case, it's crazy precisely because it'll stop the compiler from statically allocating locals. Programming techniques have to be appropriate, and we're talking about a machine with 128-256 bytes of RAM and 4-8k of ROM. You can attach external memory, but it's relatively slow. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2011-04-29 15:09 -0700 |
| Message-ID | <7x7hack8uy.fsf@ruckus.brouhaha.com> |
| In reply to | #1641 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > There's nothing inherently crazy about it: "crazy" has to have a > context. In this case, it's crazy precisely because it'll stop the > compiler from statically allocating locals. Programming techniques > have to be appropriate, and we're talking about a machine with 128-256 > bytes of RAM and 4-8k of ROM. You can attach external memory, but > it's relatively slow. I see. Yeah, my approach to such processors has basically been to plan on giving up on C altogether (one reason I got interested in Forth, as mentioned elsewhere). I now start to understand that it's possible to use C in a constrained enough way to get that compactness, but it still seems more like working against C than with it. It seems to me that one has to also be careful with data pointers, e.g. setting them to null when their contents are no longer useful, to help the compiler with interprocedural dataflow analysis. It occurs me too that in a small program with no function pointers, there's probably just a few paths through the call graph to reach any particular function. If the function is called from just one place, it can be inlined there. If it's called from a few places, it may be enough to have a few global bits or words saying where the function was called from (in some cases labelling the entire call path as identified by static analysis). Then the function can be "called" with a jump after setting these bits, and "return" by switching on the bits and jumping to the appropriate return address. That allows getting rid of the return stack in favor of putting the return addresses in code space, which is more plentiful than data space on these processors (plus taking a slowdown for the call and return). It probably makes no sense in large programs with lots of call paths, but in these small microcontroller programs, maybe it can be worthwhile in some circumstances. I spent a little while with the 8051 manual yesterday and it really is a pretty neat processor, somewhat more powerful than I expected it to be. Compared to really tiny controllers like the PIC 10F/12F series, it's almost a supercomputer ;-).
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2011-05-02 21:47 -0700 |
| Message-ID | <562809d3-7763-422e-8f95-ed166f1c6104@d19g2000prh.googlegroups.com> |
| In reply to | #1637 |
On Apr 28, 10:34 pm, Paul Rubin <no.em...@nospam.invalid> wrote: > Andrew Haley <andre...@littlepinkcloud.invalid> writes: > > If you're doing something truly crazy like recursion through function > > pointers, that's true. > > I don't see what's so crazy about that. I even do it in Forth: > > : times ( xt n -- ) \ run an execution token n times > 0 ?do dup execute loop drop ; > : blob ( -- ) ['] foo boo ['] moo 5 times ; > : frob ( -- ) mob ['] blob 4 times ; > > In the above example, frob calls times, passing it blob as an xt. Times > calls blob through the xt, and blob calls times again, so it's indirect > recursion through function pointers. > > I guess I'm open to hearing that my "times" word isn't really Forth-ish, > but I find it nicer than writing explicit loops. Your TIMES isn't any good because it leaves the xt on the stack. The function presumably needs to have access to parameters on the stack, but its own xt value is in the way. You need to put the xt value on the return stack during the execution of the function, so that it is out of the way. You could also hold the xt value in a local variable so that it doesn't conflict with the DO loop's use of the return stack. See EACH in list.4th in my novice package for an example of the correct way to do this. It is possible to have lists of lists, so EACH would be called inside of itself. DECOMMA>SEQ does this; those are actually EACH[ ... ]EACH loops rather than EACH loops, but the idea is the same. Note that EACH and its ilk use BEGIN loops rather than DO loops, and don't use local variables. Local variables are very slow under SwiftForth, so I avoid their use as much as possible in the novice package. You are right that this is better than writing explicit loops. This is one of the best ways to factor code; this is common in Lisp programming. All of my novice package code uses this technique extensively. This includes list.4th and association.4th, as well as the array stuff. That novice package was written for novices, and you are a novice --- you really could learn a lot about Forth by starting there. I would make the same suggestion to Andrew Haley (this is not the first time that he has said that factoring like this is crazy, and that he prefers to write loops explicitly). On the plus side though, at least you are posting code on c.l.f. rather than just talking vaguely about code. When you post code, it is possible for programmers to comment on your code, which may result in your learning something.
[toc] | [prev] | [next] | [standalone]
| From | John Passaniti <john.passaniti@gmail.com> |
|---|---|
| Date | 2011-04-28 10:49 -0700 |
| Message-ID | <a625fdbc-236b-4ed3-90ec-767f30a81f06@q30g2000vbs.googlegroups.com> |
| In reply to | #1621 |
On Apr 28, 11:54 am, Paul Rubin <no.em...@nospam.invalid> wrote: > It occurs to me that statically allocating locals may be > hard to do if the code uses function pointers, say in > a dispatch table. Yes, which is why in such systems, if you had such indirection, you could either inform the linker of such using pragmas or more explicit linker statements. As with everything I've described in this sub- thread, it was practically never a problem to deal with.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2011-04-28 21:57 -0700 |
| Message-ID | <7x1v0l8xil.fsf@ruckus.brouhaha.com> |
| In reply to | #1627 |
John Passaniti <john.passaniti@gmail.com> writes: >> It occurs to me that statically allocating locals may be >> hard to do if the code uses function pointers > > Yes, which is why in such systems, if you had such indirection, you > could either inform the linker of such using pragmas or more explicit > linker statements. As with everything I've described in this sub- > thread, it was practically never a problem to deal with. Maybe I'll look at the SDCC docs to see how that handled. It seems like there's a similar problem if there's data pointers. And once you've got pragmas affecting the language semantics so much, it's like having an additional kludgy language stapled onto C. Overall I think C is the actual problem, and for this type of code, a lower level language (or an HLL with a richer type system, like maybe even Ada-83) would be better. For example, Ada supports constrained integers, so you can use 1-byte integers in places where they'll fit (and have automatic bound checking during debugging); it has actual arrays with known bounds, so it can use 1-byte-wide data pointers in the right places; it has a boolean type that the compiler can store as a single bit in the 8051's bit-addressible memory area, etc. (Maybe C99 can also do that). I know that lots of engineers have prior experience with C, but if you don't get to re-use the existing code universe you're familiar with, and you also have to deal with a bunch of special language extensions for the particular hardware, the past experience doesn't gain you that much.
[toc] | [prev] | [next] | [standalone]
| From | John Passaniti <john.passaniti@gmail.com> |
|---|---|
| Date | 2011-05-03 13:28 -0700 |
| Message-ID | <ac645fff-816f-4cfe-a927-9dff3ffac146@s2g2000yql.googlegroups.com> |
| In reply to | #1638 |
On Apr 29, 12:57 am, Paul Rubin <no.em...@nospam.invalid> wrote: > Maybe I'll look at the SDCC docs to see how that handled. It > seems like there's a similar problem if there's data pointers. > And once you've got pragmas affecting the language semantics > so much, it's like having an additional kludgy language stapled > onto C. I really don't understand what you have against giving the programmer control over code generation, and allowing the programmer to make intelligent choices. Oh wait, actually I do. You suffer from the fantasy that programming embedded systems is about mindlessly reusing code instead of crafting code that is specific to the problem. You want to completely ignore the target machine's limitations (such as processor speed, ROM and RAM addressability). Well, you can do that, but it's not a very smart way to approach such systems. And code you write for such systems isn't likely to meet objectives. The few times I've had to sprinkle #pragmas in my code is when I wanted to do something unusual, or when I wanted to have more control over the compiler's code generation process. The *vast* majority of the code I've written over the past 23ish years doesn't need any #pragmas or other odd directives. And when I have reused code (usually my own), I find it far more often than not just works. And it just works because the code I'm reusing was *designed* for such systems. I'm not trying to take something I wrote on some larger system with far greater resources and pretending that it makes sense to reuse that code. You see me discuss a code generation strategy like "compiled stack" and you see problems. That's nice, but in the real world, I've successfully ported efforts for one compiler to another (and between target platforms) in hours because the vast majority of the code wasn't affected by this. Usually, the biggest effort I've had porting designs between compilers and targets has more to do with any embedded assembly language code I've added. > Overall I think C is the actual problem, and for this type of > code, a lower level language (or an HLL with a richer type > system, like maybe even Ada-83) would be better. Yes, you do think C is the problem, because you refuse to recognize that writing code for a resource-constrained system is different. You want to mindlessly drop in code you've written before without a consideration of appropriateness for the target. Good luck with that. Regardless of what language you're using, that's a bad idea. Yes, it doesn't take much imagination to come up with languages that could be better tuned to the target. Or one could take an existing language-- like C-- and give the programmer more control over code generation. > I know that lots of engineers have prior experience with C, but > if you don't get to re-use the existing code universe you're > familiar with, and you also have to deal with a bunch of special > language extensions for the particular hardware, the past > experience doesn't gain you that much. Reuse of code that isn't appropriate for the target seems like a questionable goal.
[toc] | [prev] | [next] | [standalone]
Page 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web