Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #42901 > unrolled thread
| Started by | Chris Curl <ccurl609@gmail.com> |
|---|---|
| First post | 2015-10-28 09:04 -0700 |
| Last post | 2015-12-12 18:52 -0800 |
| Articles | 20 on this page of 174 — 27 participants |
Back to article view | Back to comp.lang.forth
Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 09:04 -0700
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 09:18 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-28 12:35 -0400
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 09:54 -0700
Re: Stoked lehs <skydda.barnen@gmail.com> - 2015-10-28 10:35 -0700
Re: Stoked Jason Damisch <jasondamisch@yahoo.com> - 2015-10-28 11:21 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-28 14:24 -0400
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 13:12 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-28 16:31 -0400
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 14:55 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-29 01:36 -0400
Re: Stoked Alfred Singlestone <vitonis@gmail.com> - 2015-10-30 06:01 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-30 13:22 -0400
Re: Stoked Marcos Cruz <use_the_contact_page@programandala.net> - 2015-11-07 17:50 +0000
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-07 13:04 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-07 10:19 -0800
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-07 08:29 -1000
Re: Stoked hughaguilar96@gmail.com - 2015-11-07 13:28 -0800
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-07 13:33 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-07 16:40 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-07 14:25 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-07 18:03 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-07 15:22 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-08 01:13 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-07 22:35 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-08 01:58 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-07 23:17 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-08 02:49 -0500
Re: Stoked Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-08 00:06 -0800
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-08 01:40 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-08 15:18 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-08 13:31 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-08 17:19 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-11 20:49 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-12 00:57 -0500
Re: Stoked hughaguilar96@gmail.com - 2015-11-11 22:24 -0800
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-11 23:34 -0800
Re: Stoked Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-12 00:03 -0800
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-12 19:37 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-12 15:24 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-12 13:18 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-12 16:40 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-12 20:59 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-13 01:50 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-12 23:11 -0800
Re: Stoked forthisit@gmail.com - 2015-11-12 13:47 -0800
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-12 16:27 -0800
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-12 12:18 -1000
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-13 00:28 -0800
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-11 22:37 -1000
Re: Stoked hughaguilar96@gmail.com - 2015-11-12 23:37 -0800
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-09 14:19 +0000
Re: Stoked Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-23 07:47 +0100
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-23 11:27 +0000
Re: Stoked Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-23 13:43 +0100
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-08 12:49 -1000
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-08 19:20 -0500
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-07 23:44 -1000
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-08 18:23 +0000
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-08 10:32 -0800
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-08 18:45 +0000
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-08 10:53 -0800
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-08 21:25 +0000
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-08 14:09 -0800
Re: Stoked "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-11-09 05:32 -0500
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-09 14:58 +0000
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-08 23:42 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-08 21:11 -0800
Re: Stoked Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-15 12:50 +0100
Re: Stoked Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-07 23:56 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-08 03:24 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-08 01:31 -0800
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-07 23:57 -1000
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-08 02:18 -0800
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-08 08:33 -1000
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-09 00:07 -0500
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-08 23:49 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-08 21:06 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-09 00:20 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-08 22:51 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-09 02:22 -0500
Re: Stoked Alfred Singlestone <vitonis@gmail.com> - 2015-11-10 04:32 -0800
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-10 13:48 +0000
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-10 16:17 -0500
Re: Stoked "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-11-10 17:26 -0500
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-08 21:50 -1000
Re: Stoked stephen@mpeforth.com (Stephen Pelc) - 2015-11-09 12:15 +0000
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-09 15:09 +0000
Re: Stoked Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-24 09:47 +0100
Re: Stoked stephen@mpeforth.com (Stephen Pelc) - 2015-11-24 12:54 +0000
Re: Stoked Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-24 15:03 +0100
Emulating a 16-bit Forth Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-25 13:18 +0100
Re: Emulating a 16-bit Forth Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-25 14:08 +0100
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-09 14:30 +0000
Re: Stoked Bernd Linsel <bl1@gmx.com> - 2015-11-09 18:27 +0100
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-10 00:50 -0800
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-07 23:52 -1000
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-07 23:16 -1000
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-07 23:07 -1000
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-08 17:58 +0000
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-07 12:00 -1000
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-08 17:49 +0000
Re: Stoked stephen@mpeforth.com (Stephen Pelc) - 2015-10-28 23:24 +0000
Re: Stoked Jason Damisch <jasondamisch@yahoo.com> - 2015-10-28 17:30 -0700
Re: Stoked Waldek Hebisch <hebisch@antispam.uni.wroc.pl> - 2015-10-29 02:40 +0000
Re: Stoked stephen@mpeforth.com (Stephen Pelc) - 2015-10-29 10:11 +0000
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 21:07 -0700
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-10-28 21:16 -0700
Re: Stoked franck.bensusan@gmail.com - 2015-10-29 01:35 -0700
Re: Stoked stephen@mpeforth.com (Stephen Pelc) - 2015-10-29 10:16 +0000
Re: Stoked lehs <skydda.barnen@gmail.com> - 2015-10-29 03:35 -0700
Re: Stoked lehs <skydda.barnen@gmail.com> - 2015-10-29 03:48 -0700
Re: Stoked mhx@iae.nl - 2015-10-29 11:31 -0700
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-29 12:01 -0700
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-10-29 12:26 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-29 15:29 -0400
Re: Stoked mhx@iae.nl - 2015-10-29 13:27 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-29 16:48 -0400
Re: Stoked josv@planet.nl - 2015-10-29 14:58 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-30 01:36 -0400
Re: Stoked josv@planet.nl - 2015-10-30 04:34 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-30 13:28 -0400
Re: Stoked josv@planet.nl - 2015-10-30 12:05 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-30 15:32 -0400
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-10-30 18:53 -1000
Re: Stoked josv@planet.nl - 2015-11-01 04:28 -0800
Re: Stoked hughaguilar96@gmail.com - 2015-11-03 22:27 -0800
Re: Stoked mhx@iae.nl - 2015-10-29 16:47 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-30 01:33 -0400
Re: Stoked mhx@iae.nl - 2015-10-31 00:55 -0700
Re: Stoked stephen@mpeforth.com (Stephen Pelc) - 2015-10-30 11:52 +0000
Re: Stoked josv@planet.nl - 2015-10-29 14:49 -0700
Re: Stoked stephen@mpeforth.com (Stephen Pelc) - 2015-10-30 11:50 +0000
Re: Stoked Hans Bezemer <the.beez.speaks@gmail.com> - 2015-10-28 18:39 +0100
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 11:11 -0700
Re: Stoked Hans Bezemer <the.beez.speaks@gmail.com> - 2015-10-28 20:01 +0100
Re: Stoked hughaguilar96@gmail.com - 2015-10-28 12:34 -0700
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 13:09 -0700
Re: Stoked François <francois.ganza@wanadoo.fr> - 2015-10-28 15:25 -0700
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 21:01 -0700
Re: Stoked "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-29 01:58 -0400
Re: Stoked Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-10-28 23:34 -0700
Re: Stoked Lars Brinkhoff <lars.spam@nocrew.org> - 2015-10-29 08:56 +0100
Re: Stoked "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-28 18:41 -0400
Re: Stoked josv@planet.nl - 2015-10-29 05:28 -0700
Re: Stoked "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-12-12 11:25 -0500
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-12-12 08:43 -1000
Re: Stoked hughaguilar96@gmail.com - 2015-12-16 13:45 -0800
Re: Stoked hughaguilar96@gmail.com - 2015-12-17 10:26 -0800
Re: Stoked Rob Sciuk <rob@controlq.com> - 2015-12-13 23:29 -0500
Re: Stoked Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-12-13 22:31 -0800
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-10-28 15:52 -0700
Re: Stoked anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-29 16:57 +0000
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-10-29 12:36 -0700
Re: Stoked anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-31 14:57 +0000
Re: Stoked Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-31 20:25 +0100
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-03 20:39 -0800
Re: Stoked Pablo Hugo Reda <pabloreda@gmail.com> - 2015-10-28 16:27 -0700
Re: Stoked Alfred Singlestone <vitonis@gmail.com> - 2015-10-30 05:57 -0700
Re: Stoked "HAA" <someone@microsoft.com> - 2015-11-02 13:15 +1100
Re: Stoked François <francois.ganza@wanadoo.fr> - 2015-11-02 02:08 -0800
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-10-28 09:28 -0700
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 09:37 -0700
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-10-28 10:28 -0700
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 10:52 -0700
Re: Stoked anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-28 18:14 +0000
Re: Stoked François <francois.ganza@wanadoo.fr> - 2015-10-28 15:20 -0700
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 21:16 -0700
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-30 12:13 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-30 15:34 -0400
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-11-07 13:57 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-07 17:19 -0500
Re: Stoked François <francois.ganza@wanadoo.fr> - 2015-11-09 00:10 -0800
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-12-12 18:52 -0800
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-07 14:25 -0800 |
| Message-ID | <87611dwio9.fsf@nightsong.com> |
| In reply to | #43325 |
rickman <gnuarm@gmail.com> writes: >> 1. Being written entirely in Forth with no external dependencies, >> instead of booting from assembler. >> >> 2. Being able to choose the cell size at build time, or maybe even >> run time. > I'm not at all clear on item 2. Can you explain that a bit more? How > would this be useful much less important? Say you have a Forth program that assumes a 32-bit cell size. It works great on x86 and ARM, but you'd like to run it on MSP430. So you build the MSP430 Forth for 32-bit cells. Or maybe you want to run a 16-bit program on an ARM. You get the idea. > I also don't see how you can achieve item 1 if you are going to > support multiple CPUs. Can you explain that? The primitives are written in an embedded Forth assembler for the cpus in question. That is very traditional. I didn't mean there's no assembly code, but just that you start from Forth instead of an external assembler.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-11-07 18:03 -0500 |
| Message-ID | <n1lvsi$mdb$1@dont-email.me> |
| In reply to | #43331 |
On 11/7/2015 5:25 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >>> 1. Being written entirely in Forth with no external dependencies, >>> instead of booting from assembler. >>> >>> 2. Being able to choose the cell size at build time, or maybe even >>> run time. >> I'm not at all clear on item 2. Can you explain that a bit more? How >> would this be useful much less important? > > Say you have a Forth program that assumes a 32-bit cell size. It works > great on x86 and ARM, but you'd like to run it on MSP430. So you build > the MSP430 Forth for 32-bit cells. Or maybe you want to run a 16-bit > program on an ARM. You get the idea. No, I don't really. What has to change to compile a forth for 16 bit machine? Isn't a cell a cell? Unless you overflow the cell size in some operation, a forth system is cell size agnostic I thought. What operations will exceed the capacity of a 16 bit cell. >> I also don't see how you can achieve item 1 if you are going to >> support multiple CPUs. Can you explain that? > > The primitives are written in an embedded Forth assembler for the cpus > in question. That is very traditional. I didn't mean there's no > assembly code, but just that you start from Forth instead of an external > assembler. Ok, so rather than use a FOSS assembler, you feel the need to write your own and to support that you want to code in Forthish assembly language... which still is not portable across CPUs. Hmmm... I ask, what is the value in this? I'm not seeing it. Tradition is not always optimal. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-07 15:22 -0800 |
| Message-ID | <871tc1wg1b.fsf@nightsong.com> |
| In reply to | #43336 |
rickman <gnuarm@gmail.com> writes: > What operations will exceed the capacity of a 16 bit cell. 100000 200000 + > Ok, so rather than use a FOSS assembler, you feel the need to write > your own and to support that you want to code in Forthish assembly > language... which still is not portable across CPUs. Hmmm... I ask, > what is the value in this? I'm not seeing it. Tradition is not > always optimal. You get a completely self-contained Forth environment that can rebuild itself.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-11-08 01:13 -0500 |
| Message-ID | <n1mp2q$luv$1@dont-email.me> |
| In reply to | #43337 |
On 11/7/2015 6:22 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> What operations will exceed the capacity of a 16 bit cell. > > 100000 200000 + Is that required to write a Forth? >> Ok, so rather than use a FOSS assembler, you feel the need to write >> your own and to support that you want to code in Forthish assembly >> language... which still is not portable across CPUs. Hmmm... I ask, >> what is the value in this? I'm not seeing it. Tradition is not >> always optimal. > > You get a completely self-contained Forth environment that can rebuild > itself. But it can't. Not unless you write an assembler. I don't see the huge advantage of redoing work that others have done just to be able to say you are independent of others work. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-07 22:35 -0800 |
| Message-ID | <87pozluhfj.fsf@nightsong.com> |
| In reply to | #43341 |
rickman <gnuarm@gmail.com> writes: >> 100000 200000 + > Is that required to write a Forth? There's some programs that are simply easier to write with 32-bit arithmetic than having to use double cells everywhere. There are other programs that were developed with 32-bit for whatever reason, so they use 32-bit operations: who wants to >> self-contained Forth environment that can rebuild itself. > But it can't. Not unless you write an assembler To port to a new cpu, yes you either have to write some asm primitives and a simple assembler, or implement some kind of simple token threaded VM on the target. The asm primitive approach worked well in FigForth and eForth, both of which have been ported to many targets. eForth has 20 or 30 primitives of mostly just a few instructions each, iirc. > to say you are independent of others work. That's not the issue, I'm perfectly fine re-using other people's code. The idea is only to have an all-up system that doesn't need to pull in a bunch of bloated external software dependencies such as a non-Forth assembler, rely on stuff running on a host computer, etc.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-11-08 01:58 -0500 |
| Message-ID | <n1mrnc$s5v$1@dont-email.me> |
| In reply to | #43342 |
On 11/8/2015 1:35 AM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >>> 100000 200000 + >> Is that required to write a Forth? > > There's some programs that are simply easier to write with 32-bit > arithmetic than having to use double cells everywhere. There are other > programs that were developed with 32-bit for whatever reason, so they > use 32-bit operations: who wants to Where do you need 32 bit arithmetic to write a Forth compiler? >>> self-contained Forth environment that can rebuild itself. >> But it can't. Not unless you write an assembler > > To port to a new cpu, yes you either have to write some asm primitives > and a simple assembler, or implement some kind of simple token threaded > VM on the target. The asm primitive approach worked well in FigForth > and eForth, both of which have been ported to many targets. eForth has > 20 or 30 primitives of mostly just a few instructions each, iirc. Or you write some asm primitives and use an external assembler. >> to say you are independent of others work. > > That's not the issue, I'm perfectly fine re-using other people's code. > The idea is only to have an all-up system that doesn't need to pull in a > bunch of bloated external software dependencies such as a non-Forth > assembler, rely on stuff running on a host computer, etc. I don't see where that is such an important or even useful thing. I would prefer to use an existing tool than to write my own. I notice you use the loaded term "bloated" and seem to think a host computer is a bad thing. I'm not sure what sort of target you are used to working with that isn't a PC, yet has adequate facilities to support development without a host computer. The ones I work with are either a PC or a target that is not capable of supporting a full development environment. Heck, I even use a non-forth editor. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-07 23:17 -0800 |
| Message-ID | <87lha9ufhc.fsf@nightsong.com> |
| In reply to | #43343 |
rickman <gnuarm@gmail.com> writes: > Where do you need 32 bit arithmetic to write a Forth compiler? You don't. You might want to write a Forth APPLICATION that needs 32 bit arithmetic. And then to run that program, you want a Forth interpreter with 32 bit cells. If the hardware you want to run on has 16 bit words, you could make a special build of the interpreter and take some efficiency loss, instead of rewriting the app to use double ints all over. > Or you write some asm primitives and use an external assembler. You could do that, but Forth assemblers are standard in the Forth world and if you want a native code compiler, it will need some kind of assembler anyway. > I'm not sure what sort of target you are used to working with that > isn't a PC, yet has adequate facilities to support development without > a host computer. The idea is to have a complete development environment on a small embedded board, like the systems of the FigForth and F83 era. You plug in a terminal and hack away. I've always wanted to know how the legendary forth programmers of the 1970s and 1980s managed to get anything done on those systems.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-11-08 02:49 -0500 |
| Message-ID | <n1mulh$46a$1@dont-email.me> |
| In reply to | #43344 |
On 11/8/2015 2:17 AM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> Where do you need 32 bit arithmetic to write a Forth compiler? > > You don't. You might want to write a Forth APPLICATION that needs 32 > bit arithmetic. And then to run that program, you want a Forth > interpreter with 32 bit cells. If the hardware you want to run on has > 16 bit words, you could make a special build of the interpreter and take > some efficiency loss, instead of rewriting the app to use double ints > all over. Or I can define a set of words for that app that use double operations with the 32 bit doubles. In effect make the 16 bit forth work like a 32 bit forth without rewriting the forth interpreter. We do things similar to this in VHDL and it is called "overloading", very common. >> Or you write some asm primitives and use an external assembler. > > You could do that, but Forth assemblers are standard in the Forth world > and if you want a native code compiler, it will need some kind of > assembler anyway. You started out with this in your list of things that make writing your own forth a requirement. Now you are saying it is common in the forth world. If it is so common, why would it be one of the features that makes you need to write your own forth? >> I'm not sure what sort of target you are used to working with that >> isn't a PC, yet has adequate facilities to support development without >> a host computer. > > The idea is to have a complete development environment on a small > embedded board, like the systems of the FigForth and F83 era. You plug > in a terminal and hack away. I've always wanted to know how the > legendary forth programmers of the 1970s and 1980s managed to get > anything done on those systems. These days terminals are PCs and no one just "hacks away", never did. You need a way to save and load source, etc. I think you image of useful programming is a bit obsolete. I recently wrote some code for a small board using Mecrisp. It runs on the target, but I need a PC to act as life support for development. I can't imagine trying to do any development without the PC or something similar. I could use the raspberry Pi, but that's just a small PC. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-11-08 00:06 -0800 |
| Message-ID | <3f90b31d-7e09-483e-8eed-3c476aee973f@googlegroups.com> |
| In reply to | #43346 |
> > The idea is to have a complete development environment on a small > > embedded board, like the systems of the FigForth and F83 era. You plug > > in a terminal and hack away. I've always wanted to know how the > > legendary forth programmers of the 1970s and 1980s managed to get > > anything done on those systems. > > These days terminals are PCs and no one just "hacks away", never did. > You need a way to save and load source, etc. I think you image of > useful programming is a bit obsolete. I recently wrote some code for a > small board using Mecrisp. It runs on the target, but I need a PC to > act as life support for development. I can't imagine trying to do any > development without the PC or something similar. I could use the > raspberry Pi, but that's just a small PC. > You are right, you need a "PC". At least for editing/storing source files and for a "console" or terminal. My plan for embedding my LFTForth is to support as a minimum system a cortex-m cpu AND a serial flash memory (a practical minimum will be 512K bytes which is as low as 13 cents these days). The serial flash will carry a small file system where the source files will be loaded by either XMODEM or TFTP. The compilation will be "embedded" but from the internal file system, like in desktop computers. As an interesting thing, the dictionary will also be "external" in a file. So the cortex-m internal executable flash will carry only real executable code. The whole LFTForth design is based on a separate dicitionary space assumption.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-08 01:40 -0800 |
| Message-ID | <878u68vngr.fsf@nightsong.com> |
| In reply to | #43346 |
rickman <gnuarm@gmail.com> writes: > These days terminals are PCs and no one just "hacks away", never > did. You need a way to save and load source, etc. You can have storage on the target. > I recently wrote some code for a small board using Mecrisp. It runs > on the target, but I need a PC to act as life support for development. > I can't imagine trying to do any development without the PC or > something similar. I could use the raspberry Pi, but that's just a > small PC. Maybe you'd like to use a PC, or maybe a rPi, or perhaps a Macintosh or a tablet or a mobile phone (Android or Apple or Maemo/Jolla or Firefox or whatever) or Y or Z or whatever. You ready to write a different host app for each of those environments? They all have terminal emulators so that's the least common denominator.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-11-08 15:18 -0500 |
| Message-ID | <n1oaij$677$2@dont-email.me> |
| In reply to | #43353 |
On 11/8/2015 4:40 AM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> These days terminals are PCs and no one just "hacks away", never >> did. You need a way to save and load source, etc. > > You can have storage on the target. Actually you can't on many targets like the TMS430 or CM3 and CM4 ARMs. >> I recently wrote some code for a small board using Mecrisp. It runs >> on the target, but I need a PC to act as life support for development. >> I can't imagine trying to do any development without the PC or >> something similar. I could use the raspberry Pi, but that's just a >> small PC. > > Maybe you'd like to use a PC, or maybe a rPi, or perhaps a Macintosh or > a tablet or a mobile phone (Android or Apple or Maemo/Jolla or Firefox > or whatever) or Y or Z or whatever. You ready to write a different host > app for each of those environments? They all have terminal emulators so > that's the least common denominator. What host app is needed? There is no host app. I'm getting tired of this discussion. No useful information is being exchanged. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-08 13:31 -0800 |
| Message-ID | <87mvuotbz3.fsf@nightsong.com> |
| In reply to | #43384 |
rickman <gnuarm@gmail.com> writes: >> You can have storage on the target. > Actually you can't on many targets like the TMS430 or CM3 and CM4 ARMs. Some of the CM4's have as much as a megabyte of flash right there on the chip. That's more than plenty for a Forth environment and its full source code. > What host app is needed? There is no host app. The Forth development environment, external assembler, etc. that you want on the host instead of the target.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-11-08 17:19 -0500 |
| Message-ID | <n1ohld$5lb$1@dont-email.me> |
| In reply to | #43387 |
On 11/8/2015 4:31 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >>> You can have storage on the target. >> Actually you can't on many targets like the TMS430 or CM3 and CM4 ARMs. > > Some of the CM4's have as much as a megabyte of flash right there on > the chip. That's more than plenty for a Forth environment and its full > source code. And you need to create a file system to support that. I see no value in this since it completely lacks all the normal mechanisms of support... unless you want to reinvent all those wheels as well. I seem to recall that Chuck Moore was working this way not too long ago and ended up losing a bunch of source. Not my idea of good practice. Then when you work with an MCU that only has 64 kB of flash you have to revert to using a PC host. >> What host app is needed? There is no host app. > > The Forth development environment, external assembler, etc. that you > want on the host instead of the target. What development environment? You are putting words in my mouth. Check out Mecrisp. It works the way I like, using the PC for the things a PC does well and doing reasonable things on the target. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-11 20:49 -0800 |
| Message-ID | <87fv0brfdl.fsf@nightsong.com> |
| In reply to | #43389 |
rickman <gnuarm@gmail.com> writes: > And you need to create a file system to support that. I see no value > in this since it completely lacks all the normal mechanisms of > support... unless you want to reinvent all those wheels as well. What normal mechanisms? I was imagining the same stuff that existed in F83 and Polyforth, very traditional. I admittedly have never used either of those, but have always wondered what the experience was like. > Then when you work with an MCU that only has 64 kB of flash you have > to revert to using a PC host. The cpu of immediate interest is the MSP430FR6989 which has 128K of FRAM, but I take your point: small MCU's can't really support this approach while bigger (e.g. rPi level) boards can handle full blown OS's, so there's only a narrow middle range where the concept has any plausible appeal. >> The Forth development environment, external assembler, etc. that you >> want on the host instead of the target. > What development environment? You are putting words in my mouth. > Check out Mecrisp. I don't think there's a way to modify and rebuild Mecrisp from source without using tools outside of Mecrisp itself. The historical Forths were capable of total self-bootstrapping. I think that's an incredibly cool characteristic. Whether that's of much practical benefit, I don't know, but how can any red-blooded programmer not want to check out such a system if it exists?
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-11-12 00:57 -0500 |
| Message-ID | <n219k5$2td$1@dont-email.me> |
| In reply to | #43489 |
On 11/11/2015 11:49 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> And you need to create a file system to support that. I see no value >> in this since it completely lacks all the normal mechanisms of >> support... unless you want to reinvent all those wheels as well. > > What normal mechanisms? I was imagining the same stuff that existed in > F83 and Polyforth, very traditional. I admittedly have never used > either of those, but have always wondered what the experience was like. There is a reason why blocks are barely used these days. If nothing else, lack of compatibility with the rest of the world. The real issue is the myriad of support a PC provides while any fully self contained system has to duplicate any of that functionality you wish to use. How many times have people tried to boot one of the various native forths only to find they don't have the requisite hardware or that the forth doesn't support some hardware they wish to use? Same with all the software provided with an operating system. >> Then when you work with an MCU that only has 64 kB of flash you have >> to revert to using a PC host. > > The cpu of immediate interest is the MSP430FR6989 which has 128K of > FRAM, but I take your point: small MCU's can't really support this > approach while bigger (e.g. rPi level) boards can handle full blown > OS's, so there's only a narrow middle range where the concept has any > plausible appeal. "Appeal" is the part I don't get. It may be possible to implement a forth that can compile source from local flash, but where is the advantage? The same PC connection that lets you use it as a terminal can just as easily provide a full set of functions. >>> The Forth development environment, external assembler, etc. that you >>> want on the host instead of the target. >> What development environment? You are putting words in my mouth. >> Check out Mecrisp. > > I don't think there's a way to modify and rebuild Mecrisp from source > without using tools outside of Mecrisp itself. The historical Forths > were capable of total self-bootstrapping. I think that's an incredibly > cool characteristic. Whether that's of much practical benefit, I don't > know, but how can any red-blooded programmer not want to check out such > a system if it exists? "Cool" is not of relevance to me. I just want an approach that works, easily and conveniently. I especially like the idea that I don't have to design an assembler for every processor the system is ported to. Using an existing tool on a PC is not automatically a large hurdle. When you say historical Forths were capable of total self-bootstrapping I don't think that includes porting to a new processor. Not only do you need to code the assembler, you need to modify any code that interfaces with the unique hardware of a different processor. Ask Forth Inc why they don't support more processors. I remember I tried to encourage MPE to support the ARM MCUs. It was some time later that this eventually happened, most likely when they found a customer to pay for the port since the costs are considerable. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-11-11 22:24 -0800 |
| Message-ID | <5c6e15f2-9a48-47d2-b73b-fddbc1b4725d@googlegroups.com> |
| In reply to | #43490 |
On Wednesday, November 11, 2015 at 10:57:35 PM UTC-7, rickman wrote: > "Cool" is not of relevance to me. This has been obvious for quite some time --- most likely starting in junior high-school. I think comp.lang.forth would be a lot more fun if people were less full of themselves and just more cool --- the Forth-200x folks are very focused on claiming to be benevolent dictators and denouncing everybody who refuses to bow to them as being non-standard; they are really as uncool as it is possible to be.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-11 23:34 -0800 |
| Message-ID | <876117r7ql.fsf@nightsong.com> |
| In reply to | #43490 |
rickman <gnuarm@gmail.com> writes: >> F83 and Polyforth, very traditional. > There is a reason why blocks are barely used these days. Well ok, a simple file system is easy to implement and doesn't take much code. I've done it several times--it's not a big deal. > The real issue is the myriad of support a PC provides.. How many times > have people tried to boot one of the various native forths only to > find they don't have the requisite hardware or that the forth doesn't > support some hardware they wish to use? That's because a PC is a complicated device with a lot of hardware that simpler systems don't deal with. I don't imagine this on a PC but rather on an MCU or something like a Launchpad board. There just wouldn't be all that extra stuff from multiple vendors, no CD burner or desktop scanner, etc. > "Appeal" is the part I don't get. It may be possible to implement a > forth that can compile source from local flash, but where is the > advantage? The same PC connection that lets you use it as a terminal > can just as easily provide a full set of functions. What if there's no PC? You might have a Mac instead, or a Chromebook, or a mobile phone, or whatever. Any software you wanted to run on the PC now has to run on that other thing instead. If it's a browser or a terminal emulator you're probably ok. Anything else: lots of luck. Better to not depend on any special software. > Ask Forth Inc why they don't support more processors. I remember I > tried to encourage MPE to support the ARM MCUs. It was some time Doing a commercially supported product that has to be qualified on lots of disparate hardware, with a complicated optimizing compiler (written in Forth even) that has to be targeted to the new cpu, is a lot more complicated than porting a simple interpreter or STC compiler. > Actually, I'm not sure why it would be any better to debug the code on > a different platform. Do you have some special debugging tools on the > Linux box? What makes this more convenient? Well, I'm used to gforth and I've generally found that bigger systems have more development and debugging conveniences. Plus you don't have to mess with the target hardware unless you're trying to test something that actually uses special features that it has. Even for embedded Linux, I've preferred cross-developing to the extent possible. > crashing the target required me to go to the other room since I was > working remotely. For the ARM stuff I'm currently messing with, I work remotely too--my ARM board is in France (www.scaleway.com/pricing). So I can't easily go to the other room to muck with it. I'd rather just be able to sit around with my laptop and no internet, and code the non-hardware-specific parts as much as possible without the hardware. I don't even own one of those fancy MSP430 boards at the moment. I'm resisting buying one until I've actually coded the app. > I was very happy with Mecrisp... In fact, the problem I had using it > with the PC is the TI driver for flashing the launchpad... So I > decided to use a raspberry Pi as the "host" for the TI launchpad How did you avoid similar problems with the RPi driver? See, I'm imagining something like 4e4th where there's no downloads, no drivers, no installation. You get a board (maybe a Stellaris launchpad, maybe something like this (it could even be called 5e4th since the board costs 5 euros): https://www.olimex.com/Products/IoT/MOD-WIFI-ESP8266/ with Forth already on it, including all the source code, editor, etc. Then you just use it directly in a totally Forth environment. Btw that 5 euro board has a 32 bit cpu (comparable to ARM CM3 I think), 96k of usable ram iiuc, and 2MB of SPI flash there on the board, plus wifi (board is cheap enough that people use it for non-wifi things too) and the usual MCU stuff (gpio etc). There are many similar boards for the same chip. It would be neat to have a Forth system on one. You could bake it into some embedded thing, and then any time you wanted, you could go up to it with your smartphone and connect to it and configure or reprogram it any way you wanted, including total rebuild of the software, all done right there on the board. Who needs a PC?
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-11-12 00:03 -0800 |
| Message-ID | <67191170-f1d5-4e7f-af7e-eedcf59d5d96@googlegroups.com> |
| In reply to | #43492 |
> Btw that 5 euro board has a 32 bit cpu (comparable to ARM CM3 I think), > 96k of usable ram iiuc, and 2MB of SPI flash there on the board, plus > wifi (board is cheap enough that people use it for non-wifi things too) > and the usual MCU stuff (gpio etc). There are many similar boards for > the same chip. It would be neat to have a Forth system on one. You > could bake it into some embedded thing, and then any time you wanted, > you could go up to it with your smartphone and connect to it and > configure or reprogram it any way you wanted, including total rebuild of > the software, all done right there on the board. Who needs a PC? I don't think I understand what you are describing. A PC is needed at least for a terminal emulator (the bare minimum). If you happen to have one on a smartphone, ok, but I don't think you will edit source files on the phone... Keep in mind that the old systems had a keyboard and a monitor... They afforded to be independent. These emebedded boards like launchpad or ESP thing don't have that... They usually have only a communication link (uart) fopr both the "keyboard" and the "monitor". Incidentally, the ESP8266 systems are exactly like what I'm targetting, because they have a serial flash. There you can store source files and the embedded forth system can act exactly like a PC, compiling from the internal source files. The problem is how you will get those files in. And there are two solutions: one is to transfer the files from a PC/whatever by XMODEM, FTP, TFTP, etc. and second is to have an internal editor. But this editor should use the "keyboard" and "monitor" over a serial link (or a tcpip protocol).
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-12 19:37 -0800 |
| Message-ID | <877flmpo1r.fsf@nightsong.com> |
| In reply to | #43494 |
Raimond Dragomir <raimond.dragomir@gmail.com> writes: > I don't think I understand what you are describing. A PC is needed at > least for a terminal emulator (the bare minimum). If you happen to > have one on a smartphone, ok, but I don't think you will edit source > files on the phone... I don't see why not. People send email from their phones all the time. Heavy duty development on a phone is probably impractical, but setting a parameter or patching a few lines of code seems ok. And you can always use an external keyboard with your phone.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-11-12 15:24 -0500 |
| Message-ID | <n22scs$3ju$1@dont-email.me> |
| In reply to | #43492 |
On 11/12/2015 2:34 AM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >>> F83 and Polyforth, very traditional. >> There is a reason why blocks are barely used these days. > > Well ok, a simple file system is easy to implement and doesn't take much > code. I've done it several times--it's not a big deal. > >> The real issue is the myriad of support a PC provides.. How many times >> have people tried to boot one of the various native forths only to >> find they don't have the requisite hardware or that the forth doesn't >> support some hardware they wish to use? > > That's because a PC is a complicated device with a lot of hardware that > simpler systems don't deal with. I don't imagine this on a PC but > rather on an MCU or something like a Launchpad board. There just > wouldn't be all that extra stuff from multiple vendors, no CD burner or > desktop scanner, etc. This discussion is not really going anywhere. You are picturing a very simple system that is self contained (of questionable value) with limited functionality as your entire development system. You don't seem to appreciate the need for inter-working, communication or backup et. al. Constructing a full blown development system is a big deal. That's why no one does it. They use computers running an OS with tons of support software. >> "Appeal" is the part I don't get. It may be possible to implement a >> forth that can compile source from local flash, but where is the >> advantage? The same PC connection that lets you use it as a terminal >> can just as easily provide a full set of functions. > > What if there's no PC? You might have a Mac instead, or a Chromebook, > or a mobile phone, or whatever. Any software you wanted to run on the > PC now has to run on that other thing instead. If it's a browser or a > terminal emulator you're probably ok. Anything else: lots of luck. > Better to not depend on any special software. To me "PC" includes whatever platform you are running including a cell phone. What software are you imagining? There typically has to be a terminal emulator and a flash burner. Often the flash burner uses a standard protocol, but often there are vendor specific flavors. If your chip/board vendor doesn't support a platform, then you can't use that without writing your own burner code or more likely modifying existing code to work on that platform. Still tons less work than trying to duplicate the PC functionality on every target you wish to use. >> Ask Forth Inc why they don't support more processors. I remember I >> tried to encourage MPE to support the ARM MCUs. It was some time > > Doing a commercially supported product that has to be qualified on lots > of disparate hardware, with a complicated optimizing compiler (written > in Forth even) that has to be targeted to the new cpu, is a lot more > complicated than porting a simple interpreter or STC compiler. I'm not talking about writing a compiler. I'm talking about supporting a new target. Heck, they even support a limited number of boards using the same CPU. If it were remotely easy, they would support a large number of brands, chip models and boards. >> Actually, I'm not sure why it would be any better to debug the code on >> a different platform. Do you have some special debugging tools on the >> Linux box? What makes this more convenient? > > Well, I'm used to gforth and I've generally found that bigger systems > have more development and debugging conveniences. Plus you don't have > to mess with the target hardware unless you're trying to test something > that actually uses special features that it has. Even for embedded > Linux, I've preferred cross-developing to the extent possible. > >> crashing the target required me to go to the other room since I was >> working remotely. > > For the ARM stuff I'm currently messing with, I work remotely too--my > ARM board is in France (www.scaleway.com/pricing). So I can't easily go > to the other room to muck with it. I'd rather just be able to sit > around with my laptop and no internet, and code the > non-hardware-specific parts as much as possible without the hardware. I > don't even own one of those fancy MSP430 boards at the moment. I'm > resisting buying one until I've actually coded the app. I'm not sure why there would be hardware specific stuff. Isn't this under an OS? Do they even let you access the hardware? >> I was very happy with Mecrisp... In fact, the problem I had using it >> with the PC is the TI driver for flashing the launchpad... So I >> decided to use a raspberry Pi as the "host" for the TI launchpad > > How did you avoid similar problems with the RPi driver? I don't recall the details, but a flash tool for Linux just worked. I think someone had hacked something up that might have been multi-target and they added the TI target. The TI tool would have worked on the PC fine, but they didn't get a signature and you had to muck with a bunch of crap to install the unsigned tool. Part of the reason I used the rPi was so I *could* work remotely, even though it was just in the next room. I also wanted to learn more about using the rPi. I'm not a Linux guy. > See, I'm imagining something like 4e4th where there's no downloads, no > drivers, no installation. You get a board (maybe a Stellaris launchpad, > maybe something like this (it could even be called 5e4th since the board > costs 5 euros): > > https://www.olimex.com/Products/IoT/MOD-WIFI-ESP8266/ > > with Forth already on it, including all the source code, editor, etc. > Then you just use it directly in a totally Forth environment. That's great, but how "total" can it be? Won't it need a PC to provide storage, etc? How does the user back up the info and propagate it to other units? If you are using a PC for a terminal, all the rest comes free. > Btw that 5 euro board has a 32 bit cpu (comparable to ARM CM3 I think), > 96k of usable ram iiuc, and 2MB of SPI flash there on the board, plus > wifi (board is cheap enough that people use it for non-wifi things too) > and the usual MCU stuff (gpio etc). There are many similar boards for > the same chip. It would be neat to have a Forth system on one. You > could bake it into some embedded thing, and then any time you wanted, > you could go up to it with your smartphone and connect to it and > configure or reprogram it any way you wanted, including total rebuild of > the software, all done right there on the board. Who needs a PC? I might have an application for this board. Right now the prototype is using Bluetooth, but wifi would do the job too. One small detail. The board appears to have no I/O and very little board level documentation. I guess the MOD-WIFI-ESP8266-DEV is more like what I need. I would probably port Mecrisp to it if I can figure out what CPU it uses and how to use it. -- Rick
[toc] | [prev] | [next] | [standalone]
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web