Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #19218 > unrolled thread
| Started by | Lauri Alanko <la@iki.fi> |
|---|---|
| First post | 2013-01-28 11:54 +0000 |
| Last post | 2013-02-04 23:18 -0800 |
| Articles | 20 on this page of 79 — 22 participants |
Back to article view | Back to comp.lang.forth
Offline compilation of Forth Lauri Alanko <la@iki.fi> - 2013-01-28 11:54 +0000
Re: Offline compilation of Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2013-01-28 17:19 +0000
Re: Offline compilation of Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-28 22:08 +0100
Re: Offline compilation of Forth "Peter Knaggs" <pjk@bcs.org.uk> - 2013-02-03 10:50 +0000
Re: Offline compilation of Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2013-02-03 12:11 +0000
Re: Offline compilation of Forth "A. K." <akk@nospam.org> - 2013-02-03 14:59 +0100
Re: Offline compilation of Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-03 15:14 +0100
Re: Offline compilation of Forth Hannu Vuolasaho <hannu.vuolasaho@nospam.tut.fi.invalid> - 2013-02-03 15:25 +0000
Re: Offline compilation of Forth Gary Bergstrom <g.bergstrom@ieee.org> - 2013-02-05 08:13 -0800
Re: Offline compilation of Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-04 16:23 +0000
Re: Offline compilation of Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-01-28 12:26 -1000
Re: Offline compilation of Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-29 08:55 +0000
Re: Offline compilation of Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-29 17:49 +0100
Re: Offline compilation of Forth Paul Rubin <no.email@nospam.invalid> - 2013-01-30 00:42 -0800
Re: Offline compilation of Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2013-01-30 11:58 +0000
Re: Offline compilation of Forth Mark Wills <forthfreak@gmail.com> - 2013-01-30 23:16 -0800
Re: Offline compilation of Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-01-31 13:29 +0000
Re: Offline compilation of Forth "Ed" <invalid@nospam.com> - 2013-02-03 12:49 +1100
Re: Offline compilation of Forth "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2013-02-14 20:37 -0800
Re: Offline compilation of Forth mhx@iae.nl (Marcel Hendrix) - 2013-02-03 21:15 +0200
Re: Offline compilation of Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-04 02:04 +0100
Re: Offline compilation of Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2013-02-04 13:22 +0000
Re: Offline compilation of Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-04 20:07 +0100
Re: Offline compilation of Forth mhx@iae.nl (Marcel Hendrix) - 2013-02-04 23:07 +0200
Re: Offline compilation of Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-05 18:33 +0100
Re: Offline compilation of Forth mhx@iae.nl (Marcel Hendrix) - 2013-02-06 22:53 +0200
Re: Offline compilation of Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-07 00:30 +0100
Re: Offline compilation of Forth Paul Rubin <no.email@nospam.invalid> - 2013-01-30 00:36 -0800
Re: Offline compilation of Forth Lauri Alanko <la@iki.fi> - 2013-01-30 18:12 +0000
Re: Offline compilation of Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-01-30 09:36 -1000
Re: Offline compilation of Forth "A. K." <akk@nospam.org> - 2013-01-31 07:45 +0100
Re: Offline compilation of Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-31 03:37 -0600
Re: Offline compilation of Forth Lauri Alanko <la@iki.fi> - 2013-02-01 00:01 +0000
Re: Offline compilation of Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-01-31 14:59 -1000
Re: Offline compilation of Forth Lauri Alanko <la@iki.fi> - 2013-02-05 15:17 +0000
Re: Offline compilation of Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-05 10:46 -0600
Re: Offline compilation of Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-05 18:47 +0100
Re: Offline compilation of Forth "Ed" <invalid@nospam.com> - 2013-01-31 21:47 +1100
Re: Offline compilation of Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-31 06:12 -0600
Re: Offline compilation of Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-01-31 13:32 +0000
Re: Offline compilation of Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-01-31 08:27 -1000
Re: Offline compilation of Forth "Ed" <invalid@nospam.com> - 2013-02-01 10:23 +1100
Re: Offline compilation of Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-01-31 13:53 -1000
Re: Offline compilation of Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-01 03:17 +0000
Re: Offline compilation of Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-01-31 18:43 -1000
Re: Offline compilation of Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-01 08:45 -0800
Re: Offline compilation of Forth Mark Wills <forthfreak@gmail.com> - 2013-01-31 23:05 -0800
Re: Offline compilation of Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-01-31 21:25 -1000
Re: Offline compilation of Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-01 08:55 -0800
Re: Offline compilation of Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-01 09:18 -1000
Re: Offline compilation of Forth Mark Wills <forthfreak@gmail.com> - 2013-02-01 13:04 -0800
Re: Offline compilation of Forth "Ed" <invalid@nospam.com> - 2013-02-03 11:20 +1100
Re: Offline compilation of Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2013-02-03 12:20 +0000
Re: Offline compilation of Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-03 07:22 -0800
Re: Offline compilation of Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2013-02-03 17:54 +0000
Re: Offline compilation of Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-03 10:17 -0800
Re: Offline compilation of Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-03 19:33 +0000
Re: Offline compilation of Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-03 11:53 -0800
Re: Offline compilation of Forth Coos Haak <chforth@hccnet.nl> - 2013-02-04 00:59 +0100
Re: Offline compilation of Forth Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-02-04 11:38 +0100
Re: Offline compilation of Forth Brad Eckert <hwfwguy@gmail.com> - 2013-02-06 09:13 -0800
Re: Offline compilation of Forth "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2013-02-14 21:02 -0800
Re: Offline compilation of Forth "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2013-02-14 20:55 -0800
Re: Offline compilation of Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-03 08:26 -1000
Re: Offline compilation of Forth "Ed" <invalid@nospam.com> - 2013-02-05 13:04 +1100
Re: Offline compilation of Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2013-02-05 10:33 +0000
Re: Offline compilation of Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-05 08:56 -1000
Re: Offline compilation of Forth "Ed" <invalid@nospam.com> - 2013-02-08 02:07 +1100
Re: Offline compilation of Forth Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2013-02-07 19:03 +0100
Re: Offline compilation of Forth "Ed" <invalid@nospam.com> - 2013-02-09 22:45 +1100
Re: Offline compilation of Forth Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2013-02-09 18:56 +0100
Re: Offline compilation of Forth Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2013-02-11 00:19 +0100
Re: Offline compilation of Forth Alex McDonald <blog@rivadpm.com> - 2013-02-09 11:59 -0800
Re: Offline compilation of Forth "Ed" <invalid@nospam.com> - 2013-02-13 13:13 +1100
Re: Offline compilation of Forth Alex McDonald <blog@rivadpm.com> - 2013-02-12 19:19 -0800
Re: Offline compilation of Forth "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2013-02-14 21:01 -0800
Re: Offline compilation of Forth Roberto Waltman <usenet@rwaltman.com> - 2013-02-03 16:26 -0500
Re: Offline compilation of Forth "Ed" <invalid@nospam.com> - 2013-02-05 15:32 +1100
Re: Offline compilation of Forth Mark Wills <forthfreak@gmail.com> - 2013-02-04 23:18 -0800
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2013-01-31 08:27 -1000 |
| Message-ID | <ooydnRmabYDkKpfMnZ2dnUVZ_j-dnZ2d@supernews.com> |
| In reply to | #19309 |
On 1/31/13 2:12 AM, Andrew Haley wrote: > Ed <invalid@nospam.com> wrote: >> >> Does one *need* to have the Forth compiler/interpreter in the final >> application? In my experience, almost never. > > It depends what you're doing. An open interpreter can be really > useful: OpenBoot is a good example. So are application-oriented > languages used for, say, sequence control. The strength of the original NRAO data acquisitions systems was that the scientists could type in new definitions to modify their analysis, or even just simplify or customize procedures. That system was in use (evolving, of course) for 20 years. Since then we've seen many applications which benefited by being open for new capabilities, either by regular users (assuming the "regular users" were knowledgeable and trusted) or maintainers who obtain access by invoking special commands or procedures. But even when there is no need for access to the development tools in the finished product, there's no harm in leaving them there assuming you don't have space issues, because the total system is still likely to be very modest in size. 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 | "Ed" <invalid@nospam.com> |
|---|---|
| Date | 2013-02-01 10:23 +1100 |
| Message-ID | <keeuek$jrc$1@speranza.aioe.org> |
| In reply to | #19321 |
Elizabeth D. Rather wrote: > ... > But even when there is no need for access to the development tools in > the finished product, there's no harm in leaving them there assuming you > don't have space issues, because the total system is still likely to be > very modest in size. But what isn't needed - isn't needed. I'm not sure what you mean by modest. I balk at having to download a 0.5 - 2 Mb (or more) ANS-Forth executable just to run a program that could be effected in 100 Kb. In my system a 5K executable bloats to 22K if the compiler and assembler is saved. I see no point lugging around the compiler if I'm rarely going to use it. Of course, most forth systems don't offer you the choice.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2013-01-31 13:53 -1000 |
| Message-ID | <_7-dnT_tDeB0npbMnZ2dnUVZ_qKdnZ2d@supernews.com> |
| In reply to | #19333 |
On 1/31/13 1:23 PM, Ed wrote: > Elizabeth D. Rather wrote: >> ... >> But even when there is no need for access to the development tools in >> the finished product, there's no harm in leaving them there assuming you >> don't have space issues, because the total system is still likely to be >> very modest in size. > > But what isn't needed - isn't needed. > > I'm not sure what you mean by modest. I balk at having to download > a 0.5 - 2 Mb (or more) ANS-Forth executable just to run a program > that could be effected in 100 Kb. In my system a 5K executable > bloats to 22K if the compiler and assembler is saved. > > I see no point lugging around the compiler if I'm rarely going to use it. > Of course, most forth systems don't offer you the choice. It's all a matter of perspective. Most PC programs are multi-Mb images. The several SwiftForth apps I'm familiar with are ~400Kb including all of SwiftForth, and launch instantaneously, and no one really notices. With SwiftX, we do offer the option to have a compiler in the target or not, and I think for embedded systems it is appropriate to have the option. 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@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2013-02-01 03:17 +0000 |
| Message-ID | <510b33ba$0$6330$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #19334 |
In article <_7-dnT_tDeB0npbMnZ2dnUVZ_qKdnZ2d@supernews.com>, Elizabeth D. Rather <erather@forth.com> wrote: >On 1/31/13 1:23 PM, Ed wrote: >> Elizabeth D. Rather wrote: >>> ... >>> But even when there is no need for access to the development tools in >>> the finished product, there's no harm in leaving them there assuming you >>> don't have space issues, because the total system is still likely to be >>> very modest in size. >> >> But what isn't needed - isn't needed. >> >> I'm not sure what you mean by modest. I balk at having to download >> a 0.5 - 2 Mb (or more) ANS-Forth executable just to run a program >> that could be effected in 100 Kb. In my system a 5K executable >> bloats to 22K if the compiler and assembler is saved. >> >> I see no point lugging around the compiler if I'm rarely going to use it. >> Of course, most forth systems don't offer you the choice. > >It's all a matter of perspective. Most PC programs are multi-Mb images. >The several SwiftForth apps I'm familiar with are ~400Kb including all >of SwiftForth, and launch instantaneously, and no one really notices. >With SwiftX, we do offer the option to have a compiler in the target or >not, and I think for embedded systems it is appropriate to have the option. Still, suppose I use the Launchpad for a simple task (a light dimmer, drawing the curtains, doing the air in my fish tank). With noforth, compiler assembler, application and all, you have a couple dozen kbyte of flash to spare, for 5 euro. So umbilical systems come into play for industrial settings where unit prize becomes important. > >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." >================================================== -- 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 | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2013-01-31 18:43 -1000 |
| Message-ID | <pOydnS1RLdRo2pbMnZ2dnUVZ_jCdnZ2d@supernews.com> |
| In reply to | #19337 |
On 1/31/13 5:17 PM, Albert van der Horst wrote: > In article <_7-dnT_tDeB0npbMnZ2dnUVZ_qKdnZ2d@supernews.com>, > Elizabeth D. Rather <erather@forth.com> wrote: >> On 1/31/13 1:23 PM, Ed wrote: >>> Elizabeth D. Rather wrote: >>>> ... >>>> But even when there is no need for access to the development tools in >>>> the finished product, there's no harm in leaving them there assuming you >>>> don't have space issues, because the total system is still likely to be >>>> very modest in size. >>> >>> But what isn't needed - isn't needed. >>> >>> I'm not sure what you mean by modest. I balk at having to download >>> a 0.5 - 2 Mb (or more) ANS-Forth executable just to run a program >>> that could be effected in 100 Kb. In my system a 5K executable >>> bloats to 22K if the compiler and assembler is saved. >>> >>> I see no point lugging around the compiler if I'm rarely going to use it. >>> Of course, most forth systems don't offer you the choice. >> >> It's all a matter of perspective. Most PC programs are multi-Mb images. >> The several SwiftForth apps I'm familiar with are ~400Kb including all >> of SwiftForth, and launch instantaneously, and no one really notices. >> With SwiftX, we do offer the option to have a compiler in the target or >> not, and I think for embedded systems it is appropriate to have the option. > > Still, suppose I use the Launchpad for a simple task (a light dimmer, > drawing the curtains, doing the air in my fish tank). > With noforth, compiler assembler, application and all, you have a couple > dozen kbyte of flash to spare, for 5 euro. > So umbilical systems come into play for industrial settings where unit > prize becomes important. Yes, absolutely. 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 | 2013-02-01 08:45 -0800 |
| Message-ID | <7xwqusf0ed.fsf@ruckus.brouhaha.com> |
| In reply to | #19337 |
albert@spenarnc.xs4all.nl (Albert van der Horst) writes: > Still, suppose I use the Launchpad for a simple task (a light dimmer, > drawing the curtains, doing the air in my fish tank). With noforth, > compiler assembler, application and all, you have a couple dozen kbyte > of flash to spare, for 5 euro. So umbilical systems come into play > for industrial settings where unit prize becomes important. You mean this? http://home.hccnet.nl/anij/nof/noforth.html Looks like there's about 8k flash and 256 bytes ram free without the assembler resident. Still pretty good. And for not much more cost there's a much bigger Launchpad (the ARM M4 version), 256k flash and 32k ram for around 10 Euro. I got two of those for 5 USD each when they were on promotion.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <forthfreak@gmail.com> |
|---|---|
| Date | 2013-01-31 23:05 -0800 |
| Message-ID | <2831888c-d434-4b38-8eb8-f0fa5ff787b9@r14g2000yqe.googlegroups.com> |
| In reply to | #19334 |
On Jan 31, 11:53 pm, "Elizabeth D. Rather" <erat...@forth.com> wrote: > On 1/31/13 1:23 PM, Ed wrote: > > > > > > > Elizabeth D. Rather wrote: > >> ... > >> But even when there is no need for access to the development tools in > >> the finished product, there's no harm in leaving them there assuming you > >> don't have space issues, because the total system is still likely to be > >> very modest in size. > > > But what isn't needed - isn't needed. > > > I'm not sure what you mean by modest. I balk at having to download > > a 0.5 - 2 Mb (or more) ANS-Forth executable just to run a program > > that could be effected in 100 Kb. In my system a 5K executable > > bloats to 22K if the compiler and assembler is saved. > > > I see no point lugging around the compiler if I'm rarely going to use it. > > Of course, most forth systems don't offer you the choice. > > It's all a matter of perspective. Most PC programs are multi-Mb images. > The several SwiftForth apps I'm familiar with are ~400Kb including all > of SwiftForth, and launch instantaneously, and no one really notices. > With SwiftX, we do offer the option to have a compiler in the target or > not, and I think for embedded systems it is appropriate to have the option. > > 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 90045http://www.forth.com > > "Forth-based products and Services for real-time > applications since 1973." > ==================================================- Hide quoted text - > > - Show quoted text - It's a nice to have. Sure, I guess if there's space, and hosting the interpreter/compiler as a separate task doesn't impact too much on the performance of the application too much it might be useful in early production runs of an embedded product, where you *think* it's all debugged and tickety-boo but would really like to clock up some hours in the field first! I remember back in the early 90's we designed some embedded DC rectifier controllers running off of an RS485 multi-drop. It all worked like a champ in our setup, but there were problems in the field. Fortunately, we had left the terminal task in the production code, (the uControllers were K4's from MicroRobotics in Cambridge, England) so we could attach a portable computer (it's wasn't really a 'laptop'!) and leave it capturing the output from the serial port via a VT100 emulator. If I remember correctly the bug was eventually traced back to a task that was writing to a global without locking the global first (so it could be part way through writing to the global (being a multi-byte floating-point value) and another task could be reading it at the same time, and read garbage. Schoolboy error. Very hard to trace. Anyway, having the terminal in there saved us. These days, I'd say security, or legal liability is possibly the overriding factor rather than memory space. Could the terminal be used for malicious purposes? Or, if someone re-maps the ignition timing on their sports car and blows the engine, will he come back and sue you because you made it possible?
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2013-01-31 21:25 -1000 |
| Message-ID | <RLednQAeNN5K8JbMnZ2dnUVZ_gqdnZ2d@supernews.com> |
| In reply to | #19341 |
On 1/31/13 9:05 PM, Mark Wills wrote: > On Jan 31, 11:53 pm, "Elizabeth D. Rather" <erat...@forth.com> wrote: >> On 1/31/13 1:23 PM, Ed wrote: >>> Elizabeth D. Rather wrote: >>>> ... >>>> But even when there is no need for access to the development tools in >>>> the finished product, there's no harm in leaving them there assuming you >>>> don't have space issues, because the total system is still likely to be >>>> very modest in size. >> >>> But what isn't needed - isn't needed. >> >>> I'm not sure what you mean by modest. I balk at having to download >>> a 0.5 - 2 Mb (or more) ANS-Forth executable just to run a program >>> that could be effected in 100 Kb. In my system a 5K executable >>> bloats to 22K if the compiler and assembler is saved. >> >>> I see no point lugging around the compiler if I'm rarely going to use it. >>> Of course, most forth systems don't offer you the choice. >> >> It's all a matter of perspective. Most PC programs are multi-Mb images. >> The several SwiftForth apps I'm familiar with are ~400Kb including all >> of SwiftForth, and launch instantaneously, and no one really notices. >> With SwiftX, we do offer the option to have a compiler in the target or >> not, and I think for embedded systems it is appropriate to have the option. > > It's a nice to have. Sure, I guess if there's space, and hosting the > interpreter/compiler as a separate task doesn't impact too much on the > performance of the application too much it might be useful in early > production runs of an embedded product, where you *think* it's all > debugged and tickety-boo but would really like to clock up some hours > in the field first! It has zero impact if no one's typing to it. > I remember back in the early 90's we designed some embedded DC > rectifier controllers running off of an RS485 multi-drop. It all > worked like a champ in our setup, but there were problems in the > field. Fortunately, we had left the terminal task in the production > code, (the uControllers were K4's from MicroRobotics in Cambridge, > England) so we could attach a portable computer (it's wasn't really a > 'laptop'!) and leave it capturing the output from the serial port via > a VT100 emulator. > > If I remember correctly the bug was eventually traced back to a task > that was writing to a global without locking the global first (so it > could be part way through writing to the global (being a multi-byte > floating-point value) and another task could be reading it at the same > time, and read garbage. Schoolboy error. Very hard to trace. > > Anyway, having the terminal in there saved us. A familiar story :-) > These days, I'd say security, or legal liability is possibly the > overriding factor rather than memory space. Could the terminal be used > for malicious purposes? Or, if someone re-maps the ignition timing on > their sports car and blows the engine, will he come back and sue you > because you made it possible? It's really easy to secure access to the underlying Forth by a variety of means, of which the simplest is simply placing its wordlist behind a password. 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 | 2013-02-01 08:55 -0800 |
| Message-ID | <7x7gmskm7m.fsf@ruckus.brouhaha.com> |
| In reply to | #19341 |
Mark Wills <forthfreak@gmail.com> writes: > If I remember correctly the bug was eventually traced back to a task > that was writing to a global without locking the global first (so it > could be part way through writing to the global (being a multi-byte > floating-point value) and another task could be reading it at the same > time, and read garbage. Schoolboy error. Very hard to trace. Was this traditional Forth cooperative multitasking? I thought the cooperative switching was suppose to prevent that sort of problem.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2013-02-01 09:18 -1000 |
| Message-ID | <f_GdnWA64f2EiJHMnZ2dnUVZ_rSdnZ2d@supernews.com> |
| In reply to | #19355 |
On 2/1/13 6:55 AM, Paul Rubin wrote: > Mark Wills <forthfreak@gmail.com> writes: >> If I remember correctly the bug was eventually traced back to a task >> that was writing to a global without locking the global first (so it >> could be part way through writing to the global (being a multi-byte >> floating-point value) and another task could be reading it at the same >> time, and read garbage. Schoolboy error. Very hard to trace. > > Was this traditional Forth cooperative multitasking? I thought the > cooperative switching was suppose to prevent that sort of problem. > Doesn't sound like it. And, yes, the cooperative model would not have this problem. 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 | Mark Wills <forthfreak@gmail.com> |
|---|---|
| Date | 2013-02-01 13:04 -0800 |
| Message-ID | <d124e0c5-f165-467b-9e90-f87fb2f70194@4g2000yqv.googlegroups.com> |
| In reply to | #19356 |
On Feb 1, 7:18 pm, "Elizabeth D. Rather" <erat...@forth.com> wrote: > On 2/1/13 6:55 AM, Paul Rubin wrote: > > > Mark Wills <forthfr...@gmail.com> writes: > >> If I remember correctly the bug was eventually traced back to a task > >> that was writing to a global without locking the global first (so it > >> could be part way through writing to the global (being a multi-byte > >> floating-point value) and another task could be reading it at the same > >> time, and read garbage. Schoolboy error. Very hard to trace. > > > Was this traditional Forth cooperative multitasking? I thought the > > cooperative switching was suppose to prevent that sort of problem. > > Doesn't sound like it. And, yes, the cooperative model would not have > this problem. > > 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 90045http://www.forth.com > > "Forth-based products and Services for real-time > applications since 1973." > ================================================== No t wasn't forth, it was a language called Venom, and it was preemptive. Mark
[toc] | [prev] | [next] | [standalone]
| From | "Ed" <invalid@nospam.com> |
|---|---|
| Date | 2013-02-03 11:20 +1100 |
| Message-ID | <kekahn$5cr$1@speranza.aioe.org> |
| In reply to | #19334 |
Elizabeth D. Rather wrote: > On 1/31/13 1:23 PM, Ed wrote: > > Elizabeth D. Rather wrote: > >> ... > >> But even when there is no need for access to the development tools in > >> the finished product, there's no harm in leaving them there assuming you > >> don't have space issues, because the total system is still likely to be > >> very modest in size. > > > > But what isn't needed - isn't needed. > > > > I'm not sure what you mean by modest. I balk at having to download > > a 0.5 - 2 Mb (or more) ANS-Forth executable just to run a program > > that could be effected in 100 Kb. In my system a 5K executable > > bloats to 22K if the compiler and assembler is saved. > > > > I see no point lugging around the compiler if I'm rarely going to use it. > > Of course, most forth systems don't offer you the choice. > > It's all a matter of perspective. Most PC programs are multi-Mb images. > The several SwiftForth apps I'm familiar with are ~400Kb including all > of SwiftForth, and launch instantaneously, and no one really notices. > With SwiftX, we do offer the option to have a compiler in the target or > not, and I think for embedded systems it is appropriate to have the option. I imagine the onboard target compiler SwiftX installs would be very cut down and/or requires SwiftX as the host. I would say the option to generate compilerless turnkeys should be available all systems - particularly the large Forth systems of today. If the *only* reason they generate 400 Kb "Hello World" executables (800 Kb in the case of SwiftForth) is because they're using 1970's implementation methods, then perhaps it's time for a re-think. Strategies for keeping the compiler separate from the code it generates have been around since at least the 1980's.
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2013-02-03 12:20 +0000 |
| Message-ID | <510e5448.768542997@192.168.0.50> |
| In reply to | #19378 |
On Sun, 3 Feb 2013 11:20:36 +1100, "Ed" <invalid@nospam.com> wrote: >I would say the option to generate compilerless turnkeys should be >available all systems - particularly the large Forth systems of today. >If the *only* reason they generate 400 Kb "Hello World" executables >(800 Kb in the case of SwiftForth) is because they're using 1970's >implementation methods, then perhaps it's time for a re-think. >Strategies for keeping the compiler separate from the code it >generates have been around since at least the 1980's. But why? If ultimate performance is your goal, then there is merit in keeping applications smaller than the size of the cache. Otherwise, on computers with 1Gb or more of RAM, and the largest desktop Forth app I know of being 22Mb plus a few DLLs, we can say that Forth apps occupy less than 2.5% of the available RAM. Why on earth should I worry about the size of the Forth kernel? I certainly do worry about memory usage in embedded systems, but there I worry about RAM usage, not about code size. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-02-03 07:22 -0800 |
| Message-ID | <7xk3qpe81h.fsf@ruckus.brouhaha.com> |
| In reply to | #19383 |
stephenXXX@mpeforth.com (Stephen Pelc) writes: > I certainly do worry about memory usage in embedded systems, but > there I worry about RAM usage, not about code size. When I think of cross-compilation, one target that immediately comes to mind is the smaller of the two TI MSP430 Launchpad processors, with 2k of program flash and 128 bytes of ram. That certainly seems reasonable to cross-compile for, but awfully constrained for a resident interpreter. Even the bigger cpu (16k flash, 512 bytes ram) leads to a rather stripped down interpreter (4e4th tries to fit in 8k of the flash to leave the other 8k for user code).
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2013-02-03 17:54 +0000 |
| Message-ID | <510ea1a2.788345077@192.168.0.50> |
| In reply to | #19390 |
On Sun, 03 Feb 2013 07:22:50 -0800, Paul Rubin <no.email@nospam.invalid> wrote: >stephenXXX@mpeforth.com (Stephen Pelc) writes: >> I certainly do worry about memory usage in embedded systems, but >> there I worry about RAM usage, not about code size. > >When I think of cross-compilation, one target that immediately comes >to mind is the smaller of the two TI MSP430 Launchpad processors, with >2k of program flash and 128 bytes of ram. That certainly seems >reasonable to cross-compile for, but awfully constrained for a resident >interpreter. There's a reason why the Forth vendors developed Umbilical Forths. ANd your point is? I have never claimed that one should fit a resident interpreter on such a CPU. These days, one should use a CPU on which one can fit a resident interpreter. Add there are such devices with power consumption similar to or better than low-end MSP430s. >Even the bigger cpu (16k flash, 512 bytes ram) leads >to a rather stripped down interpreter (4e4th tries to fit in 8k of >the flash to leave the other 8k for user code). So use a bigger CPU? One problem with the discussion about resident Forths on Launchpads is that it's the usual fatuous assumption that cheaper is better. The underfunded education world has a reason to need cheap, but a far better long-term solution is to fund education properly. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-02-03 10:17 -0800 |
| Message-ID | <7xboc145z0.fsf@ruckus.brouhaha.com> |
| In reply to | #19399 |
stephenXXX@mpeforth.com (Stephen Pelc) writes: > ANd your point is? I have never claimed that one should fit a resident > interpreter on such a CPU. These days, one should use a CPU on which > one can fit a resident interpreter. Add there are such devices with > power consumption similar to or better than low-end MSP430s. Hmm, I've been trying to figure out what some of those devices are, especially in very small physical packages. Any suggestions are welcome. > One problem with the discussion about resident Forths on Launchpads > is that it's the usual fatuous assumption that cheaper is better. Well, the MSP430 Launchpad fits nicely with Forth's minimalistic spirit and I think people like it for that reason. And for products being made in quantity, the cost of parts actually matters. Even when cost doesn't matter much, package size and power consumption can still matter. Even for a working nerd though, the cheap Launchpad has its attractions. I like the idea of a board I can buy a handful of without really noticing the cost, so I can build them them into places where they won't get much glory. As an educational Forth target, a bigger cpu (Stellaris Launchpad or STM Discovery) allows much more code and is probably still cheap enough, but why stop there? Why not a Raspberry Pi, or for that matter a desktop software application? As an alternative (higher cost) MSP430 board to the Launchpad, this looks nice: https://www.olimex.com/Products/MSP430/Header/MSP430-HFR5739/ Its interesting feature is 16k of nonvolatile ferromagnetic ram (FRAM). I can hardly wait for FRAM memories to get bigger.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2013-02-03 19:33 +0000 |
| Message-ID | <510ebb93$0$6052$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #19399 |
In article <510ea1a2.788345077@192.168.0.50>, Stephen Pelc <stephenXXX@INVALID.mpeforth.com> wrote: >On Sun, 03 Feb 2013 07:22:50 -0800, Paul Rubin ><no.email@nospam.invalid> wrote: > >>stephenXXX@mpeforth.com (Stephen Pelc) writes: >>> I certainly do worry about memory usage in embedded systems, but >>> there I worry about RAM usage, not about code size. >> >>When I think of cross-compilation, one target that immediately comes >>to mind is the smaller of the two TI MSP430 Launchpad processors, with >>2k of program flash and 128 bytes of ram. That certainly seems >>reasonable to cross-compile for, but awfully constrained for a resident >>interpreter. > >There's a reason why the Forth vendors developed Umbilical Forths. > >ANd your point is? I have never claimed that one should fit a resident >interpreter on such a CPU. These days, one should use a CPU on which >one can fit a resident interpreter. Add there are such devices with >power consumption similar to or better than low-end MSP430s. > >>Even the bigger cpu (16k flash, 512 bytes ram) leads >>to a rather stripped down interpreter (4e4th tries to fit in 8k of >>the flash to leave the other 8k for user code). > >So use a bigger CPU? > >One problem with the discussion about resident Forths on Launchpads >is that it's the usual fatuous assumption that cheaper is better. >The underfunded education world has a reason to need cheap, but >a far better long-term solution is to fund education properly. I couldn't agree more, but truth of the matter is, for the Launchpad noforth delivers a workable interpreter with decent tools, and 256 bytes RAM left for decent applications. Albert Nijhof demonstrated a musical interpreter, playing quite sizable pieces of music at our december meeting. There is a whole world of electronic hobbyists to win over, where the cost to entry should be as low as possible. > >Stephen 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 | 2013-02-03 11:53 -0800 |
| Message-ID | <7xr4kxnph3.fsf@ruckus.brouhaha.com> |
| In reply to | #19404 |
albert@spenarnc.xs4all.nl (Albert van der Horst) writes: > I couldn't agree more, but truth of the matter is, for the Launchpad > noforth delivers a workable interpreter with decent tools, and 256 bytes > RAM left for decent applications. I'm having a hard time finding info about noforth. Got any links? Thanks!
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2013-02-04 00:59 +0100 |
| Message-ID | <v5o16nehyqdn.1ohgte2jyjvky.dlg@40tude.net> |
| In reply to | #19405 |
Op Sun, 03 Feb 2013 11:53:44 -0800 schreef Paul Rubin: > albert@spenarnc.xs4all.nl (Albert van der Horst) writes: >> I couldn't agree more, but truth of the matter is, for the Launchpad >> noforth delivers a workable interpreter with decent tools, and 256 bytes >> RAM left for decent applications. > > I'm having a hard time finding info about noforth. Got any links? > Thanks! http://www.forth.hcc.nl/w/WerkgroepMSP/WerkgroepMSP -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | Matthias Koch <matthias.koch@hot.uni-hannover.de> |
|---|---|
| Date | 2013-02-04 11:38 +0100 |
| Message-ID | <keo37q$3qo$1@newsserver.rrzn.uni-hannover.de> |
| In reply to | #19404 |
Besides noforth and 4e4th, I wrote an optimizing native code Forth implementation that runs in MSP430G2553 chips and reached stable on Christmas 2012. http://mecrisp.sourceforge.net/ Matthias Koch
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.lang.forth
csiph-web