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

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

Arduino Due - small FORTH Computer - Multitasking

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

Contents

  Arduino Due - small FORTH Computer - Multitasking Mark Wills <markwills1970@gmail.com> - 2015-07-14 08:13 -0700
    Re: Arduino Due - small FORTH Computer - Multitasking Mark Wills <markwills1970@gmail.com> - 2015-07-14 08:16 -0700
    Re: Arduino Due - small FORTH Computer - Multitasking Paul Rubin <no.email@nospam.invalid> - 2015-07-14 09:23 -0700
      Re: Arduino Due - small FORTH Computer - Multitasking Mark Wills <markwills1970@gmail.com> - 2015-07-15 04:03 -0700
        Re: Arduino Due - small FORTH Computer - Multitasking Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-07-15 14:02 +0200
          Re: Arduino Due - small FORTH Computer - Multitasking stephen@mpeforth.com (Stephen Pelc) - 2015-07-15 16:34 +0000
            Re: Arduino Due - small FORTH Computer - Multitasking Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-07-16 12:26 +0200
              Re: Arduino Due - small FORTH Computer - Multitasking stephen@mpeforth.com (Stephen Pelc) - 2015-07-16 12:10 +0000
              Re: Arduino Due - small FORTH Computer - Multitasking Gary Bergstrom <forthprgrmr@gmail.com> - 2015-07-17 06:48 -0700
              Re: Arduino Due - small FORTH Computer - Multitasking Walter Banks <walter@bytecraft.com> - 2015-07-17 16:21 -0400
                Re: Arduino Due - small FORTH Computer - Multitasking Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-07-20 11:57 +0200
                  Re: Arduino Due - small FORTH Computer - Multitasking stephen@mpeforth.com (Stephen Pelc) - 2015-07-20 12:37 +0000
                    Re: Arduino Due - small FORTH Computer - Multitasking Gary Bergstrom <forthprgrmr@gmail.com> - 2015-07-20 10:42 -0700
                      Re: Arduino Due - small FORTH Computer - Multitasking stephen@mpeforth.com (Stephen Pelc) - 2015-07-21 11:29 +0000
                    Re: Arduino Due - small FORTH Computer - Multitasking Paul Rubin <no.email@nospam.invalid> - 2015-07-20 11:48 -0700
                      Re: Arduino Due - small FORTH Computer - Multitasking stephen@mpeforth.com (Stephen Pelc) - 2015-07-20 22:53 +0000
                        Re: Arduino Due - small FORTH Computer - Multitasking Paul Rubin <no.email@nospam.invalid> - 2015-07-21 00:32 -0700
                          Re: Arduino Due - small FORTH Computer - Multitasking stephen@mpeforth.com (Stephen Pelc) - 2015-07-21 08:03 +0000
                            Re: Arduino Due - small FORTH Computer - Multitasking Paul Rubin <no.email@nospam.invalid> - 2015-07-21 01:33 -0700
                        Re: Arduino Due - small FORTH Computer - Multitasking hughaguilar96@gmail.com - 2015-08-10 16:54 -0700
                    Re: Arduino Due - small FORTH Computer - Multitasking anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-21 05:18 +0000
                      Re: Arduino Due - small FORTH Computer - Multitasking stephen@mpeforth.com (Stephen Pelc) - 2015-07-21 08:20 +0000
                  Re: Arduino Due - small FORTH Computer - Multitasking Walter Banks <walter@bytecraft.com> - 2015-07-20 12:09 -0400
                  Re: Arduino Due - small FORTH Computer - Multitasking JUERGEN <epldfpga@aol.com> - 2015-07-20 14:02 -0700
                    Re: Arduino Due - small FORTH Computer - Multitasking Paul Rubin <no.email@nospam.invalid> - 2015-07-21 15:03 -0700
                    Re: Arduino Due - small FORTH Computer - Multitasking visualforth@rocketmail.com - 2015-07-21 21:59 -0700
                    Re: Arduino Due - small FORTH Computer - Multitasking Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-03 23:30 +0200
                      Re: Arduino Due - small FORTH Computer - Multitasking JUERGEN <epldfpga@aol.com> - 2015-08-10 03:11 -0700

Page 1 of 2  [1] 2  Next page →

#40616 — Arduino Due - small FORTH Computer - Multitasking

Ran into this by accident on YouTube:

https://www.youtube.com/watch?v=M-Xt1ShKW3c#t=162

EXACTLY what I'm looking for, though I don't know how fast 
it is, or how well (if at all) it is documented as a system.

Anyone know anything about it?

Mark

[toc] | [next] | [standalone]

#40617

On Tuesday, 14 July 2015 16:13:49 UTC+1, Mark Wills  wrote:
> Ran into this by accident on YouTube:
> 
> https://www.youtube.com/watch?v=M-Xt1ShKW3c#t=162
> 
> EXACTLY what I'm looking for, though I don't know how fast 
> it is, or how well (if at all) it is documented as a system.
> 
> Anyone know anything about it?
> 
> Mark

Info on the board here:

The Arduino Due is the newcomer microcontroller board in the Arduino boards family. It's the first board based on a 32 bit ARM core processor, the Atmel SAM3X8E ARM Cortex-M3 MCU, that improve all the standard Arduino functionalities and add more new features. It offer 54 digital input/output pins (of which 12 can be used as PWM outputs, with selectable resolution), 12 analog inputs with 12 bit of resolution, 4 UARTs (hardware serial ports), and two DAC outputs (digital to analog converter), 84 MHz crystal oscillator, two USB connections, a power jack, an ICSP header, a JTAG header, and a reset button. 

http://www.amazon.co.uk/367/dp/B00A6C3JN2/ref=sr_1_1/279-7914403-4163034?ie=UTF8&qid=1436886148&sr=8-1&keywords=arduino+due

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

#40618

Mark Wills <markwills1970@gmail.com> writes:
> EXACTLY what I'm looking for, though I don't know how fast 
> it is, or how well (if at all) it is documented as a system.
> Anyone know anything about it?

Yes, see here: http://www.adafruit.com/products/1076

Arduinos have a big user community and tool ecosystem but the hardware
is kind of expensive for what you get.  There are lots of comparable
boards that are much less expensive, e.g. the STM Discovery boards,
TI Launchpads, etc.

Be aware that the Arduino is not a "Forth board" as the youtube link
might have made it sound.  It's a general purpose Cortex M3 board that
someone installed a Forth system on.  It's not even clear which Forth
system.  Normally they are programmed in C with a beginner-friendly
software setup called "sketches" (I'm not describing it perfectly, ok).
Part of what you pay for is the hardware and software support (special
bootloader etc) to accomodate that.

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

#40647

On Tuesday, 14 July 2015 17:23:36 UTC+1, Paul Rubin  wrote:
> Mark Wills <markwills1970@gmail.com> writes:
> > EXACTLY what I'm looking for, though I don't know how fast 
> > it is, or how well (if at all) it is documented as a system.
> > Anyone know anything about it?
> 
> Yes, see here: http://www.adafruit.com/products/1076
> 
> Arduinos have a big user community and tool ecosystem but the hardware
> is kind of expensive for what you get.  There are lots of comparable
> boards that are much less expensive, e.g. the STM Discovery boards,
> TI Launchpads, etc.
> 
> Be aware that the Arduino is not a "Forth board" as the youtube link
> might have made it sound.  It's a general purpose Cortex M3 board that
> someone installed a Forth system on.  It's not even clear which Forth
> system.  Normally they are programmed in C with a beginner-friendly
> software setup called "sketches" (I'm not describing it perfectly, ok).
> Part of what you pay for is the hardware and software support (special
> bootloader etc) to accomodate that.

Thanks Paul. It's a shame that the Forth system can't be identified.
It looks quite comprehensive. The author of the video doesn't appear
to be responding to requests for more info, so I guess I'll just leave
it there.

Mark

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

#40651

> Thanks Paul. It's a shame that the Forth system can't be identified.
> It looks quite comprehensive. The author of the video doesn't appear
> to be responding to requests for more info, so I guess I'll just leave
> it there.

Hi Mark,

so far, there are few Forths for ARM Cortex, the ones I know are:

m3forth by Cliff Biffle (https://bitbucket.org/cbiffle/m3forth/src)
coreforth by Eckhart Köppen (https://github.com/ekoeppen/CoreForth)

It is clearly not Mecrisp-Stellaris, as variable is used without initialisation value.
But if you wish for a Forth on your own Arduino Due, consider writing just another port of Mecrisp-Stellaris.

Matthias

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

#40658

On Wed, 15 Jul 2015 14:02:46 +0200, Matthias Koch
<matthias.koch@hot.uni-hannover.de> wrote:

>> Thanks Paul. It's a shame that the Forth system can't be identified.
>> It looks quite comprehensive. The author of the video doesn't appear
>> to be responding to requests for more info, so I guess I'll just leave
>> it there.
>
>Hi Mark,
>
>so far, there are few Forths for ARM Cortex, the ones I know are:
>
>m3forth by Cliff Biffle (https://bitbucket.org/cbiffle/m3forth/src)
>coreforth by Eckhart Köppen (https://github.com/ekoeppen/CoreForth)

Ignoring Forths because they are not FOSS does not mean that they do
not exist.

Naturally, there are commercial Forths by MPE and Forth Inc. The MPE
one can have such extensions as a FAT file system, USB stack, TCP/IP
stack and son on. The commercial ones also have documentation. The
MPE VFX cross compiler includes a *really* good code generator.
There's a free (of charge) Lite version of the MPE compiler.

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]

#40680

Hi Stephen,

of course I know that you have developed a very good compiler with register allocation, available for many special CPU cores. Unlike yours, which enjoys having a lot of memory available for many optimisation cases, mine has to fit entirely in small chips. Yours clearly shows its strength in tethered mode, but to cite your Euroforth article:

http://www.complang.tuwien.ac.at/anton/euroforth/ef14/papers/pelc1.pdf

"In our world, the cross compiler generates highly optimised code, but we are not really concerned with the quality of the code created by the target."

This is exactly what I care about. Additionally, FOSS implementations neither have artificial limitations as your Lite compiler nor the requirement to sign an NDA to see the complete compiler sources.

Matthias

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

#40682

On Thu, 16 Jul 2015 12:26:15 +0200, Matthias Koch
<matthias.koch@hot.uni-hannover.de> wrote:

>of course I know that you have developed a very good compiler with
>register allocation, available for many special CPU cores.

What I was asking for was to be acknowledged, just as I always
acknowledge systems like Mecrisp or other FOSS systems when asked
what is available.

>Unlike yours, which enjoys having a lot of memory available for many
>optimisation cases, mine has to fit entirely in small chips. Yours clearly
>shows its strength in tethered mode, but to cite your Euroforth article:
>
>http://www.complang.tuwien.ac.at/anton/euroforth/ef14/papers/pelc1.pdf
>
>"In our world, the cross compiler generates highly optimised code, but
>we are not really concerned with the quality of the code created by the
>target."

With a Raspberry Pi being cheaper than many Arduinos, we just decided
to go the Pi route where performance matters. In 10 years or so, the
majority of what are now deep-embedded systems are likely to be on
small boards with an OS of some sort. We have seen some truly dreadful
Linux implementations on such boards. The hard-real-time argument 
will only apply to a very small proportion of developers and most of
them will not know what you are talking about.

>This is exactly what I care about. Additionally, FOSS implementations
>neither have artificial limitations as your Lite compiler nor the 
>requirement to sign an NDA to see the complete compiler sources.

The FOSS versus proprietary argument is old and tired. It's just a
different business model - consultancy vs product.

MPE can and has put the full VFX code generator on a deep embedded
target.

However, in a work environment, trying to do deep embedded development
without a proper toolchain including something like a Segger J-Link
is just madness. In the C world, that's why companies like Rowley
are still in business and in the Forth world, companies like MPE
and Forth Inc. are still in business.

Just do not pretend that we do not exist.

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]

#40693

On Thursday, July 16, 2015 at 6:24:56 AM UTC-4, Matthias Koch wrote:
>to cite your Euroforth article:
> 
> http://www.complang.tuwien.ac.at/anton/euroforth/ef14/papers/pelc1.pdf
> 
> "In our world, the cross compiler generates highly optimised code, but we are not really concerned with the quality of the code created by the target."
> 
> This is exactly what I care about. 

I'd agree with Stephen that I'm not really concerned with this.
The time it takes to recompile and flash a processor today is seconds.  The host computer talking to the embedded system is doing very little if it is just relegated to being a terminal.  Let it do some work.
I find in my work that most of my errors have to do with things that are buried deep in systems (eg the interrupts or multitasking interactions).  I can't fix those easily with code interactively compiled.
I do want the interactive connection and compiling simple words via the tether is certainly desirable.  But at some point putting those changes into the source code and recompiling is, in my opinion, worthwhile.  Most of this discussion is where to draw that line.
So I'm happy with the model pushed by MPE. It's what I've used for 20 years with my own system.

>Additionally, FOSS implementations neither have artificial limitations as your >Lite compiler nor the requirement to sign an NDA to see the complete compiler >sources.

FOSS implementations are certainly interesting, but it can be difficult to make a living at.  Stephen sells one of the very best Forth compilers and I don't fault him for protecting his IP.  
I also enjoy looking at Mecrisp, but it's not VFX.
I've spent 20 years crafting my optimizing compiler, but I continue to be impressed with Stephen's product.

Gary

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

#40697

On 16/07/2015 6:26 AM, Matthias Koch wrote:
>Additionally, FOSS implementations
> neither have artificial limitations as your Lite compiler nor the
> requirement to sign an NDA to see the complete compiler sources.

I see the point on the Lite compiler, I don't see the
point of the NDA objection.

w..

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

#40710

I am a physicist and very curious on how it works internally. I simply would not recommend VFX for the hobbyist or the one who wishes to play with Forth internals. The in-target Lite compilers have their limits, and a NDA is not the right choice for FOSS freaks. The original question has been about Arduino Due, so I assumed an experimental environment.

Matthias

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

#40711

On Mon, 20 Jul 2015 11:57:46 +0200, Matthias Koch
<matthias.koch@hot.uni-hannover.de> wrote:

>I am a physicist and very curious on how it works internally.

The internals are described in EuroForth papers. The real problems for
people who want to write good compilers are that
a) Pattern matching (Timbre style) compilers are a dead end in
terms of ultimate code quality.
b) Analytical compilers take a lot of effort to write and take a
while to mature.

>I simply would not recommend VFX for the hobbyist

The Lite compiler is ideal for hobbyists who do not require a 
huge amount of optimised code. There is an upgrade path to the
inexpensive Stamp compiler.

> or the one who wishes to play with Forth internals.

You mean those who want the source code. The trouble is, when we did
not have an NDA on our source code, people ripped us off. Since we
introduced the NDA, we do not have that problem. Even the Lite
compiler comes with full source code for the target.

> and a NDA is not the right choice for FOSS freaks.

That's just politics and a different business model.

In the Forth world, if you want good code quality from a 
production-grade compiler, you have to use a commercial one. The
reason MPE was able to do it was that we put together a team and
funding to produce the VFX compiler chassis and the first few 
targets. There is nothing to stop a FOSS team doing the same.

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]

#40713

On Monday, July 20, 2015 at 8:37:42 AM UTC-4, Stephen Pelc wrote:
...
> The internals are described in EuroForth papers. The real problems for
> people who want to write good compilers are that
> a) Pattern matching (Timbre style) compilers are a dead end in
> terms of ultimate code quality.
> b) Analytical compilers take a lot of effort to write and take a
> while to mature.
...
> 
> Stephen

I'll take some exception to part a).  As a casual statement it is, of course, true.  By definition peephole optimizers have limited breadth in their scope but that doesn't mean that they should be dismissed.
Although I've never made my optimizer available, it is loosely based on Rob's Timbre work and generates very good code.  Not as good as VFX.  But still good enough for my consulting work for the last 10-15 years.  And like Stephen, I don't write in assembler anymore - the generated code from Forth source is good enough.  I periodically look at the generated assembly from the compiler and there is little to nothing that I can see to further optimize except in certain situations.  If performance is an issue in these cases I don't fall back to assembler, I write a new rule or two to handle that case.
A lot has to do with how you write the Forth source code.  Small definitions lend themselves to peephole compilation quite nicely.  And I make 6-8 different passes at the code with different rule sets for each pass.  Separating out different translation methods depending upon the goal goes a long way to making rulesets that are quick, simple, and effective.
I look at published optimized code and I'm not disappointed with what I have.  

That said, I don't think I've ever seen VFX produce "worse" code than my compiler.  But this style (peephole) of optimization can be relatively easy to learn and implement.  Had I appreciated this 30 years ago I would have jumped at it then.  Writing a complier like VFX is not for the faint of heart.

The most "fun" I had was porting to a tiny 'hc08.  An 8 bit Forth that ran multitasking on a part with 2k of flash and 128 bytes of RAM.  On such a small part the port only took a day or too.  

But porting to every new processor gets old.  I recently bought a license to VFX for Cortex parts and I'm happy with it.  There is room for both.

gary

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

#40727

On Mon, 20 Jul 2015 10:42:30 -0700 (PDT), Gary Bergstrom
<forthprgrmr@gmail.com> wrote:

>On Monday, July 20, 2015 at 8:37:42 AM UTC-4, Stephen Pelc wrote:
>...
>> The internals are described in EuroForth papers. The real problems for
>> people who want to write good compilers are that
>> a) Pattern matching (Timbre style) compilers are a dead end in
>> terms of ultimate code quality.
>> b) Analytical compilers take a lot of effort to write and take a
>> while to mature.

>I'll take some exception to part a).  As a casual statement it is, of cours=
>e, true.  By definition peephole optimizers have limited breadth in their s=
>cope but that doesn't mean that they should be dismissed.
...
>A lot has to do with how you write the Forth source code.  Small definition=
>s lend themselves to peephole compilation quite nicely.

I may have been a bit cruel. It is certainly true that on small and
irregular CPUs, pattern matchers can do a useful job. With enough
effort, you can do a reasonable job. However, the rule base size
becomes a problem after a while. Analytical compilers require much 
more structure to begin with, but take you further in the long term.

A typical VFX code generator requires an assembler, adisassembler, and
5000-6000 lines of Forth for the code generator itself. Of those
5000-6000 lines, about half is reusable for the next target.

>The most "fun" I had was porting to a tiny 'hc08.  An 8 bit Forth that ran =
>multitasking on a part with 2k of flash and 128 bytes of RAM.  On such a sm=
>all part the port only took a day or too. =20
>
>But porting to every new processor gets old.  I recently bought a license t=
>o VFX for Cortex parts and I'm happy with it.  There is room for both.

It's processors like the HC08/RS08 where a pattern matcher does well.

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]

#40714

stephen@mpeforth.com (Stephen Pelc) writes:
> The Lite compiler is ideal for hobbyists who do not require a 
> huge amount of optimised code. There is an upgrade path to the
> inexpensive Stamp compiler.

I'd agree with this if the hobbyist's goal is to get some gadget working
using Forth as a development tool like an oscilloscope, whose internals
they don't really care about.  If their interest is in language
implementations and Forth hacking per se, obviously not having source
code is a big drawback.

> Even the Lite compiler comes with full source code for the target.

Does that include the target-resident interpreter that will run on
Juergen's board?  I can understand if it doesnt, but it becomes a lot
more interesting if it does.

>> and a NDA is not the right choice for FOSS freaks.
> That's just politics and a different business model.

Agree.

> In the Forth world, if you want good code quality from a 
> production-grade compiler, you have to use a commercial one.

From seeing the huge Arduino world based around the AVR8 when they could
perfectly well be using Cortex M processors, I have to infer that code
speed (and therefore compiler optimizations) just plain don't matter for
a lot of embedded applications.  So from that perspective, I'd say the
attractions of VFX compared to something like Mecrisp are

     1) language features and libraries
     2) umbilical debugging; and
     3) optimizing compiler

in about that order, maybe with 1 and 2 switched.  I do think you'd
generate considerable interest in VFX Lite if you did an AVR target.  I
wonder if the introduction of the MSP432 (a Cortex M0 core with
MSP430-like marketing) means TI now sees the MSP430 as a dead end.  But
the AVR is still going strong.

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

#40719

On Mon, 20 Jul 2015 11:48:35 -0700, Paul Rubin
<no.email@nospam.invalid> wrote:

>> Even the Lite compiler comes with full source code for the target.
>
>Does that include the target-resident interpreter that will run on
>Juergen's board?  I can understand if it doesnt, but it becomes a lot
>more interesting if it does.

That's what I just said, so yes.

>From seeing the huge Arduino world based around the AVR8 when they could
>perfectly well be using Cortex M processors, I have to infer that code
>speed (and therefore compiler optimizations) just plain don't matter for
>a lot of embedded applications.  So from that perspective, I'd say the
>attractions of VFX compared to something like Mecrisp are
>
>     1) language features and libraries
>     2) umbilical debugging; and
>     3) optimizing compiler
>
>in about that order, maybe with 1 and 2 switched.  I do think you'd
>generate considerable interest in VFX Lite if you did an AVR target.

If code speed doesn't matter, use a Linux system to soak up all
those free cycles. It's interesting that a Raspberry Pi is cheaper
than an Arduino.

Being able to write interrupt handlers in high-level is the killer
item for any high-level language. I haven't written an ARM/Cortex
ISR in assembler for 10-15 years except to prove that I still
know how.

The AVR only has three address registers. That's good enough for C's
single frame stack, but not for Forth. A Cortex-M0 makes a far
better Forth engine than an AVR ... and is probably cheaper.
We had an AVR target for while - it was swept aside by ARM.

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]

#40721

stephen@mpeforth.com (Stephen Pelc) writes:
>>> Even the Lite compiler comes with full source code for the target.
>>Does that include the target-resident interpreter
> That's what I just said, so yes.

Oh neat, thanks!  Is there a url where I can download it?  I had
expected "compiler" was a cross-compiler where "source code for the
target" meant an address interpreter that would run headless code sent
by the closed-source compiler.  The text interpreter running on the
target sounded different so I had to ask for clarification.

> If code speed doesn't matter, use a Linux system to soak up all
> those free cycles. It's interesting that a Raspberry Pi is cheaper
> than an Arduino.

There are some expensive Arduinos but the entry level ones are much
cheaper than an RPi, plus they are way smaller and use much less power.
If you include the sub-Arduinos based on the ATTiny85, some of them are
really small and cheap:

  https://www.olimex.com/Products/Duino/AVR/OLIMEXINO-85S/
  http://digistump.com/products/1

They are too small (8k flash) to run a good resident Forth, but it would
be really cool to support them with a cross compiler.

> Being able to write interrupt handlers in high-level is the killer
> item for any high-level language. I haven't written an ARM/Cortex ISR
> in assembler for 10-15 years except to prove that I still know how.

Hmm, I guess that could be an issue for some things.  But even on an 8
Mhz part (the 5 volt AVR's are 12-16 mhz) you can usually afford a few
microseconds per interrupt, which is enough to run a bit of threaded
interpreted Forth code.

> The AVR only has three address registers. That's good enough for C's
> single frame stack, but not for Forth.

I'm not sure but I thought the AVR had a hardware stack pointer that
(like the program counter) is independent of the general purpose
registers.  So with subroutine threading you don't need an address
register (pair) for the R stack.  You can relative CALL to an address
within 2k words of the current pc in one 16-bit instruction word, which
should work out nicely for a small Forth.  I haven't looked at Amforth
though.

> A Cortex-M0 makes a far better Forth engine than an AVR ... and is
> probably cheaper.  We had an AVR target for while - it was swept aside
> by ARM.

The AVR has its good points including the PDIP-packaged (breadboard
friendly) Atmega328 having >2x more capacity than the MSP430G2553 while
costing around the same.  There aren't many PDIP ARM's.  Plus the AVR
can drive quite a lot of current from its gpio pins, enough to run stuff
like relays and leds.  Hardware guys tell me features like this keep the
AVR attractive.  I get the impression that ARMs are harder to program at
the low level, but I haven't tried it yet.

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

#40723

On Tue, 21 Jul 2015 00:32:32 -0700, Paul Rubin
<no.email@nospam.invalid> wrote:

>Oh neat, thanks!  Is there a url where I can download it?

Of course - try our web site.

http://lmgtfy.com/?q=mpe+lite+cross+compiler

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]

#40725

stephen@mpeforth.com (Stephen Pelc) writes:
>>Oh neat, thanks!  Is there a url where I can download it?
> Of course - try our web site.
> http://lmgtfy.com/?q=mpe+lite+cross+compiler

I did look at that page (http://www.mpeforth.com/xc7lite.htm), but as it
says at the top, it's about a cross compiler.  I'm asking about a
resident text interpreter that runs directly on the MSP430, like 4e4th.
Not a cross compiler.  Are you distributing something like that in
source code form?  I don't see any clear mention of that on your Lite
cross compiler page or in the linked doc files.  And then there's the
matter of how to bootstrap it.

The download that I see on that page is a Windows .exe that I have no
way to run or unpack.

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

#41268

On Monday, July 20, 2015 at 3:53:22 PM UTC-7, Stephen Pelc wrote:
> On Mon, 20 Jul 2015 11:48:35 -0700, Paul Rubin
> <no.email@nospam.invalid> wrote:
> 
> >> Even the Lite compiler comes with full source code for the target.

I don't blame Stephen Pelc for wanting to get paid, and for wanting to avoid getting ripped off --- so, holding onto the source-code or at least requiring an NDA is reasonable.

At Testra they had a different strategy. They built their own processor (the MiniForth, now called RACE). They make their money by selling motion-control boards and processor chips. I don't know that they have ever sold any chips by themselves, as they seem to sell only boards. The point though, is that they sell hardware not software. My MFX is given away for free --- it is only useful for generating code for the MiniForth/RACE so it can't be used to compete against Testra --- any use of it will necessarily require the user to buy chips or boards, and there is only one source for this.

> The AVR only has three address registers. That's good enough for C's
> single frame stack, but not for Forth. A Cortex-M0 makes a far
> better Forth engine than an AVR ... and is probably cheaper.
> We had an AVR target for while - it was swept aside by ARM.

I like the AVR. It does have only the X Y and Z register-pairs that can be used as pointers, but I don't see this as a big problem. Moving one register-pair into another is a one-cycle instruction --- so, just leave Z available as a general-purpose pointer and move your pointer into it as necessary.

The AVR code tends to be rather bloated. Also, the AVR lacks certain features that would improve both speed and size significantly. It is almost 20 years old, and it is the last 8-bit processor that is still a realistic target for Forth --- it is true that the ARM is the modern way, and the AVR is pretty retro.

Writing a compiler for either the AVR or the ARM or any other such processor is a waste of time --- it will get pirated if the source-code is made available, whether there is an NDA or not --- and, nobody will use it if the source-code is not available because they don't want to depend upon somebody else to support it, as that person may prove to be unreliable (highly likely, as there is no money to be made, and it is really just a hobby).

This is why I'm promoting the FMITE nowadays --- the only way to make money is with a custom processor --- that is what Testra did with the MiniForth/RACE and what I would like to do with the FMITE.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web