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 3 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-12 13:18 -0800 |
| Message-ID | <87si4aq5l3.fsf@nightsong.com> |
| In reply to | #43507 |
rickman <gnuarm@gmail.com> writes: > 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. 1. Back in the day (before my time) real development was done on such systems and people gushed about how productive it was. I have my doubts but it sounds interesting. 2. I don't actually see such a system as the entire development environment for complicated applications. I see writing the app using a PC and installing it on the little board along with the pure Forth dev environment, and delivering it that way to users. The users could then configure and modify the code if they wanted, without needing specific PC software. This seems like a reasonable way to (e.g.) set parameters or put in small patches, that might involve rebuilding the interpreter. They could also use a PC environment if the internal Forth stuff got to be too constraining. > 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. There are terminal emulators for everything, e.g. type "terminal emulator android" into a search engine. There would be in-circuit programming, so no flash burner. There would have to be a way to upload/download the flash contents through the terminal port, as hex dumps or whatever, so you could back it up, use source control, etc. >> my ARM board is in France... I'd rather... 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 not sure why there would be hardware specific stuff. Isn't this > under an OS? Do they even let you access the hardware? Sorry, two things conflated. 1) the ARM board runs Linux and I basically use it as a small dedicated server, no special hardware. I might try to run Mecrisp on it (there is a Linux port) but am not yet doing that. 2) The MSP430 (my app target) has no OS. The idea is to write the app under Linux or under emulation, then port it to the Launchpad. > 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? Most terminal emulators have ways to upload and download files. And those boards are quite powerful! The original Macintosh had 128k of ram and a 400k floppy and 64k of rom, so a lot can be done with those resources. > 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. The cpu uses a MIPS-descended architecture with a more compact instruction set. There is a GCC port for it. You'll have to retarget the Mecrisp compiler but that is probably doable. You want to look up ESP8266, the chip type. There are a lot of other boards using it, including Chinese ones for around $2 each on ebay. You could also look at the Adafruit Huzzah breakout page (www.adafruit.com/products/2471) which might point to better docs. The Huzzah board runs Lua I think someone even got Micropython running on the 8266. www.esp8266.com has a lot of other info about these systems. Espressif is doing a follow-on to the 8266 that has both wifi and Bluetooth: http://hackaday.com/2015/07/13/new-part-day-the-esp8266-killer/ The Mecrisp port for that one might be easier, since it uses a Cortex M4 core.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-11-12 16:40 -0500 |
| Message-ID | <n230sm$m1s$1@dont-email.me> |
| In reply to | #43508 |
On 11/12/2015 4:18 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> 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. > > 1. Back in the day (before my time) real development was done on such > systems and people gushed about how productive it was. I have my doubts > but it sounds interesting. I think the point of comparison was different. Working on the target can be very productive, but that would be compared to the edit, compile, load, debug cycle using a VAX or similar machine potentially shared between a dozen users. > 2. I don't actually see such a system as the entire development > environment for complicated applications. I see writing the app using a > PC and installing it on the little board along with the pure Forth dev > environment, and delivering it that way to users. The users could then > configure and modify the code if they wanted, without needing specific > PC software. This seems like a reasonable way to (e.g.) set parameters > or put in small patches, that might involve rebuilding the interpreter. > They could also use a PC environment if the internal Forth stuff got to > be too constraining. I'm not so worried about users modifying the code. Not my problem. >> 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. > > There are terminal emulators for everything, e.g. type "terminal > emulator android" into a search engine. There would be in-circuit > programming, so no flash burner. There would have to be a way to > upload/download the flash contents through the terminal port, as hex > dumps or whatever, so you could back it up, use source control, etc. Not sure what system you are describing. The development systems I work with have a single USB cable with two functions, burning the flash and comms. You get a board, install the flash software, burn the Forth program and start working with it through the term emulator. You edit your code on the PC using your favorite editor and load it into the board in RAM for debug, Flash for inclusion to the system. Debug as you see fit. >>> my ARM board is in France... I'd rather... 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 not sure why there would be hardware specific stuff. Isn't this >> under an OS? Do they even let you access the hardware? > > Sorry, two things conflated. 1) the ARM board runs Linux and I > basically use it as a small dedicated server, no special hardware. I > might try to run Mecrisp on it (there is a Linux port) but am not yet > doing that. 2) The MSP430 (my app target) has no OS. The idea is to > write the app under Linux or under emulation, then port it to the > Launchpad. Why bother with the ARM server? Why not just use your PC? >> 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? > > Most terminal emulators have ways to upload and download files. And > those boards are quite powerful! The original Macintosh had 128k of ram > and a 400k floppy and 64k of rom, so a lot can be done with those > resources. Ok, I'm a bit tired of dealing with this aspect. The size of the storage is not the point. The issue is all the things you can do with the source on the PC that you can't do with it on the target. Once you connect the PC there is no reason to do extra work to move functionality into the target. >> 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. > > The cpu uses a MIPS-descended architecture with a more compact > instruction set. There is a GCC port for it. You'll have to retarget > the Mecrisp compiler but that is probably doable. That's a MAJOR port since it will require adjusting all the startup code to a new processor. Mecrisp only supports ARM and MSP430 so far I believe, but a fair number of target boards, around 20 I think. > You want to look up ESP8266, the chip type. There are a lot of other > boards using it, including Chinese ones for around $2 each on ebay. You > could also look at the Adafruit Huzzah breakout page > (www.adafruit.com/products/2471) which might point to better docs. The > Huzzah board runs Lua I think someone even got Micropython running on > the 8266. www.esp8266.com has a lot of other info about these systems. I'm not looking for chip docs, I want board docs. Looking at the schematic there are GPIO4 and GPIO5 which seem to be connected to some sort of connector. I have to dig into the tiny photos to find they seem to be connected to vias or miniature pads. To be useful there should be a ground, but I suppose the power connection is sufficient. It does not appear this module is intended for any I/O purpose. The MOD-WIFI-ESP8266-DEV has many I/Os along the edges, but still no board docs other than a schematic. > Espressif is doing a follow-on to the 8266 that has both wifi and > Bluetooth: > > http://hackaday.com/2015/07/13/new-part-day-the-esp8266-killer/ > > The Mecrisp port for that one might be easier, since it uses a Cortex M4 > core. MUCH easier. Heck, using a STM32F4 means it may already have a port. I may have to try this one! -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-12 20:59 -0800 |
| Message-ID | <8737wapk9u.fsf@nightsong.com> |
| In reply to | #43509 |
rickman <gnuarm@gmail.com> writes: > I think the point of comparison was different. Working on the target > can be very productive, but that would be compared to the edit, > compile, load, debug cycle using a VAX or similar machine potentially > shared between a dozen users. I wrote lots of C on Vaxes back then. It wasn't that much different than writing C today. Compiling was much slower per KLOC but you tended to work on smaller programs. Interactive debuggers (then and now) let you trace through a running program without having to recompile it a lot of times. Forth's much faster compilation lets you insert tracing and recompile instead of using an external breakpoint debugger, we've had some threads here comparing the approaches. It didn't occur to me til just now, maybe C users preferred debuggers because they avoid recompiles that are much cheaper in Forth. Overall though, I think the big productivity gain over the VAX era is that C is now relegated to a low level systems niche, with application programming usually done in HLL's. > I'm not so worried about users modifying the code. Not my problem. Whether that's useful depends of course on what you're trying to do. > You get a board, install the flash software, burn the Forth program > and start working with it through the term emulator. You edit your > code on the PC using your favorite editor and load it into the board > in RAM for debug, Flash for inclusion to the system. Hmm, most of those chips let you erase and rewrite flash blocks under program control. So I was expecting an Arduino-like system where there's a protected bootloader in low flash, that lets you load your program over the same port that's used for other comms. You don't need to mess with an actual flash programmer unless you somehow corrupt the boot loader, which is hard to do by accident. > Why bother with the ARM server? Why not just use your PC? 1) the ARM server is an actual server, in a data center, running 24/7 with high speed internet, etc. I can access it from anywhere and serve data to other computers from it. I can back it up over the network without being limited by my slow DSL uplink. I don't have to worry about bogging my laptop down if I run an overnight computation on it (I did a 7 hour software build a couple nights ago), etc. I always prefer remote servers to my laptop for big calculations, since the laptop fan turns on and the thing feels like it's straining. 2) I wanted a 32-bit system to mess with and my laptop has a 64 bit OS. 3) The ARM is a crash and burn machine. If I mess something up badly enough, it's no big deal to wipe it out and reinstall. 4) I'd like to try ARM-specific software like Mecrisp, which has an ARM Linux port. 5) The ARM servers are crazy cheap (0.6 eurocents/hour or 3 euro/month rental) and I can acquire and release them under program control through an API. They're about 1/4 the CPU speed of my laptop, or similar to a netbook Atom or a RPi model 2. So for 60 eurocents an hour I can launch 100 of them in parallel and do a calculation in a few days that would take months on my laptop. There's actually a shortage of the boards right now (probably can't get 100 at once) but being able to do that is the design intention and hopefully they'll get more hardware in place soon. It's sort of a miniature EC2 cloud. > Once you connect the PC there is no reason to do extra work to move > functionality into the target. A tethered Forth may be even better-- Elizabeth says her users prefer that to resident Forths these days. I don't know of any free ones though. >> The cpu uses a MIPS-descended architecture > That's a MAJOR port Hmm ok. > I'm not looking for chip docs, I want board docs. I thought Olimex published a lot of such stuff. You could ask on their forum. > MUCH easier. Heck, using a STM32F4 means it may already have a port. > I may have to try this one! There's a link in the Hackaday thread to Seeed Studios which sells them for $8. Let me know if you get one and do anything with it.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-11-13 01:50 -0500 |
| Message-ID | <n2413b$joc$1@dont-email.me> |
| In reply to | #43517 |
On 11/12/2015 11:59 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> I think the point of comparison was different. Working on the target >> can be very productive, but that would be compared to the edit, >> compile, load, debug cycle using a VAX or similar machine potentially >> shared between a dozen users. > > I wrote lots of C on Vaxes back then. It wasn't that much different > than writing C today. Compiling was much slower per KLOC but you tended > to work on smaller programs. Interactive debuggers (then and now) let > you trace through a running program without having to recompile it a lot > of times. Forth's much faster compilation lets you insert tracing and > recompile instead of using an external breakpoint debugger, we've had > some threads here comparing the approaches. It didn't occur to me > til just now, maybe C users preferred debuggers because they avoid > recompiles that are much cheaper in Forth. > > Overall though, I think the big productivity gain over the VAX era is > that C is now relegated to a low level systems niche, with application > programming usually done in HLL's. > >> I'm not so worried about users modifying the code. Not my problem. > > Whether that's useful depends of course on what you're trying to do. > >> You get a board, install the flash software, burn the Forth program >> and start working with it through the term emulator. You edit your >> code on the PC using your favorite editor and load it into the board >> in RAM for debug, Flash for inclusion to the system. > > Hmm, most of those chips let you erase and rewrite flash blocks under > program control. So I was expecting an Arduino-like system where > there's a protected bootloader in low flash, that lets you load your > program over the same port that's used for other comms. You don't need > to mess with an actual flash programmer unless you somehow corrupt the > boot loader, which is hard to do by accident. > >> Why bother with the ARM server? Why not just use your PC? > > 1) the ARM server is an actual server, in a data center, running 24/7 > with high speed internet, etc. I can access it from anywhere and > serve data to other computers from it. I can back it up over the > network without being limited by my slow DSL uplink. I don't have to > worry about bogging my laptop down if I run an overnight computation > on it (I did a 7 hour software build a couple nights ago), etc. I > always prefer remote servers to my laptop for big calculations, since > the laptop fan turns on and the thing feels like it's straining. This isn't making any sense to me. I'm not sure what programs you are working on, but if you are targeting an embedded target I see no reason why an ARM server would be of any real value. When you talk about the entire development system being on the embedded MSP430 target and then you talk about 7 hour builds, I can only figure you are living in a different universe than I am. > 2) I wanted a 32-bit system to mess with and my laptop has a 64 bit OS. To develop code for a 16 bit target... > 3) The ARM is a crash and burn machine. If I mess something up badly > enough, it's no big deal to wipe it out and reinstall. I have no idea what you could be doing that would crash a PC to the point you need to reinstall the OS. > 4) I'd like to try ARM-specific software like Mecrisp, which has an > ARM Linux port. Which you could run on the MSP430 target instead. > 5) The ARM servers are crazy cheap (0.6 eurocents/hour or 3 euro/month > rental) and I can acquire and release them under program control > through an API. They're about 1/4 the CPU speed of my laptop, or > similar to a netbook Atom or a RPi model 2. So for 60 eurocents an > hour I can launch 100 of them in parallel and do a calculation in a > few days that would take months on my laptop. There's actually a > shortage of the boards right now (probably can't get 100 at once) but > being able to do that is the design intention and hopefully they'll > get more hardware in place soon. It's sort of a miniature EC2 cloud. The $10 MSP430 board is *free* to use once you get in house. >> Once you connect the PC there is no reason to do extra work to move >> functionality into the target. > > A tethered Forth may be even better-- Elizabeth says her users prefer > that to resident Forths these days. I don't know of any free ones > though. A tethered forth is some work to get going and is *exactly* the dedicated environment with dependencies on both the target and host that you were saying you wanted to avoid. >>> The cpu uses a MIPS-descended architecture >> That's a MAJOR port > > Hmm ok. > >> I'm not looking for chip docs, I want board docs. > > I thought Olimex published a lot of such stuff. You could ask on their > forum. The forum for this board seems to be people asking/complaining with no responses. >> MUCH easier. Heck, using a STM32F4 means it may already have a port. >> I may have to try this one! > > There's a link in the Hackaday thread to Seeed Studios which sells them > for $8. Let me know if you get one and do anything with it. I might, but it will be later I think. The lack of real documentation is an issue. I have an FPGA/CPU SoC board I want to work with. If I get that working I will try this next. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-12 23:11 -0800 |
| Message-ID | <87y4e2nzl0.fsf@nightsong.com> |
| In reply to | #43518 |
rickman <gnuarm@gmail.com> writes: > This isn't making any sense to me. I'm not sure what programs you are > working on, but if you are targeting an embedded target I see no > reason why an ARM server would be of any real value. Nah, the ARM server is for general hacking which for me is mostly server side. Mecrisp is the one embedded-related thing I'd like to try on it (well maybe later develop code intended for a Cortex-M) but it's a small component. Anyway at $3 a month I can afford a server like this just for messing around, at least for a while. > When you talk about the entire development system being on the > embedded MSP430 target and then you talk about 7 hour builds, I can > only figure you are living in a different universe than I am. The 7 hour build was totally unrelated to the MSP430 thing. I just mentioned it to get across that a remote server lets you kick off long computing tasks and forget about them til they finish, unlike bogging down your workstation or laptop with such a thing. >> 2) I wanted a 32-bit system to mess with and my laptop has a 64 bit OS. > To develop code for a 16 bit target... Nah, mostly for other things. Also want to figure out how to use LXC containers. > I have no idea what you could be doing that would crash a PC to the > point you need to reinstall the OS. Have too many interfering package installs breaking version dependencies between program, that sort of thing. I want to try out some so-called functional package managers (Guix and NixOS) that try to fix this. But they themselves may interfere with the regular OS installation so I'd rather use a burner machine that I rebuild from scratch easily. >> 4) I'd like to try ARM-specific software like Mecrisp, which has an >> ARM Linux port. > Which you could run on the MSP430 target instead. I don't have the MSP430 target board at the moment. Someone mentioned an MSP430 simulator, and the ARM server might be a good host for that, since if the simulator busy-loops (I don't know if it does), the ARM is low-powered and unshared so it won't waste too many electrons or interfere with other people's work while spinning away. > The $10 MSP430 board is *free* to use once you get in house. It's $18 but then there's the (for me) somewhat significant hurdle of actually connecting it to a computer and getting it to do something. Writing code is easier for me than mucking with hardware. Anyway $18 is 6 months of the ARM server running 24/7. If I shut down the server when I'm not using it (hourly billing), expenditures go to near zero. > A tethered forth is some work to get going and is *exactly* the > dedicated environment with dependencies on both the target and host > that you were saying you wanted to avoid. Yes, if you're going to deal with those dependencies then you might as well go 100% and get all the benefits. > The lack of real documentation is an issue. I have an FPGA/CPU SoC > board I want to work with. If I get that working I will try this next. Cool. I do think the 8266 software is pretty well understood by now. I'm actually more likely to buy the Adafruit board than the Olimex one. I saw a page recently about a TINY Cortex-M0+ / Bluetooth LE module, that looked about like a microSD card. Maybe that's also of interest. Unfortunately I wasn't able to find the URL when I looked for it again, but it will probably turn up.
[toc] | [prev] | [next] | [standalone]
| From | forthisit@gmail.com |
|---|---|
| Date | 2015-11-12 13:47 -0800 |
| Message-ID | <bf462bb9-aff5-4df0-a980-bdad261eabb8@googlegroups.com> |
| In reply to | #43508 |
On Thursday, November 12, 2015 at 3:18:59 PM UTC-6, Paul Rubin wrote: > > There are terminal emulators for everything, e.g. type "terminal > emulator android" into a search engine. There would be in-circuit > programming, so no flash burner. There would have to be a way to > upload/download the flash contents through the terminal port, as hex > dumps or whatever, so you could back it up, use source control, etc. > For backups why not just have two serial ports that can interface to removable flash devices? Normally just one is used, but for backups the second flash device is plugged in. It would be comparable to the old floppy A: & B: drives from ancient PC history. (Doesn't seem so ancient to some of us.) And isn't source control less of an issue for compact, well factored code? I guess it all depends on how much you value having a system that is independent of the continuously changing, and increasingly complex, PC environment.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-12 16:27 -0800 |
| Message-ID | <87k2pmpwvd.fsf@nightsong.com> |
| In reply to | #43510 |
forthisit@gmail.com writes: > For backups why not just have two serial ports that can interface to > removable flash devices? We're talking about an MCU device, maybe not even a board. You might want those extra pins for something, or you might not have them. > And isn't source control less of an issue for compact, well factored > code? Nah, it's a way of life. I use it for everything these days.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-11-12 12:18 -1000 |
| Message-ID | <teOdnfsVq9akjdjLnZ2dnUU7-XGdnZ2d@supernews.com> |
| In reply to | #43508 |
On 11/12/15 11:18 AM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> 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. > > 1. Back in the day (before my time) real development was done on such > systems and people gushed about how productive it was. I have my doubts > but it sounds interesting. The early microcontroller development systems (late 70's and early 80's) included typically floppy disks and a serial port for a dumb terminal. Our Forth support for these (initially microFORTH and later an early variant of polyFORTH) included a full native Forth including a Forth assembler, compiler, editor for source in blocks on the floppies, and source management utilities. As PCs became more popular in the mid-80's the vendors stopped making these development systems and we moved to using the PC as a host. Some Forths actually kept the compiler on the target, using the PC to store and supply the blocks of source. Serial ports were pretty slow then, so compile times for such systems could be quite long. > 2. I don't actually see such a system as the entire development > environment for complicated applications. I see writing the app using a > PC and installing it on the little board along with the pure Forth dev > environment, and delivering it that way to users. The users could then > configure and modify the code if they wanted, without needing specific > PC software. This seems like a reasonable way to (e.g.) set parameters > or put in small patches, that might involve rebuilding the interpreter. > They could also use a PC environment if the internal Forth stuff got to > be too constraining. SwiftX offers approximately that option, with the full-powered development system available on a PC along with the support for interactive testing, and an optional limited compiler on the target capable of changing parameters and settings as well as adding new definitions (usually for testing). It requires only a dumb terminal or terminal emulator for the user interface. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-13 00:28 -0800 |
| Message-ID | <87twoqnw0s.fsf@nightsong.com> |
| In reply to | #43511 |
"Elizabeth D. Rather" <erather@forth.com> writes: > SwiftX offers approximately that option, with the full-powered > development system available on a PC along with the support for > interactive testing, and an optional limited compiler on the target Yeah, that's the kind of thing I had in mind. Thanks!
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-11-11 22:37 -1000 |
| Message-ID | <JdCdnRh5a7BR0tnLnZ2dnUU7-aOdnZ2d@supernews.com> |
| In reply to | #43490 |
On 11/11/15 7:57 PM, rickman wrote: > 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. This conversation spells out exactly why FORTH, Inc. decided to concentrate on PC-hosted interactive cross-compilers. Powerful host support, no problem with source storage, use the editor of your choice, etc. Everything to gain, nothing to lose. >>>> 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. FORTH, Inc. supports all the processors our customers have asked for, including 12 processor families with multiple boards on each. Yes, we do need paying customers: this is not a hobby, we depend on our customers for a living. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-11-12 23:37 -0800 |
| Message-ID | <8d4ba738-1bb0-49f0-a441-ce2a1a4598ab@googlegroups.com> |
| In reply to | #43495 |
On Thursday, November 12, 2015 at 1:37:34 AM UTC-7, Elizabeth D. Rather wrote: > FORTH, Inc. supports all the processors our customers have asked for, > including 12 processor families with multiple boards on each. Yes, we do > need paying customers: this is not a hobby, we depend on our customers > for a living. You don't support the MiniForth/RACE, which was afaik the only Forth processor built in the 20th century by somebody other than Charles Moore. In this case the customer (Testra) also expected to make a living at what they were doing, and so they declined to pay your exorbitant price --- also, as a practical matter, it was obvious that you were going to fail anyway, so any amount of money paid to Forth Inc. would have been wasted.
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2015-11-09 14:19 +0000 |
| Message-ID | <5640ab58$0$23765$e4fe514c@news.xs4all.nl> |
| In reply to | #43387 |
Paul Rubin <no.email@nospam.invalid> writes: >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. This is a situation that is quite common, e.g. in the Renesas chips. ciforth packs a considerable functionality in a few hundred kilobytes of source library. Put that in flash and you have a serious development environment. Part of flash can be used to store the source of the application. There you have it: works with a vt100 terminal. >> 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. In the above situation, the assembler would sit somewhere in the blocks. Forth assemblers can be compact, my 32 bit Pentium I assembler can be <100 lines say 15 blocks. (floating point, sib and all size overrides and 16 bit instructions.) Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2015-11-23 07:47 +0100 |
| Message-ID | <86610tyzxz.fsf@vps34351.public.cloudvps.com> |
| In reply to | #43428 |
Albert van der Horst <albert@spenarnc.xs4all.nl> writes: > Forth assemblers can be compact, my 32 bit Pentium I assembler can be > <100 lines say 15 blocks. (floating point, sib and all size overrides > and 16 bit instructions.) Can I see the source code, please?
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2015-11-23 11:27 +0000 |
| Message-ID | <5652f832$0$23779$e4fe514c@news.xs4all.nl> |
| In reply to | #43667 |
Lars Brinkhoff <lars.spam@nocrew.org> writes: >Albert van der Horst <albert@spenarnc.xs4all.nl> writes: >> Forth assemblers can be compact, my 32 bit Pentium I assembler can be >> <100 lines say 15 blocks. (floating point, sib and all size overrides >> and 16 bit instructions.) >Can I see the source code, please? I is part of the library. Download any ciforth ( lina32 lina64 wina xina) They all have the same .lab file. In order to understand it you need to read the asm part of the doc's and you are well advised to first try programs out with ciasdis 1] that gives decent error messages. (I.e. you can't get through any code that would not be a valid combination of opcodes prefixes and operands in the current mode). The debugged code is accepted by to the built in assembler. The principle (postit-fixup) has been presented in articles in c.l.f and is explained on my website Groetjes Albert 1] the fullblown assembler / disassembler used for reverse engineering colorforth -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2015-11-23 13:43 +0100 |
| Message-ID | <86poz0yjh7.fsf@vps34351.public.cloudvps.com> |
| In reply to | #43669 |
Albert van der Horst write: > Lars Brinkhoff writes: >>Albert van der Horst <albert@spenarnc.xs4all.nl> writes: >>> Forth assemblers can be compact, my 32 bit Pentium I assembler can >>> be <100 lines say 15 blocks. (floating point, sib and all size >>> overrides and 16 bit instructions.) >>Can I see the source code, please? > > I is part of the library. Download any ciforth ( lina32 lina64 wina xina) > They all have the same .lab file. > > The principle (postit-fixup) has been presented in articles in c.l.f > and is explained on my website Thank you, that's very interesting.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-11-08 12:49 -1000 |
| Message-ID | <v-CdnfSQ26AeTKLLnZ2dnUU7-budnZ2d@supernews.com> |
| In reply to | #43384 |
On 11/8/15 10:18 AM, rickman wrote: > 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. > Seriously, try the evaluation version of SwiftX for the MSP. A really solid host environment is the solution for this class of processor. 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 | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-11-08 19:20 -0500 |
| Message-ID | <n1ooo8$1ae$1@dont-email.me> |
| In reply to | #43392 |
On 11/8/2015 5:49 PM, Elizabeth D. Rather wrote: > On 11/8/15 10:18 AM, rickman wrote: >> 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. >> > > Seriously, try the evaluation version of SwiftX for the MSP. A really > solid host environment is the solution for this class of processor. I was very happy with Mecrisp. No special host software required. In fact, the problem I had using it with the PC is the TI driver for flashing the launchpad. It was not signed properly and required jumping through hoops to install which TI doesn't even bother to document in the instructions. So I decided to use a raspberry Pi as the "host" for the TI launchpad and controlled it all from a PC running Putty. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-11-07 23:44 -1000 |
| Message-ID | <xOSdnbJ2Tu_3hKLLnZ2dnUU7-YX46u6z@supernews.com> |
| In reply to | #43344 |
On 11/7/15 9:17 PM, 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. Using doubles unnecessarily on a 32-bit host is a minor extravagance. It's up to you to decide whether doing so gives you the element of portability that justifies it. Often it does. >> 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. Really, having to rely on external tools is a PITA. And quite unnecessary. >> 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. They did what they could because that was the only option. Now that we have the ability to have truly interactive cross-compilers that are powerful enough to generate well-optimized code there's no need to hobble yourself in that way. 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 | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2015-11-08 18:23 +0000 |
| Message-ID | <563f9314$0$23846$e4fe514c@news.xs4all.nl> |
| In reply to | #43342 |
Paul Rubin <no.email@nospam.invalid> writes:
>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.
ciforth is probably the most notable ISO system written in assembler.
It doesn't depend on a non-Forth assembler. Assemblers are exchangable.
The build system of ciforth can switch between fasm, nasm, masm and gas.
fasm is the best of all. The "bloated dependency" amounts to
fasm lina64.fas
Okay if you insists on using a microsoft assembler, that is only supplied
hidden inside a C++ integrated development ideology, that is bloated.
Apart from such abominations, an assembler is the most non-bloated
tool around that creates programs.
I find it very hard to imagine an assembler that doesn't relies on
stuff running on a host computer, in particular files (punched tape?)
Groetjes Albert
P.S. My build system is involved, but not bloated. It generates executables,
tests and fitting(!) documentation for a number of Forth's.
It uses tools like texinfo, m4, grep, sort, make.
If I replace >IN by PP@@ it shows up in the documentation on the right
alphabetical spot. If I want a new wordlist OBSOLETE and move WORD and
FIND there, I must of course write documentation for that wordlist.
The remainder of the work is changes at two lines. The regression test
reassures that nothing much went wrong.
Groetjes ALbert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-08 10:32 -0800 |
| Message-ID | <87vb9ctk8q.fsf@nightsong.com> |
| In reply to | #43376 |
Albert van der Horst <albert@spenarnc.xs4all.nl> writes: > I find it very hard to imagine an assembler that doesn't relies on > stuff running on a host computer, in particular files (punched tape?) I thought almost all small Forths contained their own assemblers, for example to be able to interactively define CODE words. I forgot about that last night. But once you have that, why not use it for building? Maybe it comes down to aesthetics. Metacompilation vs asm bootstrapping is a reasonable technical discussion with practical arguments on both sides, but I see metacompilation as one of the fiendishly clever techniques that makes Forth interesting. A Forth written for enjoyment from this perspective should certainly use it, come what may.
[toc] | [prev] | [next] | [standalone]
Page 3 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