tethered Forth

[Paul Rubin]

Tethering has the advantage that the text interpreter runs on a PC,
while the target processor only needs a tiny address interpreter, or
even just a boot point to jump to native code produced by the compiler.

What are the disadvantages? What are the main difficulties of
implementing a tethered Forth, compared to a regular one?

Is it normal when using one, to develop against the target from
beginning to end, or do you code on a desktop environment first (other
than parts that twiddle the target hardware intensively, and even that
can use emulations)?

This is the type of target I have in mind:

http://www.adafruit.com/blog/2013/09/03/new-products-adafruit-trinket-mini-microcontroller-3-3v-and-5-5v-versions-7-95/

It's an AVR Tiny with 8k of flash and 512B of ram. But even smaller
targets (say 1k flash / 128B ram) are also interesting.

[Elizabeth D. Rather]

FORTH, Inc. has used tethered cross-compilers exclusively for embedded
systems programming since the mid-80's. Their design has evolved
substantially in that time; there was a considerable learning curve
involved in making it a really transparent process, as similar as
possible to programming a resident system. A lot of this learning is
captured in the proposed cross-compiler standard, although the present
documents omit any discussion of the design and operation of an
umbilical link, and there has been a fair amount of further evolution
since it was written in the late 90's.

The only real disadvantage I know of is that it's more difficult
technically to develop a tethered cross-compiler as a DIY project for
someone who isn't thoroughly familiar with the internals of Forth and an
experienced Forth programmer.

For someone using one to write an embedded application, it's a pretty
nearly ideal programming environment.

Ideally, it's good to develop on target hardware exclusively. However,
the target-side does need a certain amount of RAM code space if you're
going to write test definitions, for example. If you're developing for a
high-volume target that needs an absolute minimum amount of RAM, I would
recommend using a target board during development that has generally the
same configuration but more RAM. Your final code can be all resident in
ROM or flash.

There are several problems with emulators, not the least of which is
that they're a project in and of themselves to develop. And then, the
emulation will be imperfect, and almost certainly very different as to
timing.

I'd really recommend that you spend some time using one of the available
evaluation systems to get a good feel for what it's like!

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."
==================================================

[Andrew Haley]

Paul Rubin <no.e...@nospam.invalid> wrote:
> Is it normal when using one, to develop against the target from
> beginning to end,

Yes. IME there really isn't much point developing on the host.

The traditional reason for developing on the host was that the
environment on the target was crap. Once you make it not crap -- by
using Forth -- all reasons for developing on the host evaporate.

Andrew.

[Paul Rubin]

"Elizabeth D. Rather" <era...@forth.com> writes:
> FORTH, Inc. has used tethered cross-compilers exclusively for embedded
> systems programming since the mid-80's.

Oh cool, so you don't use target-resident interpreters at all any more?
Interesting.

> there was a considerable learning curve .... A lot of this learning is

> captured in the proposed cross-compiler standard,

I did look at that and it seemed doable though there was an issue or two
that I didn't completely understand.

> although the present documents omit any discussion of the design and
> operation of an umbilical link,

Is that considered secret sauce, or is it just a matter of it not being
standardized yet? Are there any publications? I had been thinking in
terms of hacking up the gdb remote stub that is typically available for
target processors these days, to handle the target-side communications.

> The only real disadvantage I know of is that it's more difficult
> technically to develop a tethered cross-compiler as a DIY project

Yeah, that's the main part I wondered about. It also seems to me that
the language has to be restricted a little, since you (e.g.) can't have
target words running and affecting the compilation of later words the
same way, or launching defining words or whatever. But I hope this
isn't an issue in practice.

> For someone using one to write an embedded application, it's a pretty
> nearly ideal programming environment.

This sounds cool.

> If you're developing for a high-volume target that needs an absolute
> minimum amount of RAM, I would recommend using a target board during
> development that has generally the same configuration but more
> RAM. Your final code can be all resident in ROM or flash.

That makes sense. I had figured the tiniest processors aren't really
feasible targets because the stacks eat a fair amount of ram. I think
some AVR's have only 24 bytes or so of ram, but they have a lot of
registers (well, 32 minus a few special purpose ones). Maybe a smart
enough optimizing compiler could get rid of most stack operations and
slots, using the registers instead.

> I'd really recommend that you spend some time using one of the
> available evaluation systems to get a good feel for what it's like!

One of these days I'd like to watch an expert hack on Forth code for a
while. The thought processes seem different than other languages, which
is one of the reasons I find Forth interesting.

Regarding the evaluation systems, it's not real clear to me how one
targets the system to a specific board. Are there docs about that?

Thanks!

[Andrew Haley]

Paul Rubin <no.e...@nospam.invalid> wrote:
>
> Yeah, that's the main part I wondered about. It also seems to me that
> the language has to be restricted a little, since you (e.g.) can't have
> target words running and affecting the compilation of later words the
> same way,

Sure you can.

> or launching defining words or whatever.

The part before DOES> runs on the host, the part after on the target.
That's OK.

Andrew.

[Paul Rubin]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>> or launching defining words or whatever.
> The part before DOES> runs on the host, the part after on the target.
> That's OK.

Right, so if the part after DOES> calls something with CREATE, I'm sure
you get the picture. I'd hope that nobody actually does that in
embedded programming. It's conceivable that it's done in Forth compilers.

[Paul Rubin]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> The traditional reason for developing on the host was that the
> environment on the target was crap. Once you make it not crap -- by
> using Forth -- all reasons for developing on the host evaporate.

Hmm, ok, if there's no serious loss of effectiveness between a tethered
and a resident Forth, that's great. The small resident Forths I've been
looking at (mostly Eforth) noticably lack creature comforts compared to
the much larger Gforth.

[Andrew Haley]

Paul Rubin <no.e...@nospam.invalid> wrote:
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>> or launching defining words or whatever.
>> The part before DOES> runs on the host, the part after on the target.
>> That's OK.
>
> Right, so if the part after DOES> calls something with CREATE, I'm sure
> you get the picture.

So you have to say which DOES> you mean: there are two.

> I'd hope that nobody actually does that in embedded programming.

Why not? It can be really useful.

> It's conceivable that it's done in Forth compilers.

Hmmm, I'm not sure what this means.

Andrew.

[Elizabeth D. Rather]

On 9/7/13 12:05 PM, Paul Rubin wrote:
> "Elizabeth D. Rather" <era...@forth.com> writes:
>> FORTH, Inc. has used tethered cross-compilers exclusively for embedded
>> systems programming since the mid-80's.
>
> Oh cool, so you don't use target-resident interpreters at all any more?
> Interesting.

Haven't for a very long time now.

>> there was a considerable learning curve .... A lot of this learning is
>> captured in the proposed cross-compiler standard,
>
> I did look at that and it seemed doable though there was an issue or two
> that I didn't completely understand.

You're welcome to ask :-)

>> although the present documents omit any discussion of the design and
>> operation of an umbilical link,
>
> Is that considered secret sauce, or is it just a matter of it not being
> standardized yet? Are there any publications? I had been thinking in
> terms of hacking up the gdb remote stub that is typically available for
> target processors these days, to handle the target-side communications.

At the time, it seemed that the important thing was to get the
cross-compiling standardized and then look at the umbilicals. It just
hasn't happened. The target side is really very simple.

>> The only real disadvantage I know of is that it's more difficult
>> technically to develop a tethered cross-compiler as a DIY project
>
> Yeah, that's the main part I wondered about. It also seems to me that
> the language has to be restricted a little, since you (e.g.) can't have
> target words running and affecting the compilation of later words the
> same way, or launching defining words or whatever. But I hope this
> isn't an issue in practice.

The only "restriction" (if you call it that) is that the target doesn't
normally have a compiler. It is possible, but that's the advanced
course, and not really appropriate or necessary most of the time.

>> For someone using one to write an embedded application, it's a pretty
>> nearly ideal programming environment.
>
> This sounds cool.
>
>> If you're developing for a high-volume target that needs an absolute
>> minimum amount of RAM, I would recommend using a target board during
>> development that has generally the same configuration but more
>> RAM. Your final code can be all resident in ROM or flash.
>
> That makes sense. I had figured the tiniest processors aren't really
> feasible targets because the stacks eat a fair amount of ram. I think
> some AVR's have only 24 bytes or so of ram, but they have a lot of
> registers (well, 32 minus a few special purpose ones). Maybe a smart
> enough optimizing compiler could get rid of most stack operations and
> slots, using the registers instead.

No, it's not the stacks that are a problem. What you want the extra RAM
for is so you can download new definitions into the target and test
them, without having to burn flash.

>> I'd really recommend that you spend some time using one of the
>> available evaluation systems to get a good feel for what it's like!
>
> One of these days I'd like to watch an expert hack on Forth code for a
> while. The thought processes seem different than other languages, which
> is one of the reasons I find Forth interesting.

Yws, it is somewhat different. You feel intimate with the system, not
like a person using an external tool. Think of a sculptor molding clay
with his bare hands. That's what it feels like. Thoughts turn into code
in what feels like an organic process.

> Regarding the evaluation systems, it's not real clear to me how one
> targets the system to a specific board. Are there docs about that?

The systems all come pre-configured for one of a list of boards. They're
all pretty cheap, and you may already have one. If not, you have the
ability to adjust most of the parameters. The only limitation on the
FORTH, Inc. evals is that you can't build a very large target
application. They all come with at least one, and sometimes several,
sample target apps to work with.

[Lars Brinkhoff]

Elizabeth D. Rather wrote:
> Think of a sculptor molding clay with his bare hands. That's what it
> feels like. Thoughts turn into code in what feels like an organic
> process.

Cool, that's *exactly* the metaphor I've been thinking coding in
another interactive extensible language feels like. And I'm striving
to get there using Forth too. In comparison, C and similar languages
are more like hacking chips off a cliff.

[Brad Eckert]

On Saturday, September 7, 2013 5:13:10 PM UTC-4, Andrew Haley wrote:
> The traditional reason for developing on the host was that the
> environment on the target was crap. Once you make it not crap -- by
> using Forth -- all reasons for developing on the host evaporate.

What kind of terminal would you use these days? I see some VT-100 emulators for Android.

[Elizabeth D. Rather]

Well, the subject is tethered cross-compilers, so the host is a lot more
than a terminal. It's providing the compiler, transparent downloading,
and a relationship to the target that *feels* like a terminal, but is in
fact doing more.

You're sitting there typing on your PC. You type in a colon definition
on the command line (or, actually, even a CODE definition, for that
matter). The definition is compiled, possibly using a smart optimizing
code compiler, and automatically downloaded to the target. You type some
numeric arguments and the name of your new definition. The arguments,
which went onto your host's stack, are passed to the target, which is
then commanded to execute the new definition. It does so. It's stack is
then passed back to the host, so you can examine the results.

If you type, HERE 40 DUMP the host gets 40 bytes from the target's data
space and displays it on your screen.

All the execution occurs on the target, but the host is providing the
compiler, assembler, target memory management, and transparent
interaction. Only executable code and data space exists on the target.
The host manages the dictionary and your access to data space.

Andrew was referring to the whole environment, which includes the
relationship between the host and target, which provides far more
capability than a limited target-resident Forth, and far, far more than
host-only development.

[Ed]

Elizabeth D. Rather wrote:
> On 9/7/13 12:05 PM, Paul Rubin wrote:

> > ...

> > Yeah, that's the main part I wondered about. It also seems to me that
> > the language has to be restricted a little, since you (e.g.) can't have
> > target words running and affecting the compilation of later words the
> > same way, or launching defining words or whatever. But I hope this
> > isn't an issue in practice.
>
> The only "restriction" (if you call it that) is that the target doesn't
> normally have a compiler. It is possible, but that's the advanced
> course, and not really appropriate or necessary most of the time.

Not long ago I was being told how great and important it was for
apps to have a compiler on board. It's amazing what difference a
few months make :)

[bob....@gmail.com]

I routinely program for Target processors with 256 bytes of ram and 8K of flash (Silicon Laboratories C8051F300 or C8051F850). For many projects I use both tethering and a standalone interpreter.

Standalone interpreters are nice if you want to exercise the chip using commands sent from a dumb terminal. Or, to implement complex functionality using a basic command repertoire and scripting (poor man's Forth). The overhead for the standalone interpreter I use is 447 bytes and 6 bytes per interpretable definition (count, first three chars and 2-byte execution vector).

Tethering is nice because you don't have to define each command to be exercised. Target overhead is trivial: the tether can just receive a two-byte execution vector and jump to it, signaling the Host when done. Multi-byte responses are possible (and straightforward to implement) but beyond the scope of this response.

On I/O restricted processors (such as the one ATtiny85), the tethering (and standalone) is a bit trickier. If you have a UART and a serial port to burn (two I/O lines), fine. Otherwise, using a one-wire tether, you need to deal with line turnaround, bit-banged serial, etc.

Solutions for this exist, but are beyond the scope, etc.

Having used several SwiftX products from Forth, Inc., I can say that a tethered development environment, well-implemented, is a pleasure to use.

BTW, the C8051F850 chip is only $0.88 in small quantity and has 2+ I/O ports and UART. Perhaps worth checking out. You can get it soldered on a Toolstick daughtercard for $10 (includes on-board LEDs and switches). The programming adapter is about $17. But, it is an 8051 processor and perhaps of little interest to Arduino fans.

[hughag...@yahoo.com]

On Saturday, September 7, 2013 2:13:10 PM UTC-7, Andrew Haley wrote:
> Paul Rubin <no.e...@nospam.invalid> wrote:

> > Is idt normal when using one, to develop against the target from

> > beginning to end,
>
> Yes. IME there really isn't much point developing on the host.
>
> The traditional reason for developing on the host was that the
> environment on the target was crap. Once you make it not crap -- by
> using Forth -- all reasons for developing on the host evaporate.

MFX developed on the host. It wasn't that the target environment was "crap" --- the target processor just didn't exist yet. Throughout most of the development of MFX, the MiniForth itself was under development. The definition of the MiniForth changed on an almost daily basis. Both MFX and the motion-control program were completed using simulation prior to the MiniForth existing as a physical chip.

This is the best way to develop a new processor. I think it is a big mistake to develop a new processor and then afterward develop a compiler for it --- because you don't know what instructions you want until you have the compiler working and discover that your compiler is generating inefficient code with the instructions that you have, and would generate better code with a different instruction set. The processor and the compiler are developed in conjunction so that each can be molded to fit the other.

It is true that developing on the host and uploading entire programs to the target, is not very interactive. With a tethered system, you are uploading portions of code to the target on the fly, and the whole process is interactive, similar to developing on the target itself as in a traditional Forth. That is what I've heard anyway, as I've never used a tethered system.

After I left Testra, they used MFX to write a traditional Forth that ran on the target. Most likely, the just didn't know how to write a tethered system. I could do it, but I was gone by that time. Anyway, the MiniForth is a pretty big processor and it can support a traditional Forth easily, so a tethered system wasn't really needed. I think that tethered systems would mostly be useful for processors that are too small to support both a Forth compiler and an application program.

The problem with a traditional Forth on a processor such as the MiniForth, is that it can only be used to develop Forth code, but not assembly-language code. This is because the processor is Harvard architecture, with the Forth code and the data in one memory, and the machine-code in another memory --- the latter being memory that can't be written to by the processor itself. Because of this, Testra must still be using my MFX when they need to write assembly-language code --- it is just not possible to do that with a Forth running on the MiniForth itself.

[Stephen Pelc]

On Sat, 07 Sep 2013 12:25:48 -0700, Paul Rubin
<no.e...@nospam.invalid> wrote:

>Tethering has the advantage that the text interpreter runs on a PC,
>while the target processor only needs a tiny address interpreter, or
>even just a boot point to jump to native code produced by the compiler.
>
>What are the disadvantages? What are the main difficulties of
>implementing a tethered Forth, compared to a regular one?

Very few. The main issues are always the comms link and the Flashing.

>Is it normal when using one, to develop against the target from
>beginning to end, or do you code on a desktop environment first (other
>than parts that twiddle the target hardware intensively, and even that
>can use emulations)?

It's rare that a PC can run an extrusion pump ... or ...

Tethered or umbilical systems have been around since at least the
1980s - I remember presenting a paper on the topic at a Rochester
conference only to be followed by two more from other people. The
issue nowadays is that you can buy a much more capable 32 bit CPU,
e.g. Cortex-M0, for the same money as a small 8-bitter. The only
exception is if you need huge volume. At the same time, Forth
compilers now have much better code generation and clients want
much more complex applications.

The Adafruit example is only a little cheaper than something like
an STM32 Discovery board, which is far more capable. If you just
like small CPUs, TI's MSP430 Launchpads are good, as is the core
itself.

If you go with a modern CPU, the choice of standalone or umbilical
development is a matter of preference.

Stephen


--
Stephen Pelc, steph...@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

[Paul Rubin]

steph...@mpeforth.com (Stephen Pelc) writes:
> The Adafruit example is only a little cheaper than something like
> an STM32 Discovery board, which is far more capable.

Yeah, the nice thing about the Adafruit board is it's really tiny, and I
get the impression it's less fuss to program. You've been using the
STM32? Is there much headache getting it booted and running, without
some monstrous dev environment from Keil or whatever?

> If you just like small CPUs, TI's MSP430 Launchpads are good, as is
> the core itself.

I do have an MSP430 Launchpad but with 16k flash / 512B ram, some of the
tiny ATmega boards are actually more powerful (plus smaller). I guess
the next thing up in very small boards is the Teensy 3.0.

My immediate application for the attiny board involves just monitoring a
few sensors and triggering an output pin on certain sensor events. An 8
bitter seems fine for that.

[Paul Rubin]

"Elizabeth D. Rather" <era...@forth.com> writes:

> You type some numeric arguments and the name of your new
> definition. The arguments, which went onto your host's stack, are
> passed to the target, which is then commanded to execute the new

> definition. ...

> All the execution occurs on the target, but the host is providing the

> compiler, assembler, target memory managem...

This is a part I'm wondering about. How do you decide what gets
run on the host? E.g. if I type "2 3 + ." are you saying 2 and 3
go on the host stack, then + copies the host stack to the target
stack, and . runs on the target and sends output back to the host?
Why does "2" not immediately push 2 on the target stack?

Thanks.

[Elizabeth D. Rather]

The host interpreter processes the line. 2 and 3 go initially on the
host stack, which is passed to the target. The host commands the target
to execute + and . and then copies the target stack back to the host.

The host commands are:

* Here's my stack.

* Execute +

* Execute . (the target's output routines send text to the host for display)

* send me your stack.

Pretty simple. The host's TARGET dictionary contains the heads of the
target words, and the equivalent target xts. The target contains the
executable code in its code space, plus its data space.

[Stephen Pelc]

On Sat, 14 Sep 2013 15:53:57 -0700, Paul Rubin
<no.e...@nospam.invalid> wrote:

>You've been using the
>STM32? Is there much headache getting it booted and running, without
>some monstrous dev environment from Keil or whatever?

The MPE Forth ARM/Cortex cross compiler, including the Stamp edition,
supports the STM32F4 processors. You do not need a big environment
to develop for them.

>I do have an MSP430 Launchpad but with 16k flash / 512B ram, some of the
>tiny ATmega boards are actually more powerful (plus smaller). I guess
>the next thing up in very small boards is the Teensy 3.0.

How is an AVR more powerful than an MSP430? Just because the chips
on the Launchpad are RAM limited says nothing about the relative
merits of the families. Without an explanation of your priorities,
I don't understand what you want.

>My immediate application for the attiny board involves just monitoring a
>few sensors and triggering an output pin on certain sensor events. An 8
>bitter seems fine for that.

IMHO, in this environment the distinction between 8. 16, and 32 bit
CPUs is irrelvant. Adafruit will sell you a minimal LPC810 kit for
very little. That's an 8 pin 32 bit CPU.

[Andrew Haley]

It could be done that way, but it doesn't happen because 2 is not a
word in the target dictionary.

Andrew.

[Paul Rubin]

steph...@mpeforth.com (Stephen Pelc) writes:
>>I do have an MSP430 Launchpad but with 16k flash / 512B ram, some of the
>>tiny ATmega boards are actually more powerful (plus smaller).

> How is an AVR more powerful than an MSP430? Just because the chips
> on the Launchpad are RAM limited says nothing about the relative
> merits of the families.

The comparison is specifically between the Atmega processors found on
(e.g.) the Teensy boards, vs the MSP430 processor found on the
Launchpad. The Atmegas are more powerful than the largest Launchpad
processor in the sense of having more program capacity and ram. There
may be other members of the MSP430 family that have more capacity than
the Atmega, but they are not compatible with the Launchpad. The bigger
MSP430's are rather expensive and it probably makes more sense to use an
ARM. The most interesting MSP430's are the FRAM models and it would be
great if they made some Launchpad compatible versions.

> IMHO, in this environment the distinction between 8. 16, and 32 bit
> CPUs is irrelvant. Adafruit will sell you a minimal LPC810 kit for
> very little. That's an 8 pin 32 bit CPU.

Thanks, I see http://www.adafruit.com/products/1336 and it's indeed
interesting, but it's a bag of parts rather than being a complete,
assembled board like the Trinket. Loading code into it apparently
involves a complex procedure, while for the Trinket I can just plug in a
USB cable and run AVRDude. It also has just 4k of program flash, vs 8k
for the Trinket, 16k for the Launchpad, 32k for the Atmega32u4, etc.
The Digispark (http://digistump.com/products/1) is comparable to the
Trinket and even plugs directly into a USB port.

[Brad Eckert]

On Saturday, September 14, 2013 6:59:08 PM UTC-4, Paul Rubin wrote:
>
> Why does "2" not immediately push 2 on the target stack?
>

It could. You could have a dedicated debug task with its own data and return stacks. Elizabeth described the SwiftX XTL, which probably evolved from earlier Forths.

When I got around to inspecting the 8051 version of SwiftX, I was surprised at how lightweight the implementation was. But it doesn't have to be done that way, and there are reasons you might not want to.

I've run a debug task where the host-based interpreter pushed numbers onto the target stack right away and it worked fine. This was on a CPU that didn't have interrupts. The UART was polled by the debug task, which was in the PAUSE chain.

[Elizabeth D. Rather]

Sure, there are lots of ways of implementing it. The target has a task
which is communicating with the host. That might or might not be one of
the tasks executing the target application, but at least in early stages
of debugging it is.

The SwiftX concept of having the host stack echo the stack of the target
task that's doing the communication simplifies things for the user, who
simply doesn't have to think about the host as an intermediary. The
objective is to make the host as transparent as possible. Since the host
already has the capability of exhibiting its stack, there are no other
mechanisms needed to monitor the target's stack, providing their
contents are kept the same.

[Paul Rubin]

"Elizabeth D. Rather" <era...@forth.com> writes:

> "2 3 + ."

> The host interpreter processes the line. 2 and 3 go initially on the
> host stack, which is passed to the target.

When is it passed to the target? As soon as the 3 is processed on the
host side? Or when + is looked up (and found) in the target dictionary?

What happens if you say "2 3 dup"? Does the host stack still have
"2 3" while the target stack has "2 3 3"?

[other post]

> Since the host already has the capability of exhibiting its stack,

How do you exhibit the host stack, if most or all of the words like "."
are intercepted by the target dictionary and run on the target instead
of the host? Are there special host words that are kept from being
redefined for the target somehow?

I had been thinking of having separate host and target windows on the
screen, or something like that. Maybe that's not Forth-like though.

Thanks as always.

[Elizabeth D. Rather]

In SwiftForth and SwiftX, the stack is always visible in the bottom
pane. Where there's not a GUI (e.g. Mac) it's at the end of each line.

The host processes the input stream. In other words, the host passes its
stack to the target, requests the target to execute one or more words,
and gets a stack back. If the target aborts for any reason, that process
is cut short, otherwise not. Since it's all happening in milliseconds or
less, more interaction wouldn't be meaningful.

The concept we're trying to maintain is that the host is transparent.
Displaying two windows would not only require a lot more code, but
wouldn't give you any more information. It would be a distraction. You
don't want to care about the host, you want it to be transparent.

[Andrew Haley]

Paul Rubin <no.e...@nospam.invalid> wrote:
> "Elizabeth D. Rather" <era...@forth.com> writes:
>> "2 3 + ."
>> The host interpreter processes the line. 2 and 3 go initially on the
>> host stack, which is passed to the target.
>
> When is it passed to the target? As soon as the 3 is processed on the
> host side? Or when + is looked up (and found) in the target dictionary?
>
> What happens if you say "2 3 dup"? Does the host stack still have
> "2 3" while the target stack has "2 3 3"?

There is only one stack: it is either on the host or the target.

Andrew.

[Matthias Koch]

Hello Elisabeth,

yes, I have a question:

If something compiling on the host can be optimized directly to machine code,
or only depends on definitions already downloaded before then it is fine to
just download the new code into the target memory.

But what happens if I use a definition like / or */ that is neither available
as short opcode sequence nor in target memory yet for size reasons ?

I suppose the host downloads needed definitions (maybe recursively if they
have further dependencies) when they are used for the first time into target ?

This is interesting for me as there are MSP430F2012 chips with 2k Flash
and 128 Bytes RAM which cannot hold a lot of core definitons.

Best wishes,
Matthias

[Elizabeth D. Rather]

Well, you start with a kernel that has all the basic code that you need
to support your application. It resides in flash. 2K isn't very much;
the SwiftX kernel for the MSP430's is about 6K. It can be shrunk (in my
classes students make a traffic intersection controller which can
eventually be reduced to about 1K, kernel included), but for general
development it would be better to use an MSP with more memory. In other
words, you can possibly get your finished application to run on that
part, but it's ill-suited to development.

[Brad Eckert]

On Monday, September 16, 2013 12:49:14 AM UTC-4, Elizabeth D. Rather wrote:

> The SwiftX concept of having the host stack echo the stack of the target
> task that's doing the communication simplifies things for the user, who
> simply doesn't have to think about the host as an intermediary. The
> objective is to make the host as transparent as possible. Since the host
> already has the capability of exhibiting its stack, there are no other
> mechanisms needed to monitor the target's stack, providing their
> contents are kept the same.
>

This approach provides a way to bring up a new port quickly. Get the tether code working first, without ISRs or PAUSE, and use it to debug the kernel. Then integrate it a little better with, say, an ISR.

[Paul Rubin]

"Elizabeth D. Rather" <era...@forth.com> writes:
> The concept we're trying to maintain is that the host is
> transparent.

OK, I think I get it, this stuff about copying stacks around is just an
implementation artifact and it would work as well if every token
(including literals) were transferred to the target immediately.
This is cool, it's as if you're talking to the target all the time.
Thanks.

[Andrew Haley]

And it makes testing easy. You can do stuff like

host : testing
n 0 do
args [target] word word word
[host] args word word word
-compare if ... test failed ... then
loop ;

Host words can call target words and pass arguments on the stack, so
you can run the same words on each and compare the results. This is
like RPC but far easier to use.

Andrew.

[Gary Bergstrom]

On Sunday, September 15, 2013 3:48:00 PM UTC-4, Paul Rubin wrote:

> ... (Stephen Pelc) writes:
>
> >>I do have an MSP430 Launchpad but with 16k flash / 512B ram, some of the
> >>tiny ATmega boards are actually more powerful (plus smaller).
>
> > How is an AVR more powerful than an MSP430? Just because the chips
> > on the Launchpad are RAM limited says nothing about the relative
> > merits of the families.
>
> The comparison is specifically between the Atmega processors found on
> (e.g.) the Teensy boards, vs the MSP430 processor found on the
> Launchpad. The Atmegas are more powerful than the largest Launchpad
> processor in the sense of having more program capacity and ram. There
> may be other members of the MSP430 family that have more capacity than
> the Atmega, but they are not compatible with the Launchpad. The bigger
> MSP430's are rather expensive and it probably makes more sense to use an
> ARM. The most interesting MSP430's are the FRAM models and it would be
> great if they made some Launchpad compatible versions.
>

There are two flavors of the TI MSP430 Launchpad. The $10 value line version and the $13 one with more memory - 8k RAM, 128k flash. That should be big enough. The two are binary compatible so moving from one to the other is trivial.
As to which family is more "powerful" - memory size is not a good determination of "power" of an embedded processor.

As Stephen has noted, the 32bit ARM boards are also quite available and run rings around the 8/16 bit chips. And the mA/MIPS numbers rival the best as does the price. Hard to justify sticking with the old other than familiarity and inertia.

Gary

[Paul Rubin]

Gary Bergstrom <forth...@gmail.com> writes:
> There are two flavors of the TI MSP430 Launchpad. The $10 value line
> version and the $13 one with more memory - 8k RAM, 128k flash.

Thanks! The bigger one is a new and interesting development that I
didn't know about. It must have just been released recently, after they
increased the Value Line launchpad price from $4.30. Some info is here:

http://processors.wiki.ti.com/index.php/MSP430F5529_LaunchPad

It has USB but looks like you need some kind of proprietary libraries in
order to use it :-(

> As Stephen has noted, the 32bit ARM boards are also quite available
> and run rings around the 8/16 bit chips. And the mA/MIPS numbers
> rival the best as does the price. Hard to justify sticking with the
> old other than familiarity and inertia.

The MSP430 seemed like a sweet spot for a while, but now looks unhappily
squeezed between 8 and 32 bitters. You're probably right that there's
not much point any more to large MSP430's, unless you get one with
special hardware features like FRAM.

8 bitters still have their place as they are available in small packages
and are simpler to program, at least using FOSS tools.

[Elizabeth D. Rather]

On 9/17/2013 3:55 PM, Paul Rubin wrote:
> Gary Bergstrom <forth...@gmail.com> writes:
>> There are two flavors of the TI MSP430 Launchpad. The $10 value line
>> version and the $13 one with more memory - 8k RAM, 128k flash.
>
> Thanks! The bigger one is a new and interesting development that I
> didn't know about. It must have just been released recently, after they
> increased the Value Line launchpad price from $4.30. Some info is here:
>
> http://processors.wiki.ti.com/index.php/MSP430F5529_LaunchPad
>
> It has USB but looks like you need some kind of proprietary libraries in
> order to use it :-(

FORTH, Inc. uses TI's library for the Windows side, and a native USB
driver based on (but quite different from) their code.

>> As Stephen has noted, the 32bit ARM boards are also quite available
>> and run rings around the 8/16 bit chips. And the mA/MIPS numbers
>> rival the best as does the price. Hard to justify sticking with the
>> old other than familiarity and inertia.
>
> The MSP430 seemed like a sweet spot for a while, but now looks unhappily
> squeezed between 8 and 32 bitters. You're probably right that there's
> not much point any more to large MSP430's, unless you get one with
> special hardware features like FRAM.
>
> 8 bitters still have their place as they are available in small packages
> and are simpler to program, at least using FOSS tools.

The big advantage of the MSP430 remains its ability to run really low
power. The SwiftX kernel on the MSP has an adapted multitasker loop that
automatically optimizes the use of low power mode, so it has duty cycles
measured in microseconds.

[Stephen Pelc]

On Tue, 17 Sep 2013 18:55:51 -0700, Paul Rubin
<no.e...@nospam.invalid> wrote:

>8 bitters still have their place as they are available in small packages
>and are simpler to program, at least using FOSS tools.

"at least using FOSS tools". That's the rub. Sometimes you need to
buy tools, especially if you need advanced tools.

[Matthias Koch]

Stephen Pelc schrieb:

> "at least using FOSS tools". That's the rub. Sometimes you need to
> buy tools, especially if you need advanced tools.

I disagree, at least for software tools.
Not everyone likes to sign an NDA to see compiler sources.
You are right that FOSS tools available today in this niche still need work,
but I have done a big step forward for MSP430 and I am just filling the gap for ARM Cortex chips.

On some types of hardware tools, I agree.

Matthias

[Paul Rubin]

steph...@mpeforth.com (Stephen Pelc) writes:
> "at least using FOSS tools". That's the rub. Sometimes you need to
> buy tools, especially if you need advanced tools.

Even if you're willing to buy tools on the host side, some applications
require 100% auditability of the target code. It might be ok in such a
situation to compare the source code going into a proprietary compiler
with the assembly code coming out as part of the audit, but there can't
be any mysterious binary blobs running in the target, and this seems
hard to avoid with some devices, notoriously the Raspberry Pi. .

[Brad Eckert]

On Tuesday, September 17, 2013 9:55:51 PM UTC-4, Paul Rubin wrote:
>
> The MSP430 seemed like a sweet spot for a while, but now looks unhappily
> squeezed between 8 and 32 bitters.

The MSP430 is a way for TI to sell chips. If I need an MCU with a 24-bit ADC in it, they have a 430 derivative at a nice price point. I suspect that chips with sensitive analog peripherals would be easier to build with lower power CPUs.

[rickman]

There is price too. 8 bit MCUs are still cheaper than 16 bit parts
which are cheaper than 32 bit parts. Of course this only matters if you
are high volume because the difference has gotten pretty small.

--

Rick