Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.forth > #41632 > unrolled thread

Could Forth be getting a bit of traction?

Started byMark Wills <markwills1970@gmail.com>
First post2015-09-01 00:49 -0700
Last post2015-10-06 01:37 -0400
Articles 20 on this page of 132 — 35 participants

Back to article view | Back to comp.lang.forth


Contents

  Could Forth be getting a bit of traction? Mark Wills <markwills1970@gmail.com> - 2015-09-01 00:49 -0700
    Re: Could Forth be getting a bit of traction? mentificium@gmail.com - 2015-09-01 04:18 -0700
    Re: Could Forth be getting a bit of traction? Steve Graham <jsgrahamus@yahoo.com> - 2015-09-01 09:51 -0700
    Re: Could Forth be getting a bit of traction? Andreas Wagner <andreas.wagner@lowfatcomputing.org> - 2015-09-01 10:23 -0700
      Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-02 13:53 -0700
        Re: Could Forth be getting a bit of traction? Greg <borota@gmail.com> - 2015-09-04 17:35 -0700
          Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-04 18:27 -0700
            Re: Could Forth be getting a bit of traction? Mux <Yvo.Zoer@gmail.com> - 2015-09-04 21:04 -0700
              Re: Could Forth be getting a bit of traction? rickman <gnuarm@gmail.com> - 2015-09-05 00:27 -0400
              Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-04 21:48 -0700
                Re: Could Forth be getting a bit of traction? rickman <gnuarm@gmail.com> - 2015-09-05 01:10 -0400
                Re: Could Forth be getting a bit of traction? Mux <Yvo.Zoer@gmail.com> - 2015-09-04 22:19 -0700
                  Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-04 23:31 -0700
                    Re: Could Forth be getting a bit of traction? Mux <Yvo.Zoer@gmail.com> - 2015-09-05 07:28 -0700
                    Re: Could Forth be getting a bit of traction? Alfred Singlestone <vitonis@gmail.com> - 2015-09-05 08:10 -0700
                      Re: Could Forth be getting a bit of traction? foxaudioresearch@gmail.com - 2015-09-05 09:05 -0700
                      Re: Could Forth be getting a bit of traction? visualforth@rocketmail.com - 2015-09-05 09:07 -0700
                        Re: Could Forth be getting a bit of traction? rickman <gnuarm@gmail.com> - 2015-09-05 13:08 -0400
                      Re: Could Forth be getting a bit of traction? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-05 16:32 +0000
                        Re: Could Forth be getting a bit of traction? Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-05 22:19 +0200
                          Re: Could Forth be getting a bit of traction? Jason Damisch <jasondamisch@yahoo.com> - 2015-09-05 13:28 -0700
                          Re: Could Forth be getting a bit of traction? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-06 12:09 +0000
                            Re: Could Forth be getting a bit of traction? Richard Owlett <rowlett@cloud85.net> - 2015-09-06 13:27 -0500
                              Re: Could Forth be getting a bit of traction? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-07 15:36 +0000
                                Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-07 09:46 -0700
                        Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-05 14:20 -0700
                          Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-06 20:52 -0700
                      Re: Could Forth be getting a bit of traction? Mux <Yvo.Zoer@gmail.com> - 2015-09-05 12:11 -0700
                      Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-05 19:56 -0700
                        Re: Could Forth be getting a bit of traction? Greg <borota@gmail.com> - 2015-09-06 09:39 -0700
                          Re: Could Forth be getting a bit of traction? mhx@iae.nl - 2015-09-06 13:01 -0700
                            Re: Could Forth be getting a bit of traction? borota@gmail.com - 2015-09-06 18:48 -0700
                              Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-06 19:43 -0700
                                Re: Could Forth be getting a bit of traction? borota@gmail.com - 2015-09-06 20:59 -0700
                                Re: Could Forth be getting a bit of traction? "WJ" <w_a_x_man@yahoo.com> - 2015-09-08 19:46 +0000
                                  Re: Could Forth be getting a bit of traction? borota@gmail.com - 2015-09-08 13:28 -0700
                                    Re: Could Forth be getting a bit of traction? jim.brakefield@ieee.org - 2015-09-08 17:27 -0700
                                      Re: Could Forth be getting a bit of traction? Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-09 03:35 +0200
                                      Re: Could Forth be getting a bit of traction? Paul Rubin <no.email@nospam.invalid> - 2015-09-08 19:48 -0700
                                        Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-08 20:28 -0700
                                        Re: Could Forth be getting a bit of traction? jim.brakefield@ieee.org - 2015-09-08 20:48 -0700
                                          Re: Could Forth be getting a bit of traction? Paul Rubin <no.email@nospam.invalid> - 2015-09-08 21:00 -0700
                                            Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-08 21:35 -0700
                                          Re: Could Forth be getting a bit of traction? mhx@iae.nl - 2015-09-10 15:20 -0700
                                            Re: Could Forth be getting a bit of traction? jim.brakefield@ieee.org - 2015-09-10 17:26 -0700
                                              Re: Could Forth be getting a bit of traction? "Elizabeth D. Rather" <erather@forth.com> - 2015-09-10 14:57 -1000
                                              Re: Could Forth be getting a bit of traction? julian.fondren@endurance.com - 2015-09-10 20:47 -0700
                                              Re: Could Forth be getting a bit of traction? mhx@iae.nl (Marcel Hendrix) - 2015-09-11 10:49 +0200
                                                Re: Could Forth be getting a bit of traction? jim.brakefield@ieee.org - 2015-09-11 10:16 -0700
                                      Re: Could Forth be getting a bit of traction? Ron Aaron <rambamist@gmail.com> - 2015-09-09 07:42 +0300
                                    Re: Could Forth be getting a bit of traction? rickman <gnuarm@gmail.com> - 2015-09-08 18:41 -0400
                                    Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-08 19:24 -0700
                                    Re: Could Forth be getting a bit of traction? "Elizabeth D. Rather" <erather@forth.com> - 2015-09-08 20:59 -1000
                                      Re: Could Forth be getting a bit of traction? Greg <borota@gmail.com> - 2015-09-09 15:47 -0700
                                        Re: Could Forth be getting a bit of traction? borota@gmail.com - 2015-09-11 08:15 -0700
                                          Re: Could Forth be getting a bit of traction? visualforth@rocketmail.com - 2015-10-04 19:59 -0700
                                            Re: Could Forth be getting a bit of traction? "Elizabeth D. Rather" <erather@forth.com> - 2015-10-04 17:48 -1000
                                              Re: Could Forth be getting a bit of traction? Paul Rubin <no.email@nospam.invalid> - 2015-10-04 21:10 -0700
                                                Re: Could Forth be getting a bit of traction? Roberto Waltman <usenet@rwaltman.com> - 2015-10-05 00:53 -0400
                                                  Re: Could Forth be getting a bit of traction? rickman <gnuarm@gmail.com> - 2015-10-05 03:51 -0400
                                                Re: Could Forth be getting a bit of traction? "Elizabeth D. Rather" <erather@forth.com> - 2015-10-04 18:58 -1000
                                                  Re: Could Forth be getting a bit of traction? Paul Rubin <no.email@nospam.invalid> - 2015-10-04 23:35 -0700
                                                    Re: Could Forth be getting a bit of traction? Paul Rubin <no.email@nospam.invalid> - 2015-10-04 23:44 -0700
                                                      Re: Could Forth be getting a bit of traction? "Elizabeth D. Rather" <erather@forth.com> - 2015-10-05 08:54 -1000
                                                        Re: Could Forth be getting a bit of traction? Paul Rubin <no.email@nospam.invalid> - 2015-10-05 12:58 -0700
                                                        Re: Could Forth be getting a bit of traction? rickman <gnuarm@gmail.com> - 2015-10-06 01:35 -0400
                                                          Re: Could Forth be getting a bit of traction? JUERGEN <epldfpga@aol.com> - 2015-10-06 02:58 -0700
                                                            Re: Could Forth be getting a bit of traction? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-10-06 04:05 -0700
                                                              Re: Could Forth be getting a bit of traction? Mark Wills <markwills1970@gmail.com> - 2015-10-06 04:22 -0700
                                                              Re: Could Forth be getting a bit of traction? JUERGEN <epldfpga@aol.com> - 2015-10-06 15:00 -0700
                                                                Re: Could Forth be getting a bit of traction? Paul Rubin <no.email@nospam.invalid> - 2015-10-06 16:02 -0700
                                                                  Re: Could Forth be getting a bit of traction? Ron Aaron <rambamist@gmail.com> - 2015-10-07 07:49 +0300
                                                              Re: Could Forth be getting a bit of traction? Paul Rubin <no.email@nospam.invalid> - 2015-10-06 15:04 -0700
                                                              Re: Could Forth be getting a bit of traction? Paul Rubin <no.email@nospam.invalid> - 2015-10-09 14:16 -0700
                                                            Re: Could Forth be getting a bit of traction? rickman <gnuarm@gmail.com> - 2015-10-06 09:34 -0400
                                                              Re: Could Forth be getting a bit of traction? "Elizabeth D. Rather" <erather@forth.com> - 2015-10-06 09:08 -1000
                                                          Re: Could Forth be getting a bit of traction? Paul Rubin <no.email@nospam.invalid> - 2015-10-06 20:49 -0700
                                                            Re: Could Forth be getting a bit of traction? rickman <gnuarm@gmail.com> - 2015-10-07 00:56 -0400
                                                              Re: Could Forth be getting a bit of traction? "Elizabeth D. Rather" <erather@forth.com> - 2015-10-06 21:11 -1000
                                                              Re: Could Forth be getting a bit of traction? Paul Rubin <no.email@nospam.invalid> - 2015-10-09 21:07 -0700
                                                                Re: Could Forth be getting a bit of traction? rickman <gnuarm@gmail.com> - 2015-10-10 19:38 -0400
                                                                  Re: Could Forth be getting a bit of traction? Paul Rubin <no.email@nospam.invalid> - 2015-10-10 20:46 -0700
                                                                    Re: Could Forth be getting a bit of traction? rickman <gnuarm@gmail.com> - 2015-10-11 01:16 -0400
                                                                    Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-10-10 22:50 -0700
                                                    Re: Could Forth be getting a bit of traction? "Elizabeth D. Rather" <erather@forth.com> - 2015-10-04 21:21 -1000
                                                      Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-10-05 08:26 -0700
                                                        Re: Could Forth be getting a bit of traction? Alfred Singlestone <vitonis@gmail.com> - 2015-10-06 07:13 -0700
                                    Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-10 00:12 -0700
                              Re: Could Forth be getting a bit of traction? humptydumpty <ouatubi@gmail.com> - 2015-09-08 11:48 -0700
                              Re: Could Forth be getting a bit of traction? "Elizabeth D. Rather" <erather@forth.com> - 2015-09-08 20:55 -1000
                                Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-09 02:28 -0700
                                  Re: Could Forth be getting a bit of traction? november.nihal@gmail.com - 2015-09-09 03:36 -0700
                                  Re: Could Forth be getting a bit of traction? Marek Brunda <marekb@phoenics.org> - 2015-09-09 03:59 -0700
                                    Re: Could Forth be getting a bit of traction? "Elizabeth D. Rather" <erather@forth.com> - 2015-09-09 07:34 -1000
                                      Re: Could Forth be getting a bit of traction? jim.brakefield@ieee.org - 2015-09-09 12:32 -0700
                                      Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-10 17:10 -0700
                                  Re: Could Forth be getting a bit of traction? "WJ" <w_a_x_man@yahoo.com> - 2015-09-09 18:59 +0000
                                  Re: Could Forth be getting a bit of traction? Whammo <sidciavic@gmail.com> - 2015-09-09 12:28 -0700
                            structs/unions/records (was: Could Forth be getting a bit of traction?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-09 07:10 +0000
                              Re: structs/unions/records (was: Could Forth be getting a bit of traction?) hughaguilar96@gmail.com - 2015-09-09 02:18 -0700
                              Re: structs/unions/records rickman <gnuarm@gmail.com> - 2015-09-09 23:27 -0400
                          Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-06 23:18 -0700
                            Re: Could Forth be getting a bit of traction? awegel@arcor.de (Alexander Wegel) - 2015-09-07 12:57 +0200
                              Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-07 09:55 -0700
                                Re: Could Forth be getting a bit of traction? "WJ" <w_a_x_man@yahoo.com> - 2015-09-07 18:45 +0000
                                  Re: Could Forth be getting a bit of traction? awegel@arcor.de (Alexander Wegel) - 2015-09-08 00:13 +0200
                                    Re: Could Forth be getting a bit of traction? Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-08 01:51 +0200
                                Re: Could Forth be getting a bit of traction? awegel@arcor.de (Alexander Wegel) - 2015-09-08 00:13 +0200
                            Re: Could Forth be getting a bit of traction? "WJ" <w_a_x_man@yahoo.com> - 2015-09-07 18:27 +0000
                            Re: Could Forth be getting a bit of traction? borota@gmail.com - 2015-09-07 12:23 -0700
                              Re: Could Forth be getting a bit of traction? rickman <gnuarm@gmail.com> - 2015-09-07 16:14 -0400
                              Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-07 17:39 -0700
                                Re: Could Forth be getting a bit of traction? rickman <gnuarm@gmail.com> - 2015-09-08 01:39 -0400
                  Re: Could Forth be getting a bit of traction? rickman <gnuarm@gmail.com> - 2015-09-05 03:12 -0400
                    Re: Could Forth be getting a bit of traction? foxaudioresearch@gmail.com - 2015-09-05 09:02 -0700
                Re: Could Forth be getting a bit of traction? "WJ" <w_a_x_man@yahoo.com> - 2015-09-05 16:47 +0000
                  Re: Could Forth be getting a bit of traction? Alfred Singlestone <vitonis@gmail.com> - 2015-09-05 11:13 -0700
    Re: Could Forth be getting a bit of traction? josv@planet.nl - 2015-09-01 12:37 -0700
      Re: Could Forth be getting a bit of traction? Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-01 22:02 +0200
    Re: Could Forth be getting a bit of traction? Mux <Yvo.Zoer@gmail.com> - 2015-09-08 03:45 -0700
      Re: Could Forth be getting a bit of traction? "Elizabeth D. Rather" <erather@forth.com> - 2015-09-08 07:54 -1000
        Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-08 19:08 -0700
        Re: Could Forth be getting a bit of traction? Mux <Yvo.Zoer@gmail.com> - 2015-09-09 15:00 -0700
          Re: Could Forth be getting a bit of traction? rickman <gnuarm@gmail.com> - 2015-09-09 23:18 -0400
    Re: Could Forth be getting a bit of traction? p.lad.work@gmail.com - 2015-10-05 05:04 -0700
      Re: Could Forth be getting a bit of traction? foxaudioresearch@gmail.com - 2015-10-05 06:39 -0700
    Re: Could Forth be getting a bit of traction? Chris Curl <ccurl609@gmail.com> - 2015-10-05 18:44 -0700
      Re: Could Forth be getting a bit of traction? "Elizabeth D. Rather" <erather@forth.com> - 2015-10-05 17:47 -1000
        Re: Could Forth be getting a bit of traction? Chris Curl <ccurl609@gmail.com> - 2015-10-05 21:58 -0700
        Re: Could Forth be getting a bit of traction? Jason Damisch <jasondamisch@yahoo.com> - 2015-10-06 10:55 -0700
          Re: Could Forth be getting a bit of traction? "Elizabeth D. Rather" <erather@forth.com> - 2015-10-06 09:13 -1000
      Re: Could Forth be getting a bit of traction? rickman <gnuarm@gmail.com> - 2015-10-06 01:37 -0400

Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7  Next page →


#42367

From"Elizabeth D. Rather" <erather@forth.com>
Date2015-10-04 18:58 -1000
Message-ID<fN2dnTvbh47lno_LnZ2dnUU7-Yf46u6z@supernews.com>
In reply to#42365
On 10/4/15 6:10 PM, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>>> For a newcomer nowadays it is not that easy to decide which Forth to
>>> start with, especially with microcontrollers.
>> For private exploration or hobby programming, the evaluation versions
>> of the commercial packages are a great choice.
>
> Are any of them available for microcontrollers?  I thought they were
> just for Windows/Linux/Mac.

SwiftX is an interactive cross-development system. The host runs on 
Windows/Linux/Mac, and there are target for most popular 
microcontrollers. It's really a far more convenient and satisfactory 
development environment than running a limited compiler entirely on the 
target.

> Hmm actually there's MPE Lite:
>
>    http://mpeforth.com/xc7lite.htm
>
> There are some code size limitations but it sounds usable, at least on
> certain devices.
>
> I don't see a comparable version of Swift?  Maybe I'm not looking in the
> right place.

Here: http://www.forth.com/embedded/index.html
>
> Meanwhile, I see Forth Application Techniques is $500 a copy on Amazon!
>
>    http://www.amazon.com/dp/0966215613
>
> Might be time for a new edition or printing ;-)

That's actually the 2006 spiral-bound edition (historical artifact?). 
The current updated version is $18.99 :-)

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]


#42368

FromPaul Rubin <no.email@nospam.invalid>
Date2015-10-04 23:35 -0700
Message-ID<87bncd960s.fsf@jester.gateway.sonic.net>
In reply to#42367
"Elizabeth D. Rather" <erather@forth.com> writes:
> Here: http://www.forth.com/embedded/index.html

Nice!  Somehow I missed that there was an evaluation version, and I
thought that I had checked.

>>    http://www.amazon.com/dp/0966215613
>> Might be time for a new edition or printing ;-)
> That's actually the 2006 spiral-bound edition (historical
> artifact?). The current updated version is $18.99 :-)

I see a 2008 paperback edition for $248.26:

   http://www.amazon.com/dp/B00JYHV1XA

I also see a paperback course notebook for $18.99:

  http://www.amazon.com/dp/1419685767

Is that the actual book?  I saw it earlier but thought "course notebook"
meant it was some kind of supplemental material that accompanied the
main book.  You might want to clarify that on the Amazon page.

[toc] | [prev] | [next] | [standalone]


#42369

FromPaul Rubin <no.email@nospam.invalid>
Date2015-10-04 23:44 -0700
Message-ID<877fn195mg.fsf@jester.gateway.sonic.net>
In reply to#42368
Paul Rubin <no.email@nospam.invalid> writes:
>> Here: http://www.forth.com/embedded/index.html
> Nice!  Somehow I missed that there was an evaluation version

Unfortunately it looks like they're all Windows .exe's.  I might be able
to try one out sometime but Linux would be much easier.  It would be
extra interesting to have an ARM Linux version that could be hosted on a
Raspberry Pi or Beaglebone.  I'm not really the target audience for this
sort of thing though.

[toc] | [prev] | [next] | [standalone]


#42378

From"Elizabeth D. Rather" <erather@forth.com>
Date2015-10-05 08:54 -1000
Message-ID<rsydnQ0k5rbjWo_LnZ2dnUU7-S2dnZ2d@supernews.com>
In reply to#42369
On 10/4/15 8:44 PM, Paul Rubin wrote:
> Paul Rubin <no.email@nospam.invalid> writes:
>>> Here: http://www.forth.com/embedded/index.html
>> Nice!  Somehow I missed that there was an evaluation version
>
> Unfortunately it looks like they're all Windows .exe's.  I might be able
> to try one out sometime but Linux would be much easier.  It would be
> extra interesting to have an ARM Linux version that could be hosted on a
> Raspberry Pi or Beaglebone.  I'm not really the target audience for this
> sort of thing though.

SwiftX only runs on Windows because most of the vendors' debug 
interfaces (which we use on the host side) are Windows only. There has 
been little interested in Linux hosts and none on OSX. As for the 
Raspberry Pi, it's not an i386 -- it's an ARM, so it would not be a 
host, it's a target. We prefer a PC host because it's capable of 
supporting a powerful optimizing compiler for the target as well as the 
most convenient editing and debugging tools.

Target platforms may have an optional, limited compiling capability, but 
our assumption is that the major application development should be 
supported by the most powerful tools available.

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]


#42379

FromPaul Rubin <no.email@nospam.invalid>
Date2015-10-05 12:58 -0700
Message-ID<87vbal6qad.fsf@jester.gateway.sonic.net>
In reply to#42378
"Elizabeth D. Rather" <erather@forth.com> writes:
> As for the Raspberry Pi, it's not an i386 -- it's an ARM, so it would
> not be a host, it's a target. We prefer a PC host because it's capable
> of supporting a powerful optimizing compiler for the target as well as
> the most convenient editing and debugging tools.

The current Raspberry Pi is equivalent to a fairly powerful PC of maybe
10 years ago, with four 700 mhz cores and 1GB of ram if I remember
right, plus an SD card for mass storage.  It can run Windows 10 these
days (ARM version of course).  So it should be able to run all the
SwiftX tools, though I take your point about vendor debug tools
requiring x86 Windows.  That hadn't occurred to me since most developers
I know use Linux (primarily on servers), but I get that the embedded
sector is different.

[toc] | [prev] | [next] | [standalone]


#42386

Fromrickman <gnuarm@gmail.com>
Date2015-10-06 01:35 -0400
Message-ID<muvmg9$bce$1@dont-email.me>
In reply to#42378
On 10/5/2015 2:54 PM, Elizabeth D. Rather wrote:
> On 10/4/15 8:44 PM, Paul Rubin wrote:
>> Paul Rubin <no.email@nospam.invalid> writes:
>>>> Here: http://www.forth.com/embedded/index.html
>>> Nice!  Somehow I missed that there was an evaluation version
>>
>> Unfortunately it looks like they're all Windows .exe's.  I might be able
>> to try one out sometime but Linux would be much easier.  It would be
>> extra interesting to have an ARM Linux version that could be hosted on a
>> Raspberry Pi or Beaglebone.  I'm not really the target audience for this
>> sort of thing though.
>
> SwiftX only runs on Windows because most of the vendors' debug
> interfaces (which we use on the host side) are Windows only. There has
> been little interested in Linux hosts and none on OSX. As for the
> Raspberry Pi, it's not an i386 -- it's an ARM, so it would not be a
> host, it's a target. We prefer a PC host because it's capable of
> supporting a powerful optimizing compiler for the target as well as the
> most convenient editing and debugging tools.
>
> Target platforms may have an optional, limited compiling capability, but
> our assumption is that the major application development should be
> supported by the most powerful tools available.

I think 10 years ago that may have been a valid perspective.  But these 
days you don't need an i7 with 16 GB of memory to compile programs to 
run on *any* processor, much less a Cortex M3 or an MSP430.

I think the mobile market has so promoted lightweight computing that it 
is a bit silly to think you need the power of a workstation to develop 
code when practical experience is telling us that many much simpler 
platforms are proving to be very productive.

The rPi is just the tip of the ice burg.  I know my preference is to 
move to lighter weight platforms for *all* my computing needs.  I expect 
that will prove to be true for many in the near future.  My last 
embedded application was done using Mecrisp on the target while using 
the rPi as a host, because of the poor support for Windows by the chip 
vendor.  I only used the PC to provide a keyboard and screen to the rPi. 
  I have put off buying one of the new rPi 2 with the quad core 
processor.  When I get it I may leave the laptop out of it entirely and 
work directly on the rPi.  The laptop is a *crappy* keyboard.

BTW, I am looking at the SmartFusion2 ARM-CM3/FPGA SoC as my next 
target.  I am thinking of porting Mecrisp to it.  I don't think that 
will be any harder than getting one of the commercial Forths to work 
with it.  I could be wrong.

-- 

Rick

[toc] | [prev] | [next] | [standalone]


#42389

FromJUERGEN <epldfpga@aol.com>
Date2015-10-06 02:58 -0700
Message-ID<a76cd6ba-7522-419f-a506-49e1630296a9@googlegroups.com>
In reply to#42386
On Tuesday, October 6, 2015 at 6:36:04 AM UTC+1, rickman wrote:
> On 10/5/2015 2:54 PM, Elizabeth D. Rather wrote:
> > On 10/4/15 8:44 PM, Paul Rubin wrote:
> >> Paul Rubin <no.email@nospam.invalid> writes:
> >>>> Here: http://www.forth.com/embedded/index.html
> >>> Nice!  Somehow I missed that there was an evaluation version
> >>
> >> Unfortunately it looks like they're all Windows .exe's.  I might be able
> >> to try one out sometime but Linux would be much easier.  It would be
> >> extra interesting to have an ARM Linux version that could be hosted on a
> >> Raspberry Pi or Beaglebone.  I'm not really the target audience for this
> >> sort of thing though.
> >
> > SwiftX only runs on Windows because most of the vendors' debug
> > interfaces (which we use on the host side) are Windows only. There has
> > been little interested in Linux hosts and none on OSX. As for the
> > Raspberry Pi, it's not an i386 -- it's an ARM, so it would not be a
> > host, it's a target. We prefer a PC host because it's capable of
> > supporting a powerful optimizing compiler for the target as well as the
> > most convenient editing and debugging tools.
> >
> > Target platforms may have an optional, limited compiling capability, but
> > our assumption is that the major application development should be
> > supported by the most powerful tools available.
> 
> I think 10 years ago that may have been a valid perspective.  But these 
> days you don't need an i7 with 16 GB of memory to compile programs to 
> run on *any* processor, much less a Cortex M3 or an MSP430.
> 
> I think the mobile market has so promoted lightweight computing that it 
> is a bit silly to think you need the power of a workstation to develop 
> code when practical experience is telling us that many much simpler 
> platforms are proving to be very productive.
> 
> The rPi is just the tip of the ice burg.  I know my preference is to 
> move to lighter weight platforms for *all* my computing needs.  I expect 
> that will prove to be true for many in the near future.  My last 
> embedded application was done using Mecrisp on the target while using 
> the rPi as a host, because of the poor support for Windows by the chip 
> vendor.  I only used the PC to provide a keyboard and screen to the rPi. 
>   I have put off buying one of the new rPi 2 with the quad core 
> processor.  When I get it I may leave the laptop out of it entirely and 
> work directly on the rPi.  The laptop is a *crappy* keyboard.
> 
> BTW, I am looking at the SmartFusion2 ARM-CM3/FPGA SoC as my next 
> target.  I am thinking of porting Mecrisp to it.  I don't think that 
> will be any harder than getting one of the commercial Forths to work 
> with it.  I could be wrong.
> 
> -- 
> 
> Rick

Elizabeth explained what the product offer is - what their customers want. 
We are talking commercial product 
You say the product is not what you want. So you will not buy it - fine
You have other options: 
try if MPE can deliver what you want - the only other commercial alternative to my knowledge,
or write your own compiler optimized for what you want
and additionally there are sufficient free solutions out there.
Not very helpful comment of your's I think.

[toc] | [prev] | [next] | [standalone]


#42390

FromRaimond Dragomir <raimond.dragomir@gmail.com>
Date2015-10-06 04:05 -0700
Message-ID<8613719b-4a5a-40e7-b058-796e619d7f35@googlegroups.com>
In reply to#42389
marți, 6 octombrie 2015, 12:58:16 UTC+3, JUERGEN a scris:
> On Tuesday, October 6, 2015 at 6:36:04 AM UTC+1, rickman wrote:
> > On 10/5/2015 2:54 PM, Elizabeth D. Rather wrote:
> > > On 10/4/15 8:44 PM, Paul Rubin wrote:
> > >> Paul Rubin <no.email@nospam.invalid> writes:
> > >>>> Here: http://www.forth.com/embedded/index.html
> > >>> Nice!  Somehow I missed that there was an evaluation version
> > >>
> > >> Unfortunately it looks like they're all Windows .exe's.  I might be able
> > >> to try one out sometime but Linux would be much easier.  It would be
> > >> extra interesting to have an ARM Linux version that could be hosted on a
> > >> Raspberry Pi or Beaglebone.  I'm not really the target audience for this
> > >> sort of thing though.
> > >
> > > SwiftX only runs on Windows because most of the vendors' debug
> > > interfaces (which we use on the host side) are Windows only. There has
> > > been little interested in Linux hosts and none on OSX. As for the
> > > Raspberry Pi, it's not an i386 -- it's an ARM, so it would not be a
> > > host, it's a target. We prefer a PC host because it's capable of
> > > supporting a powerful optimizing compiler for the target as well as the
> > > most convenient editing and debugging tools.
> > >
> > > Target platforms may have an optional, limited compiling capability, but
> > > our assumption is that the major application development should be
> > > supported by the most powerful tools available.
> > 
> > I think 10 years ago that may have been a valid perspective.  But these 
> > days you don't need an i7 with 16 GB of memory to compile programs to 
> > run on *any* processor, much less a Cortex M3 or an MSP430.
> > 
> > I think the mobile market has so promoted lightweight computing that it 
> > is a bit silly to think you need the power of a workstation to develop 
> > code when practical experience is telling us that many much simpler 
> > platforms are proving to be very productive.
> > 
> > The rPi is just the tip of the ice burg.  I know my preference is to 
> > move to lighter weight platforms for *all* my computing needs.  I expect 
> > that will prove to be true for many in the near future.  My last 
> > embedded application was done using Mecrisp on the target while using 
> > the rPi as a host, because of the poor support for Windows by the chip 
> > vendor.  I only used the PC to provide a keyboard and screen to the rPi. 
> >   I have put off buying one of the new rPi 2 with the quad core 
> > processor.  When I get it I may leave the laptop out of it entirely and 
> > work directly on the rPi.  The laptop is a *crappy* keyboard.
> > 
> > BTW, I am looking at the SmartFusion2 ARM-CM3/FPGA SoC as my next 
> > target.  I am thinking of porting Mecrisp to it.  I don't think that 
> > will be any harder than getting one of the commercial Forths to work 
> > with it.  I could be wrong.
> > 
> > -- 
> > 
> > Rick
> 
> Elizabeth explained what the product offer is - what their customers want. 
> We are talking commercial product 
> You say the product is not what you want. So you will not buy it - fine
> You have other options: 
> try if MPE can deliver what you want - the only other commercial alternative to my knowledge,
> or write your own compiler optimized for what you want
> and additionally there are sufficient free solutions out there.
> Not very helpful comment of your's I think.

You always seem to be very upset when free forth implementations come to disscussion. The subject is "Could Forth be getting a bit of traction?" and not "Could Commercial Forths be getting a bit of traction?". 
I also feel free to post anything about free/open source forths here, but I don't, because all I would say is "no, it doesn't".
Anyway, do you think that commercial forth vendors can do anything to help the "traction?" When there are only two of them as you said?
My strong feeling is that the open source community is the only one that can really help. But this open source community is very thin... For example, I have a big application pending, for a Cortex-M4 with at least 8MB sdram, and a serial flash of 4MB/8MB or a sd card. I have a hard time deciding where to choose Lua/elua or Micropython for it. "Standard" forth is lower level than C, so no way (I would consider at most oforth or Factor, but I can't do that as long as they are not open source...)

[toc] | [prev] | [next] | [standalone]


#42391

FromMark Wills <markwills1970@gmail.com>
Date2015-10-06 04:22 -0700
Message-ID<f1d545f6-2026-4cbd-8251-2d4a5b2f7013@googlegroups.com>
In reply to#42390
On Tuesday, 6 October 2015 12:06:01 UTC+1, Raimond Dragomir  wrote:
> marți, 6 octombrie 2015, 12:58:16 UTC+3, JUERGEN a scris:
> > On Tuesday, October 6, 2015 at 6:36:04 AM UTC+1, rickman wrote:
> > > On 10/5/2015 2:54 PM, Elizabeth D. Rather wrote:
> > > > On 10/4/15 8:44 PM, Paul Rubin wrote:
> > > >> Paul Rubin <no.email@nospam.invalid> writes:
> > > >>>> Here: http://www.forth.com/embedded/index.html
> > > >>> Nice!  Somehow I missed that there was an evaluation version
> > > >>
> > > >> Unfortunately it looks like they're all Windows .exe's.  I might be able
> > > >> to try one out sometime but Linux would be much easier.  It would be
> > > >> extra interesting to have an ARM Linux version that could be hosted on a
> > > >> Raspberry Pi or Beaglebone.  I'm not really the target audience for this
> > > >> sort of thing though.
> > > >
> > > > SwiftX only runs on Windows because most of the vendors' debug
> > > > interfaces (which we use on the host side) are Windows only. There has
> > > > been little interested in Linux hosts and none on OSX. As for the
> > > > Raspberry Pi, it's not an i386 -- it's an ARM, so it would not be a
> > > > host, it's a target. We prefer a PC host because it's capable of
> > > > supporting a powerful optimizing compiler for the target as well as the
> > > > most convenient editing and debugging tools.
> > > >
> > > > Target platforms may have an optional, limited compiling capability, but
> > > > our assumption is that the major application development should be
> > > > supported by the most powerful tools available.
> > > 
> > > I think 10 years ago that may have been a valid perspective.  But these 
> > > days you don't need an i7 with 16 GB of memory to compile programs to 
> > > run on *any* processor, much less a Cortex M3 or an MSP430.
> > > 
> > > I think the mobile market has so promoted lightweight computing that it 
> > > is a bit silly to think you need the power of a workstation to develop 
> > > code when practical experience is telling us that many much simpler 
> > > platforms are proving to be very productive.
> > > 
> > > The rPi is just the tip of the ice burg.  I know my preference is to 
> > > move to lighter weight platforms for *all* my computing needs.  I expect 
> > > that will prove to be true for many in the near future.  My last 
> > > embedded application was done using Mecrisp on the target while using 
> > > the rPi as a host, because of the poor support for Windows by the chip 
> > > vendor.  I only used the PC to provide a keyboard and screen to the rPi. 
> > >   I have put off buying one of the new rPi 2 with the quad core 
> > > processor.  When I get it I may leave the laptop out of it entirely and 
> > > work directly on the rPi.  The laptop is a *crappy* keyboard.
> > > 
> > > BTW, I am looking at the SmartFusion2 ARM-CM3/FPGA SoC as my next 
> > > target.  I am thinking of porting Mecrisp to it.  I don't think that 
> > > will be any harder than getting one of the commercial Forths to work 
> > > with it.  I could be wrong.
> > > 
> > > -- 
> > > 
> > > Rick
> > 
> > Elizabeth explained what the product offer is - what their customers want. 
> > We are talking commercial product 
> > You say the product is not what you want. So you will not buy it - fine
> > You have other options: 
> > try if MPE can deliver what you want - the only other commercial alternative to my knowledge,
> > or write your own compiler optimized for what you want
> > and additionally there are sufficient free solutions out there.
> > Not very helpful comment of your's I think.
> 
> You always seem to be very upset when free forth implementations come to disscussion. The subject is "Could Forth be getting a bit of traction?" and not "Could Commercial Forths be getting a bit of traction?". 
> I also feel free to post anything about free/open source forths here, but I don't, because all I would say is "no, it doesn't".
> Anyway, do you think that commercial forth vendors can do anything to help the "traction?" When there are only two of them as you said?
> My strong feeling is that the open source community is the only one that can really help. But this open source community is very thin... For example, I have a big application pending, for a Cortex-M4 with at least 8MB sdram, and a serial flash of 4MB/8MB or a sd card. I have a hard time deciding where to choose Lua/elua or Micropython for it. "Standard" forth is lower level than C, so no way (I would consider at most oforth or Factor, but I can't do that as long as they are not open source...)

Lack of libraries is the issue IMO.

[toc] | [prev] | [next] | [standalone]


#42405

FromJUERGEN <epldfpga@aol.com>
Date2015-10-06 15:00 -0700
Message-ID<cff6cdde-f215-486c-8b6c-e0cc2326e158@googlegroups.com>
In reply to#42390
On Tuesday, October 6, 2015 at 12:06:01 PM UTC+1, Raimond Dragomir wrote:
> marți, 6 octombrie 2015, 12:58:16 UTC+3, JUERGEN a scris:
> > On Tuesday, October 6, 2015 at 6:36:04 AM UTC+1, rickman wrote:
> > > On 10/5/2015 2:54 PM, Elizabeth D. Rather wrote:
> > > > On 10/4/15 8:44 PM, Paul Rubin wrote:
> > > >> Paul Rubin <no.email@nospam.invalid> writes:
> > > >>>> Here: http://www.forth.com/embedded/index.html
> > > >>> Nice!  Somehow I missed that there was an evaluation version
> > > >>
> > > >> Unfortunately it looks like they're all Windows .exe's.  I might be able
> > > >> to try one out sometime but Linux would be much easier.  It would be
> > > >> extra interesting to have an ARM Linux version that could be hosted on a
> > > >> Raspberry Pi or Beaglebone.  I'm not really the target audience for this
> > > >> sort of thing though.
> > > >
> > > > SwiftX only runs on Windows because most of the vendors' debug
> > > > interfaces (which we use on the host side) are Windows only. There has
> > > > been little interested in Linux hosts and none on OSX. As for the
> > > > Raspberry Pi, it's not an i386 -- it's an ARM, so it would not be a
> > > > host, it's a target. We prefer a PC host because it's capable of
> > > > supporting a powerful optimizing compiler for the target as well as the
> > > > most convenient editing and debugging tools.
> > > >
> > > > Target platforms may have an optional, limited compiling capability, but
> > > > our assumption is that the major application development should be
> > > > supported by the most powerful tools available.
> > > 
> > > I think 10 years ago that may have been a valid perspective.  But these 
> > > days you don't need an i7 with 16 GB of memory to compile programs to 
> > > run on *any* processor, much less a Cortex M3 or an MSP430.
> > > 
> > > I think the mobile market has so promoted lightweight computing that it 
> > > is a bit silly to think you need the power of a workstation to develop 
> > > code when practical experience is telling us that many much simpler 
> > > platforms are proving to be very productive.
> > > 
> > > The rPi is just the tip of the ice burg.  I know my preference is to 
> > > move to lighter weight platforms for *all* my computing needs.  I expect 
> > > that will prove to be true for many in the near future.  My last 
> > > embedded application was done using Mecrisp on the target while using 
> > > the rPi as a host, because of the poor support for Windows by the chip 
> > > vendor.  I only used the PC to provide a keyboard and screen to the rPi. 
> > >   I have put off buying one of the new rPi 2 with the quad core 
> > > processor.  When I get it I may leave the laptop out of it entirely and 
> > > work directly on the rPi.  The laptop is a *crappy* keyboard.
> > > 
> > > BTW, I am looking at the SmartFusion2 ARM-CM3/FPGA SoC as my next 
> > > target.  I am thinking of porting Mecrisp to it.  I don't think that 
> > > will be any harder than getting one of the commercial Forths to work 
> > > with it.  I could be wrong.
> > > 
> > > -- 
> > > 
> > > Rick
> > 
> > Elizabeth explained what the product offer is - what their customers want. 
> > We are talking commercial product 
> > You say the product is not what you want. So you will not buy it - fine
> > You have other options: 
> > try if MPE can deliver what you want - the only other commercial alternative to my knowledge,
> > or write your own compiler optimized for what you want
> > and additionally there are sufficient free solutions out there.
> > Not very helpful comment of your's I think.
> 
> You always seem to be very upset when free forth implementations come to disscussion. The subject is "Could Forth be getting a bit of traction?" and not "Could Commercial Forths be getting a bit of traction?". 
> I also feel free to post anything about free/open source forths here, but I don't, because all I would say is "no, it doesn't".
> Anyway, do you think that commercial forth vendors can do anything to help the "traction?" When there are only two of them as you said?
> My strong feeling is that the open source community is the only one that can really help. But this open source community is very thin... For example, I have a big application pending, for a Cortex-M4 with at least 8MB sdram, and a serial flash of 4MB/8MB or a sd card. I have a hard time deciding where to choose Lua/elua or Micropython for it. "Standard" forth is lower level than C, so no way (I would consider at most oforth or Factor, but I can't do that as long as they are not open source...)

Not at all. 
I just think it is silly to complain about a commercial supplier who does it how their customers want it. 
I come from the commercial world and I sometimes doubt how many here are as well. 
Go to a dentist and tell him how she / he should do it - They probably will just drill a bit deeper or put the price up to indicate how they like your "better" knowledge.

There is a difference funnyly enough - they get their living from it. 

I like the free versions as well, actually 4e4th is one I started with before I got involved with MPE and VFX. 

And if you have read the book Ting did recently it states that I got him back into reviving the MSP430 again by connecting him to Klaus and Dirk. But I assume you know this all.

Open Forths definitely breed new ideas and they are then discussed for example at Euroforth - see my inputs I did in this thread and the ANS meeting I attended. ( thanks again for allowing this - looked under all of the tables but could not find any conspiracy ... )

The Forth community is so small now compared to the past that any good idea counts, but people often do not understand how a commercial product support over many years works - slightly different from: Oh I can change my compiler this afternoon as you can with any free system which is probably more fun.

Portability and maintenance count in professional and commercial systems.

Regarding your project Cortex M4: just send an email to both suppliers and see what the result is - you might be surprised or get the "positive" feedback that they cannot achieve what you want for whatever reason - which will make your decision easier as well. 

I do not know the FORTH INC products that well, but MPE offers some free ARM options which should give you an indication. 

If your hesitation/searching costs you 1 week of your life , that means 5 x 8 = 40 hours of project lost. At for example 50 dollars per hour this means $2000 lost in revenue ( and you would have the commercial compiler for free for your next project ).
And by the way, who causes the traction - free or commercial - is irrelevant - the market is by definition 100%. If the market value increases for whatever reason, everybody wins - Forth suppliers and consultants - including an increased credibility of the market about Forth.

[toc] | [prev] | [next] | [standalone]


#42407

FromPaul Rubin <no.email@nospam.invalid>
Date2015-10-06 16:02 -0700
Message-ID<87io6j7g8s.fsf@jester.gateway.sonic.net>
In reply to#42405
JUERGEN <epldfpga@aol.com> writes:
> I just think it is silly to complain about a commercial supplier who
> does it how their customers want it. ...  Regarding your project
> Cortex M4: just send an email to both suppliers and see what the
> result is ...  If your hesitation/searching costs you 1 week of your
> life , that means 5 x 8 = 40 hours of project lost.

I think you're responding to both Rickman and Raimond Dragomir, who are
dealing with separate sets of issues.  Rickman is quite aware of the
commercial Forth options but found that Mecrisp filled his requirements.
I think he knows that the commercial Forths have features and support
that Mecrisp doesn't, but he didn't need it.  I don't think he
complained about commercial vendors; but rather, he just said that he
found something non-commercial that did what he wanted, and indicated
that maybe they hadn't kept up with the changing state of the market.

Raimond on the other hand is programming a bigger system (8MB ram) and
isn't looking to use Forth at all.  The alternatives he mentioned
(oForth, Factor, Lua, MicroPython) are all more "automated" than Forth:
they manage far more of of the program's details than Forth does, which
has a cost in hardware resources and program determinism.  But on bigger
processors and in some apps, that is often perfectly fine.  So I think
he understands the trade-offs enough to make a good decision regarding
his own constraints.  (Factor is FOSS by the way.  I don't know about
oForth.  For non-FOSS Forth-inspired systems in this class, I'd add Ron
Aaron's 8th to the list).

> And if you have read the book Ting did recently it states that I got
> him back into reviving the MSP430 again by connecting him to Klaus and
> Dirk. But I assume you know this all.

Which book is that?  I didn't realize Ting had a new book out.  I've
looked at some of his older ones and found them very interesting.

[toc] | [prev] | [next] | [standalone]


#42413

FromRon Aaron <rambamist@gmail.com>
Date2015-10-07 07:49 +0300
Message-ID<mv285k$8it$2@dont-email.me>
In reply to#42407

On 10/7/15 02:02, Paul Rubin wrote:
> I don't know about
> oForth.  For non-FOSS Forth-inspired systems in this class, I'd add Ron
> Aaron's 8th to the list).

I'd agree :)

[toc] | [prev] | [next] | [standalone]


#42406

FromPaul Rubin <no.email@nospam.invalid>
Date2015-10-06 15:04 -0700
Message-ID<87mvvv7iwt.fsf@jester.gateway.sonic.net>
In reply to#42390
Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> For example, I have a big application pending, for a Cortex-M4
> with at least 8MB sdram, and a serial flash of 4MB/8MB or a sd card. I
> have a hard time deciding where to choose Lua/elua or Micropython for
> it. "Standard" forth is lower level than C, so no way

With that much memory you have more choices, including CPython and (not
my favorite) Javascript.  In fact there's a small Javascript that runs
directly on a CM4:

  http://www.adafruit.com/products/2621

[toc] | [prev] | [next] | [standalone]


#42533

FromPaul Rubin <no.email@nospam.invalid>
Date2015-10-09 14:16 -0700
Message-ID<87k2qv4u9n.fsf@jester.gateway.sonic.net>
In reply to#42390
Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> "Standard" forth is lower level than C, so no way (I would
> consider at most oforth or Factor, but I can't do that as long as they
> are not open source...)

Both are FOSS.   Oforth is BSD3 licensed and Factor is BSD2.

[toc] | [prev] | [next] | [standalone]


#42392

Fromrickman <gnuarm@gmail.com>
Date2015-10-06 09:34 -0400
Message-ID<mv0igo$blt$1@dont-email.me>
In reply to#42389
On 10/6/2015 5:58 AM, JUERGEN wrote:
> On Tuesday, October 6, 2015 at 6:36:04 AM UTC+1, rickman wrote:
>> On 10/5/2015 2:54 PM, Elizabeth D. Rather wrote:
>>> On 10/4/15 8:44 PM, Paul Rubin wrote:
>>>> Paul Rubin <no.email@nospam.invalid> writes:
>>>>>> Here: http://www.forth.com/embedded/index.html
>>>>> Nice!  Somehow I missed that there was an evaluation version
>>>>
>>>> Unfortunately it looks like they're all Windows .exe's.  I might be able
>>>> to try one out sometime but Linux would be much easier.  It would be
>>>> extra interesting to have an ARM Linux version that could be hosted on a
>>>> Raspberry Pi or Beaglebone.  I'm not really the target audience for this
>>>> sort of thing though.
>>>
>>> SwiftX only runs on Windows because most of the vendors' debug
>>> interfaces (which we use on the host side) are Windows only. There has
>>> been little interested in Linux hosts and none on OSX. As for the
>>> Raspberry Pi, it's not an i386 -- it's an ARM, so it would not be a
>>> host, it's a target. We prefer a PC host because it's capable of
>>> supporting a powerful optimizing compiler for the target as well as the
>>> most convenient editing and debugging tools.
>>>
>>> Target platforms may have an optional, limited compiling capability, but
>>> our assumption is that the major application development should be
>>> supported by the most powerful tools available.
>>
>> I think 10 years ago that may have been a valid perspective.  But these
>> days you don't need an i7 with 16 GB of memory to compile programs to
>> run on *any* processor, much less a Cortex M3 or an MSP430.
>>
>> I think the mobile market has so promoted lightweight computing that it
>> is a bit silly to think you need the power of a workstation to develop
>> code when practical experience is telling us that many much simpler
>> platforms are proving to be very productive.
>>
>> The rPi is just the tip of the ice burg.  I know my preference is to
>> move to lighter weight platforms for *all* my computing needs.  I expect
>> that will prove to be true for many in the near future.  My last
>> embedded application was done using Mecrisp on the target while using
>> the rPi as a host, because of the poor support for Windows by the chip
>> vendor.  I only used the PC to provide a keyboard and screen to the rPi.
>>    I have put off buying one of the new rPi 2 with the quad core
>> processor.  When I get it I may leave the laptop out of it entirely and
>> work directly on the rPi.  The laptop is a *crappy* keyboard.
>>
>> BTW, I am looking at the SmartFusion2 ARM-CM3/FPGA SoC as my next
>> target.  I am thinking of porting Mecrisp to it.  I don't think that
>> will be any harder than getting one of the commercial Forths to work
>> with it.  I could be wrong.
>>
>> --
>>
>> Rick
>
> Elizabeth explained what the product offer is - what their customers want.
> We are talking commercial product
> You say the product is not what you want. So you will not buy it - fine
> You have other options:
> try if MPE can deliver what you want - the only other commercial alternative to my knowledge,
> or write your own compiler optimized for what you want
> and additionally there are sufficient free solutions out there.
> Not very helpful comment of your's I think.

Sorry you don't find my comments "helpful".  But you seem to have 
misread the post.  First, Elizabeth didn't say what her *customers* 
want, she said, "*We* prefer a PC host".  She is speaking from the 
perspective of a vendor, not a user.  There are many reasons to want to 
limit support to a single platform.  It is a lot more work to support 
multiple operating systems and host CPUs.  That is not at all the same 
thing as saying users don't want to use hosts other than Windows on big 
iron.  The existence of the many alternative Forths shows clearly there 
is at least some market for that.

The statement about vendor debug interfaces is a bit disingenuous. 
Nearly every MCU (certainly all the popular ones) has support under 
Linux using open source tools.  Even if the vendor doesn't support these 
tools themselves it doesn't mean the tools don't exist and don't work 
well.  The entire reason I used the rPi for my last project was because 
TI only offered a non-signed driver for their launchpad boards which I 
found very hard to install under Win 8.  So I used a tool under Raspian 
that installed very easily and worked well.

As to my preferences, I believe I was pretty clear about just that, they 
are my preferences, "I know my preference...".  I also commented on the 
state of the software development market and I stand by those comments. 
  Just as cell phones have largely replaced land lines and 
laptops/tablets have largely replaced desktops, software development is 
well on its way to leaving behind the big iron and Windows.

I'm not sure exactly what your post is about.  I am very aware of my 
options for development.  I mentioned that in my post.  It appears you 
were disturbed by my comments, "helpful" or not.  Am I not supposed to 
talk about what I want and what I use???

-- 

Rick

[toc] | [prev] | [next] | [standalone]


#42402

From"Elizabeth D. Rather" <erather@forth.com>
Date2015-10-06 09:08 -1000
Message-ID<_Zidnex3Vre0gYnLnZ2dnUU7-RGdnZ2d@supernews.com>
In reply to#42392
On 10/6/15 3:34 AM, rickman wrote:
> On 10/6/2015 5:58 AM, JUERGEN wrote:
>> On Tuesday, October 6, 2015 at 6:36:04 AM UTC+1, rickman wrote:
>>> On 10/5/2015 2:54 PM, Elizabeth D. Rather wrote:
>>>> On 10/4/15 8:44 PM, Paul Rubin wrote:
>>>>> Paul Rubin <no.email@nospam.invalid> writes:
>>>>>>> Here: http://www.forth.com/embedded/index.html
>>>>>> Nice!  Somehow I missed that there was an evaluation version
>>>>>
>>>>> Unfortunately it looks like they're all Windows .exe's.  I might be
>>>>> able
>>>>> to try one out sometime but Linux would be much easier.  It would be
>>>>> extra interesting to have an ARM Linux version that could be hosted
>>>>> on a
>>>>> Raspberry Pi or Beaglebone.  I'm not really the target audience for
>>>>> this
>>>>> sort of thing though.
>>>>
>>>> SwiftX only runs on Windows because most of the vendors' debug
>>>> interfaces (which we use on the host side) are Windows only. There has
>>>> been little interested in Linux hosts and none on OSX. As for the
>>>> Raspberry Pi, it's not an i386 -- it's an ARM, so it would not be a
>>>> host, it's a target. We prefer a PC host because it's capable of
>>>> supporting a powerful optimizing compiler for the target as well as the
>>>> most convenient editing and debugging tools.
>>>>
>>>> Target platforms may have an optional, limited compiling capability,
>>>> but
>>>> our assumption is that the major application development should be
>>>> supported by the most powerful tools available.
>>>
>>> I think 10 years ago that may have been a valid perspective.  But these
>>> days you don't need an i7 with 16 GB of memory to compile programs to
>>> run on *any* processor, much less a Cortex M3 or an MSP430.
>>>
>>> I think the mobile market has so promoted lightweight computing that it
>>> is a bit silly to think you need the power of a workstation to develop
>>> code when practical experience is telling us that many much simpler
>>> platforms are proving to be very productive.
>>>
>>> The rPi is just the tip of the ice burg.  I know my preference is to
>>> move to lighter weight platforms for *all* my computing needs.  I expect
>>> that will prove to be true for many in the near future.  My last
>>> embedded application was done using Mecrisp on the target while using
>>> the rPi as a host, because of the poor support for Windows by the chip
>>> vendor.  I only used the PC to provide a keyboard and screen to the rPi.
>>>    I have put off buying one of the new rPi 2 with the quad core
>>> processor.  When I get it I may leave the laptop out of it entirely and
>>> work directly on the rPi.  The laptop is a *crappy* keyboard.
>>>
>>> BTW, I am looking at the SmartFusion2 ARM-CM3/FPGA SoC as my next
>>> target.  I am thinking of porting Mecrisp to it.  I don't think that
>>> will be any harder than getting one of the commercial Forths to work
>>> with it.  I could be wrong.
>>>
>>> --
>>>
>>> Rick
>>
>> Elizabeth explained what the product offer is - what their customers
>> want.
>> We are talking commercial product
>> You say the product is not what you want. So you will not buy it - fine
>> You have other options:
>> try if MPE can deliver what you want - the only other commercial
>> alternative to my knowledge,
>> or write your own compiler optimized for what you want
>> and additionally there are sufficient free solutions out there.
>> Not very helpful comment of your's I think.
>
> Sorry you don't find my comments "helpful".  But you seem to have
> misread the post.  First, Elizabeth didn't say what her *customers*
> want, she said, "*We* prefer a PC host".  She is speaking from the
> perspective of a vendor, not a user.  There are many reasons to want to
> limit support to a single platform.  It is a lot more work to support
> multiple operating systems and host CPUs.  That is not at all the same
> thing as saying users don't want to use hosts other than Windows on big
> iron.  The existence of the many alternative Forths shows clearly there
> is at least some market for that.

In fact, the approach we use in SwiftX is what our customers (who are 
mostly professional programmers developing complex microprocessor-based 
products) have demanded for years. In addition, a major part of our work 
is contract programming, so we are not only developing and maintaining 
software for other programmers to use, we are using it in challenging 
projects. The solutions our customers request as well as our own 
experience trying to do a better job for our contract programming 
customers are what drives the development of our products.

> The statement about vendor debug interfaces is a bit disingenuous.
> Nearly every MCU (certainly all the popular ones) has support under
> Linux using open source tools.  Even if the vendor doesn't support these
> tools themselves it doesn't mean the tools don't exist and don't work
> well.  The entire reason I used the rPi for my last project was because
> TI only offered a non-signed driver for their launchpad boards which I
> found very hard to install under Win 8.  So I used a tool under Raspian
> that installed very easily and worked well.

Depends on which tools you're talking about. We do not use any vendor 
compilers or debuggers. We get access to host-side drivers for flash 
burning and things like the TI BDM, JTAG, etc. via their developer 
programs. We don't always use them the way the developer intended. For 
example, we often run the debugging interface to the host as a separate 
task from the tasks involved in the application, so you can observe the 
running application without necessarily halting it.

Many of our customers' projects are on custom hardware without any user 
interface or with otherwise very limited facilities for supporting a 
debugging environment other than what SwiftX provides via its connected 
host.

> As to my preferences, I believe I was pretty clear about just that, they
> are my preferences, "I know my preference...".  I also commented on the
> state of the software development market and I stand by those comments.
>   Just as cell phones have largely replaced land lines and
> laptops/tablets have largely replaced desktops, software development is
> well on its way to leaving behind the big iron and Windows.
>
> I'm not sure exactly what your post is about.  I am very aware of my
> options for development.  I mentioned that in my post.  It appears you
> were disturbed by my comments, "helpful" or not.  Am I not supposed to
> talk about what I want and what I use???

Of course you are :-)

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]


#42409

FromPaul Rubin <no.email@nospam.invalid>
Date2015-10-06 20:49 -0700
Message-ID<87y4ff5oee.fsf@jester.gateway.sonic.net>
In reply to#42386
rickman <gnuarm@gmail.com> writes:

> I think the mobile market has so promoted lightweight computing that
> it is a bit silly to think you need the power of a workstation to
> develop code when practical experience is telling us that many much
> simpler platforms are proving to be very productive.

The most demanding application these days is web browsers and it's
getting worse all the time.  They keep improving the performance of
Javascript, and whenever that happens, web developers feel entitled to
eat yet more CPU cycles.  So the web will always be slow from here on
out.

> I have put off buying one of the new rPi 2 with the quad core
> processor.  When I get it I may leave the laptop out of it entirely
> and work directly on the rPi.  The laptop is a *crappy* keyboard.

I like working on a small laptop (compact box with keyboard and screen
in the same place, lets me sit anywhere and code) with heavy computing
done on a remote server.  For a small ARM box you might  look at the
Odroid XU4 which should be > 2x the speed of the rPi 2:

  http://www.hardkernel.com/main/products/prdt_info.php

Hetzner (big German web host) has been renting them out as dedicated
servers, though overpriced IMHO:

  https://www.hetzner.de/us/hosting/produktmatrix/rootserver-produktmatrix-ax

I've been playing with Scaleway ARM servers (30 minute no-registration
trial: http://instantcloud.io ) which are closer to the rPi 2 in
performance but are amazingly cheap (3 euro per month with 50GB SSD, 200
megabit internet, hourly billing and a real cloud API).  OVH is doing a
small trial with 64-bit ARM servers that I didn't get to join before it
filled, but hopefully they will widen it soon.  x86, feel the heat ;-).
>
> BTW, I am looking at the SmartFusion2 ARM-CM3/FPGA SoC as my next
> target.  I am thinking of porting Mecrisp to it.  I don't think that
> will be any harder than getting one of the commercial Forths to work
> with it.  I could be wrong.

I wouldn't expect porting to be harder, but of course the commercial
Forths have a lot more features and libraries.

[toc] | [prev] | [next] | [standalone]


#42414

Fromrickman <gnuarm@gmail.com>
Date2015-10-07 00:56 -0400
Message-ID<mv28hq$9m6$1@dont-email.me>
In reply to#42409
On 10/6/2015 11:49 PM, Paul Rubin wrote:
> rickman <gnuarm@gmail.com> writes:
>
>> I think the mobile market has so promoted lightweight computing that
>> it is a bit silly to think you need the power of a workstation to
>> develop code when practical experience is telling us that many much
>> simpler platforms are proving to be very productive.
>
> The most demanding application these days is web browsers and it's
> getting worse all the time.  They keep improving the performance of
> Javascript, and whenever that happens, web developers feel entitled to
> eat yet more CPU cycles.  So the web will always be slow from here on
> out.
>
>> I have put off buying one of the new rPi 2 with the quad core
>> processor.  When I get it I may leave the laptop out of it entirely
>> and work directly on the rPi.  The laptop is a *crappy* keyboard.
>
> I like working on a small laptop (compact box with keyboard and screen
> in the same place, lets me sit anywhere and code) with heavy computing
> done on a remote server.  For a small ARM box you might  look at the
> Odroid XU4 which should be > 2x the speed of the rPi 2:
>
>    http://www.hardkernel.com/main/products/prdt_info.php
>
> Hetzner (big German web host) has been renting them out as dedicated
> servers, though overpriced IMHO:
>
>    https://www.hetzner.de/us/hosting/produktmatrix/rootserver-produktmatrix-ax
>
> I've been playing with Scaleway ARM servers (30 minute no-registration
> trial: http://instantcloud.io ) which are closer to the rPi 2 in
> performance but are amazingly cheap (3 euro per month with 50GB SSD, 200
> megabit internet, hourly billing and a real cloud API).  OVH is doing a
> small trial with 64-bit ARM servers that I didn't get to join before it
> filled, but hopefully they will widen it soon.  x86, feel the heat ;-).
>>
>> BTW, I am looking at the SmartFusion2 ARM-CM3/FPGA SoC as my next
>> target.  I am thinking of porting Mecrisp to it.  I don't think that
>> will be any harder than getting one of the commercial Forths to work
>> with it.  I could be wrong.
>
> I wouldn't expect porting to be harder, but of course the commercial
> Forths have a lot more features and libraries.

I don't know what it would take to port a commercial Forth to a new 
target.  Part of my concern with a commercial forth is the contractual 
issues that I don't even want to explore.  I don't typically develop 
large or complex applications, so I can usually do my work with less 
capable tools.  Mostly it is nice to not be restrained by the licensing 
of commercial Forths.  If I were to work on a larger project demanding 
the best tools, then I might go for one of the commercial packages. 
Until then, I want to work openly and freely.  Heck, I barely know Forth 
and still manage to develop applications.

The really funny part is that my last serious Forth project was to 
control a test fixture via an RS-232 port to an FPGA.  I had a major 
comms problem and I kept trying to nail it down thinking it was 
something goofy in the comms software.  In the end it was in my FPGA, I 
had forgotten the durn synchronizing FF at the input to the UART!!!  A 
rookie mistake!  So much for code reuse.  A bit like the Ariane rocket 
failure, lol.  The UART worked great in the previous project, but when I 
ported it to the new project I forgot to adequately verify the I/O 
details (the sync FF was external to the UART code).  However, while 
trying to find the bug, I had included some *really* fancy error 
checking code in Forth and learned about catch throw in the process.

-- 

Rick

[toc] | [prev] | [next] | [standalone]


#42417

From"Elizabeth D. Rather" <erather@forth.com>
Date2015-10-06 21:11 -1000
Message-ID<54qdnYCL1Z4NWInLnZ2dnUU7-a2dnZ2d@supernews.com>
In reply to#42414
On 10/6/15 6:56 PM, rickman wrote:
> On 10/6/2015 11:49 PM, Paul Rubin wrote:
>> rickman <gnuarm@gmail.com> writes:
>>
>>> I think the mobile market has so promoted lightweight computing that
>>> it is a bit silly to think you need the power of a workstation to
>>> develop code when practical experience is telling us that many much
>>> simpler platforms are proving to be very productive.
>>
>> The most demanding application these days is web browsers and it's
>> getting worse all the time.  They keep improving the performance of
>> Javascript, and whenever that happens, web developers feel entitled to
>> eat yet more CPU cycles.  So the web will always be slow from here on
>> out.
>>
>>> I have put off buying one of the new rPi 2 with the quad core
>>> processor.  When I get it I may leave the laptop out of it entirely
>>> and work directly on the rPi.  The laptop is a *crappy* keyboard.
>>
>> I like working on a small laptop (compact box with keyboard and screen
>> in the same place, lets me sit anywhere and code) with heavy computing
>> done on a remote server.  For a small ARM box you might  look at the
>> Odroid XU4 which should be > 2x the speed of the rPi 2:
>>
>>    http://www.hardkernel.com/main/products/prdt_info.php
>>
>> Hetzner (big German web host) has been renting them out as dedicated
>> servers, though overpriced IMHO:
>>
>>
>> https://www.hetzner.de/us/hosting/produktmatrix/rootserver-produktmatrix-ax
>>
>>
>> I've been playing with Scaleway ARM servers (30 minute no-registration
>> trial: http://instantcloud.io ) which are closer to the rPi 2 in
>> performance but are amazingly cheap (3 euro per month with 50GB SSD, 200
>> megabit internet, hourly billing and a real cloud API).  OVH is doing a
>> small trial with 64-bit ARM servers that I didn't get to join before it
>> filled, but hopefully they will widen it soon.  x86, feel the heat ;-).
>>>
>>> BTW, I am looking at the SmartFusion2 ARM-CM3/FPGA SoC as my next
>>> target.  I am thinking of porting Mecrisp to it.  I don't think that
>>> will be any harder than getting one of the commercial Forths to work
>>> with it.  I could be wrong.
>>
>> I wouldn't expect porting to be harder, but of course the commercial
>> Forths have a lot more features and libraries.
>
> I don't know what it would take to port a commercial Forth to a new
> target.  Part of my concern with a commercial forth is the contractual
> issues that I don't even want to explore.

Not really that complicated. We license the development system. A 
turnkey target that isn't itself programmable has no further obligations.

> I don't typically develop
> large or complex applications, so I can usually do my work with less
> capable tools.  Mostly it is nice to not be restrained by the licensing
> of commercial Forths.  If I were to work on a larger project demanding
> the best tools, then I might go for one of the commercial packages.
> Until then, I want to work openly and freely.  Heck, I barely know Forth
> and still manage to develop applications.
>
> The really funny part is that my last serious Forth project was to
> control a test fixture via an RS-232 port to an FPGA.  I had a major
> comms problem and I kept trying to nail it down thinking it was
> something goofy in the comms software.  In the end it was in my FPGA, I
> had forgotten the durn synchronizing FF at the input to the UART!!!  A
> rookie mistake!  So much for code reuse.  A bit like the Ariane rocket
> failure, lol.  The UART worked great in the previous project, but when I
> ported it to the new project I forgot to adequately verify the I/O
> details (the sync FF was external to the UART code).  However, while
> trying to find the bug, I had included some *really* fancy error
> checking code in Forth and learned about catch throw in the process.

Good. Catch/throw is really powerful, probably the best single 
innovation in Forth94 (Thank you, Mitch Bradley!)

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]


#42539

FromPaul Rubin <no.email@nospam.invalid>
Date2015-10-09 21:07 -0700
Message-ID<877fmv4b9i.fsf@jester.gateway.sonic.net>
In reply to#42414
rickman <gnuarm@gmail.com> writes:
> Part of my concern with a commercial forth ...  Mostly it is nice to
> not be restrained by the licensing of commercial Forths.  If I were to
> work on a larger project demanding the best tools, then I might go for
> one of the commercial packages.

Don't forget, Mecrisp is GPL3, which constrains how you can ship it in
products.  Life might be easier with a commercial Forth where you can
probably get whatever you need by writing enough checks.

[toc] | [prev] | [next] | [standalone]


Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7  Next page →

Back to top | Article view | comp.lang.forth


csiph-web