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

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

tethered Forth

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

Contents

  tethered Forth Paul Rubin <no.email@nospam.invalid> - 2013-09-07 12:25 -0700
    Re: tethered Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-09-07 10:40 -1000
      Re: tethered Forth Paul Rubin <no.email@nospam.invalid> - 2013-09-07 15:05 -0700
        Re: tethered Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-07 17:09 -0500
          Re: tethered Forth Paul Rubin <no.email@nospam.invalid> - 2013-09-07 15:38 -0700
            Re: tethered Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-08 02:09 -0500
        Re: tethered Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-09-07 22:21 -1000
          Re: tethered Forth Lars Brinkhoff <lars.spam@nocrew.org> - 2013-09-08 11:39 +0200
          Re: tethered Forth "Ed" <invalid@invalid.com> - 2013-09-09 22:42 +1000
          Re: tethered Forth Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-09-16 15:16 +0200
            Re: tethered Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-09-16 07:20 -1000
    Re: tethered Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-07 16:13 -0500
      Re: tethered Forth Paul Rubin <no.email@nospam.invalid> - 2013-09-07 18:00 -0700
      Re: tethered Forth Brad Eckert <hwfwguy@gmail.com> - 2013-09-08 11:00 -0700
        Re: tethered Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-09-08 08:55 -1000
          Re: tethered Forth Paul Rubin <no.email@nospam.invalid> - 2013-09-14 15:59 -0700
            Re: tethered Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-09-14 17:56 -1000
              Re: tethered Forth Paul Rubin <no.email@nospam.invalid> - 2013-09-15 22:27 -0700
                Re: tethered Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-09-15 21:18 -1000
                  Re: tethered Forth Paul Rubin <no.email@nospam.invalid> - 2013-09-16 22:46 -0700
                    Re: tethered Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-17 02:45 -0500
                Re: tethered Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-16 03:19 -0500
            Re: tethered Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-15 12:56 -0500
            Re: tethered Forth Brad Eckert <hwfwguy@gmail.com> - 2013-09-15 19:47 -0700
              Re: tethered Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-09-15 18:49 -1000
                Re: tethered Forth Brad Eckert <hwfwguy@gmail.com> - 2013-09-16 11:58 -0700
      Re: tethered Forth hughaguilar96@yahoo.com - 2013-09-10 20:47 -0700
    Re: tethered Forth bob.nash1@gmail.com - 2013-09-10 17:27 -0700
    Re: tethered Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2013-09-11 12:54 +0000
      Re: tethered Forth Paul Rubin <no.email@nospam.invalid> - 2013-09-14 15:53 -0700
        Re: tethered Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2013-09-15 17:14 +0000
          Re: tethered Forth Paul Rubin <no.email@nospam.invalid> - 2013-09-15 12:48 -0700
            Re: tethered Forth Gary Bergstrom <forthprgrmr@gmail.com> - 2013-09-17 13:46 -0700
              Re: tethered Forth Paul Rubin <no.email@nospam.invalid> - 2013-09-17 18:55 -0700
                Re: tethered Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-09-17 15:51 -1000
                Re: tethered Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2013-09-18 11:19 +0000
                  Re: tethered Forth Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-09-18 15:46 +0200
                  Re: tethered Forth Paul Rubin <no.email@nospam.invalid> - 2013-09-18 08:43 -0700
                Re: tethered Forth Brad Eckert <hwfwguy@gmail.com> - 2013-09-18 09:10 -0700
                Re: tethered Forth rickman <gnuarm@gmail.com> - 2013-09-18 20:20 -0400

Page 1 of 2  [1] 2  Next page →

#25556 — tethered Forth

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.

[toc] | [next] | [standalone]

#25558

On 9/7/13 9:25 AM, Paul Rubin 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?
>
> 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.

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

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

#25561

"Elizabeth D. Rather" <erather@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!

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

#25562

Paul Rubin <no.email@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.

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

#25563

Andrew Haley <andrew29@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.

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

#25565

Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@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.

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

#25569

On 9/7/13 12:05 PM, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@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.

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]

#25570

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.

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

#25589

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 :)

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

#25704

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

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

#25707

On 9/16/13 3:16 AM, Matthias Koch wrote:
> 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.

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.

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]

#25560

Paul Rubin <no.email@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.

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

#25564

Andrew Haley <andrew29@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.  

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

#25581

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.

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

#25582

On 9/8/13 8:00 AM, Brad Eckert wrote:
> 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.
>

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.

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]

#25667

"Elizabeth D. Rather" <erather@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.

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

#25671

On 9/14/13 12:59 PM, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@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?

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.

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]

#25697

"Elizabeth D. Rather" <erather@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.

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

#25698

On 9/15/13 7:27 PM, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@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.

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.

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]

#25717

"Elizabeth D. Rather" <erather@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.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web