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

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

Parallax Propeller

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

Contents

  Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-13 06:37 +0000
    Re: Parallax Propeller MK <mk@nospam.co.uk> - 2013-01-13 10:26 +0000
      Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-13 12:22 +0000
        Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-13 07:24 -0600
          Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-13 13:55 +0000
            Re: Parallax Propeller mhx@iae.nl (Marcel Hendrix) - 2013-01-13 17:13 +0200
              Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-16 06:23 -0600
                Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-16 15:01 +0000
                  Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-16 09:12 -0600
                    Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-16 15:36 +0000
                      Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-16 10:59 -0600
                        Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-16 23:38 +0000
                          Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-17 04:04 -0600
                      Re: Parallax Propeller Mark Wills <forthfreak@gmail.com> - 2013-01-17 04:52 -0800
                      Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-24 22:48 -0800
                        Re: Parallax Propeller Mark Wills <forthfreak@gmail.com> - 2013-01-24 23:10 -0800
                          Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-28 17:42 -0800
                            Re: Parallax Propeller "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-05 06:05 -0500
                              Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-05 08:41 -0600
                                Re: Parallax Propeller Paul Rubin <no.email@nospam.invalid> - 2013-02-05 10:21 -0800
                                  Re: Parallax Propeller Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-05 21:37 +0100
                                    Re: Parallax Propeller "Elizabeth D. Rather" <erather@forth.com> - 2013-02-05 10:44 -1000
                                  Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-05 15:52 -0600
                                    Re: Parallax Propeller Paul Rubin <no.email@nospam.invalid> - 2013-02-06 00:29 -0800
                                      Re: Parallax Propeller Paul Rubin <no.email@nospam.invalid> - 2013-02-06 00:31 -0800
                                        Re: Parallax Propeller Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-06 19:46 +0100
                                          Re: Parallax Propeller Paul Rubin <no.email@nospam.invalid> - 2013-02-09 00:11 -0800
                                            Re: Parallax Propeller anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-09 10:25 +0000
                                      Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-06 18:26 -0800
                                  Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-05 15:07 -0800
                              Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-05 15:49 -0800
                        Re: Parallax Propeller "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-05 06:04 -0500
                          Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-05 15:21 -0800
                  Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-16 18:09 -0500
            Re: Parallax Propeller Ben Bradley <ben_u_bradley@etcmail.com> - 2013-01-18 21:07 -0500
              Re: Parallax Propeller "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2013-01-19 10:06 +0000
                Re: Parallax Propeller Arlet Ottens <usenet+5@c-scape.nl> - 2013-01-19 13:04 +0100
                Re: Parallax Propeller "A. K." <akk@nospam.org> - 2013-01-19 13:22 +0100
                  Re: Parallax Propeller Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-19 13:38 +0100
                Re: Parallax Propeller David Brown <david.brown@removethis.hesbynett.no> - 2013-01-19 17:12 +0100
                  Re: Parallax Propeller albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-01-19 16:45 +0000
                    Re: Parallax Propeller David Brown <david.brown@removethis.hesbynett.no> - 2013-01-20 17:49 +0100
                  Re: Parallax Propeller upsidedown@downunder.com - 2013-01-19 20:54 +0200
                    Re: Parallax Propeller Paul Rubin <no.email@nospam.invalid> - 2013-01-19 11:04 -0800
                      Re: Parallax Propeller upsidedown@downunder.com - 2013-01-19 23:05 +0200
                        Re: Parallax Propeller Mark Wills <markrobertwills@yahoo.co.uk> - 2013-01-20 01:05 -0800
                          Re: Parallax Propeller Arlet Ottens <usenet+5@c-scape.nl> - 2013-01-20 12:11 +0100
                            Re: Parallax Propeller upsidedown@downunder.com - 2013-01-20 13:53 +0200
                          Re: Parallax Propeller upsidedown@downunder.com - 2013-01-20 13:26 +0200
                    Re: Parallax Propeller Les Cargill <lcargill99@comcast.com> - 2013-01-19 14:23 -0600
                  Re: Parallax Propeller Les Cargill <lcargill99@comcast.com> - 2013-01-19 14:18 -0600
                    Re: Parallax Propeller David Brown <david.brown@removethis.hesbynett.no> - 2013-01-20 20:32 +0100
                      Re: Parallax Propeller Les Cargill <lcargill99@comcast.com> - 2013-01-20 18:08 -0600
                  Re: Parallax Propeller Walter Banks <walter@bytecraft.com> - 2013-01-20 17:12 -0500
                    Re: Parallax Propeller Mel Wilson <mwilson@the-wire.com> - 2013-01-20 19:19 -0500
                      Re: Parallax Propeller Walter Banks <walter@bytecraft.com> - 2013-01-20 21:12 -0500
                    Re: Parallax Propeller David Brown <david@westcontrol.removethisbit.com> - 2013-01-21 09:01 +0100
                      Re: Parallax Propeller Walter Banks <walter@bytecraft.com> - 2013-01-21 21:11 -0500
                    Re: Parallax Propeller upsidedown@downunder.com - 2013-01-22 09:39 +0200
                      Re: Parallax Propeller Mel Wilson <mwilson@the-wire.com> - 2013-01-22 10:14 -0500
                Re: Parallax Propeller Waldek Hebisch <hebisch@math.uni.wroc.pl> - 2013-01-20 02:03 +0000
              Re: Parallax Propeller George Neuner <gneuner2@comcast.net> - 2013-01-19 12:29 -0500
                Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-23 12:29 -0500
                  Re: Parallax Propeller Mark Wills <markrobertwills@yahoo.co.uk> - 2013-01-24 14:03 -0800
                    Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-24 22:55 -0800
                      Re: Parallax Propeller Mark Wills <forthfreak@gmail.com> - 2013-01-24 23:03 -0800
                        Re: Parallax Propeller Coos Haak <chforth@hccnet.nl> - 2013-01-25 20:02 +0100
                        Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-28 17:13 -0800
                          Re: Parallax Propeller David Brown <david@westcontrol.removethisbit.com> - 2013-01-29 09:15 +0100
                            Re: Parallax Propeller Anders.Montonen@kapsi.spam.stop.fi.invalid - 2013-01-30 12:19 +0000
                              Re: Parallax Propeller David Brown <david.brown@removethis.hesbynett.no> - 2013-01-30 21:18 +0100
                                Re: Parallax Propeller Mark Wills <forthfreak@gmail.com> - 2013-01-30 22:57 -0800
                                  Re: Parallax Propeller Alex McDonald <blog@rivadpm.com> - 2013-01-31 10:38 -0800
                                    Re: Parallax Propeller Mark Wills <forthfreak@gmail.com> - 2013-01-31 12:34 -0800
              Re: Parallax Propeller Paul Rubin <no.email@nospam.invalid> - 2013-01-19 10:42 -0800
                Re: Parallax Propeller bob@bob.com - 2013-01-19 19:56 -0600
                  Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-23 12:40 -0500
                  Re: Parallax Propeller None <vandys@vsta.org> - 2013-01-24 23:26 +0000
                    Re: Parallax Propeller Walter Banks <walter@bytecraft.com> - 2013-01-25 11:49 -0500
                    Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-25 09:25 -0500
                    Re: Parallax Propeller None <vandys@vsta.org> - 2013-01-25 21:57 +0000
                      Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-26 18:07 -0500
                        Re: Parallax Propeller Mark Wills <markrobertwills@yahoo.co.uk> - 2013-01-27 00:50 -0800
                          Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-27 03:30 -0600
                          Re: Parallax Propeller Dombo <dombo@disposable.invalid> - 2013-01-27 12:58 +0100
                          Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-28 21:38 -0500
                      Re: Parallax Propeller None <vandys@vsta.org> - 2013-01-27 03:09 +0000
                        Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-28 21:51 -0500
                        Re: Parallax Propeller None <vandys@vsta.org> - 2013-01-30 02:10 +0000
                          Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-30 18:32 -0500
              Re: Parallax Propeller David Schultz <abuse@127.0.0.1> - 2013-01-20 11:21 -0600
        Re: Parallax Propeller albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-01-13 16:24 +0000
        Re: Parallax Propeller David Brown <david@westcontrol.removethisbit.com> - 2013-01-14 10:51 +0100
          Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-16 06:06 +0000
            Re: Parallax Propeller David Brown <david@westcontrol.removethisbit.com> - 2013-01-16 13:43 +0100
              Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-16 15:27 +0000
        Re: Parallax Propeller Rafael Deliano <rafael_deliano@arcor.de> - 2013-01-15 21:10 +0100
          Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-16 06:26 +0000
        Re: Parallax Propeller gavino_himself <visploveslisp@gmail.com> - 2013-01-22 06:26 -0800
      Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-13 12:44 +0000

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

#19481

Paul Rubin wrote:

> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> I think closures are more C++ than C.  Closures are really just about
>> notational convenience and expressiveness.  There is nothing that you
>> can't write in C, but it might be a lot of C.
> 
> C++11 has anonymous functions but they're not Scheme-like closures
> from
> what I can tell.  Closures seem much less useful without garbage
> collection.  Their point is that any variables that are bound in the
> surrounding context but free in the nested function, have their values
> copied into the closure when the closure is created, and the closure
> (with those values) stays around after the surrounding function has
> returned.  Languages without first-class functions usually do this
> sort of thing with OOP or similar.

C++11 "closures" are indeed that: OOP classes that have an overloaded 
function call operator, which actually invokes a method.

I don't think that's too wrong.  That's the way to do it in an OOP 
language.  The way I would implement this sort of pseudo-closures in 
current Gforth (with OOP vtable for compile, and other stuff) is to 
instantiate an object on the heap, which gets its first part filled with 
a dodoes CFA and the apropriate vtable for compile, and the other 
instance variables are filled with values from the stack.  Call it, and 
the xt bound to it can access these variables.

Freeing of no longer needed closures would be explicit.  Syntax 
something like

[:{ a b } ... use of a and b ... ;]

a and b would normal current-object ivars, and the setting of the 
current object would be compiled into the quotation-like stuff.  To free 
it, you simply "dispose" the xt.

The difference from C++11's closures: This would be a real first class 
function.  It would just be implemented with some minor OOP technique 
(instance variables).  The ivars would live in the same temporary 
dictionary region that's used for local variables, too.  They would 
actually be a variant of ivars which use TO for assignments...

The point of Forth design is not to exactly mimic something else, which 
is overly complex or requires fundamental design changes to the 
language, but build a tool, which solves the essence of the problem in a 
way that is more natural to Forth.

Example: Let's have a Forth closure for a counter.  We give it 
initialization value and increment.  With real closures, you would do 
that as follows:

: counter { start inc -- xt }
  [: ( -- value ) start inc + dup to start ;] ;

i.e. you create the locals outside the closure.  The way as above would 
be

: counter ( start inc -- xt )
  [:{ start inc -- value } start inc + dup to start ;] ;

This makes it an extension to Forth, which require some carnal knowledge 
(how to add words to the locals space), but otherwise fits into the 
standard design decisions of a Forth system, i.e. no garbage collection, 
and no non-trivial lexical scoping.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#19482

On 2/5/13 10:37 AM, Bernd Paysan wrote:
...
> The point of Forth design is not to exactly mimic something else, which
> is overly complex or requires fundamental design changes to the
> language, but build a tool, which solves the essence of the problem in a
> way that is more natural to Forth.
>
> Example: Let's have a Forth closure for a counter.  We give it
> initialization value and increment.  With real closures, you would do
> that as follows:
>
> : counter { start inc -- xt }
>    [: ( -- value ) start inc + dup to start ;] ;
>
> i.e. you create the locals outside the closure.  The way as above would
> be
>
> : counter ( start inc -- xt )
>    [:{ start inc -- value } start inc + dup to start ;] ;
>
> This makes it an extension to Forth, which require some carnal knowledge
> (how to add words to the locals space), but otherwise fits into the
> standard design decisions of a Forth system, i.e. no garbage collection,
> and no non-trivial lexical scoping.

Ok. But what is the advantage of doing this vs. simply writing the 
definition in the conventional way?

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]

#19485

Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> I think closures are more C++ than C.  Closures are really just about
>> notational convenience and expressiveness.  There is nothing that you
>> can't write in C, but it might be a lot of C.
> 
> C++11 has anonymous functions but they're not Scheme-like closures
> from what I can tell.  Closures seem much less useful without
> garbage collection.  Their point is that any variables that are
> bound in the surrounding context but free in the nested function,
> have their values copied into the closure when the closure is
> created, and the closure (with those values) stays around after the
> surrounding function has returned.

Sure, but what's your point?  C++ does this, even though it's up to
you to free the closure.

Andrew.

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

#19497

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> Sure, but what's your point?  C++ does this, even though it's up to
> you to free the closure.

Here is an idiomatic use of a closure in Python, to make a simple
on-screen GUI keyboard:

    import Tkinter as T
    def press(key): print 'you pressed', key
    T.Tk()
    def make_keyboard():
        for i,cs in enumerate(['qwertyuiop','asdfghjkl;','zxcvbnm,./']):
            for j,c in enumerate(cs):
                T.Button(text=c,command=lambda k=c: press(k)) \
                   .grid(row=i,column=j)
    make_keyboard()
    T.mainloop()

The closure is the callback expression 

   lambda k=k: press(k)

which is a bit ugly because of Python's weird scoping rules, but the
point is that it creates a callable object that wraps the value of k,
and passes that into the bowels of the GUI framework, which squirrels it
away and calls it through some inscrutable mechanism (maybe in another
thread, etc.) when the user presses buttons.  It would be useless if
the closure didn't persist after the make_keyboard call returned.

Python style note: these days it's also possible and maybe nicer to use
functools.partial(press, k).

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

#19498

Paul Rubin <no.email@nospam.invalid> writes:
>    lambda k=k: press(k)
Oops,
     lambda k=c: press(k)

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

#19515

Paul Rubin wrote:

> Paul Rubin <no.email@nospam.invalid> writes:
>>    lambda k=k: press(k)
> Oops,
>      lambda k=c: press(k)

Well, currying is totally trivial in Forth, once you accept that you 
can't reclaim the memory for the curried function:

: curry ( lit xt -- xt' )  >r >r
  :noname r> postpone literal r> compile, postpone ; ;

Test it:

3 ' + curry alias 3+  ok
5 3+ . 8  ok

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#19571

Bernd Paysan <bernd.paysan@gmx.de> writes:
> : curry ( lit xt -- xt' )  >r >r
>   :noname r> postpone literal r> compile, postpone ; ;

I can't really understand that without studying deep-down parts of Forth
compilation that I haven't had to use so far.  One thing I'd wonder is
whether you can have a mutable cell in the closure.  E.g. a classic
Scheme closure is:

   (define (counter)
     (let ((n 0))
       (lambda ()
          (set! n (1+ n))
          n)))

This creates a variable n, then a function (the lambda) which, when you
call it, increments n and returns the new value, something like an
OOP method incrementing and returning an instance variable

    guile> (define a (counter))
    guile> (define b (counter))

That made two counters each with its own n.  Now you can call them
independently of each other:

    guile> (a)
    1
    guile> (a)
    2
    guile> (a)
    3
    guile> (b)
    1
    guile> (b)
    2
    guile> (a)
    4

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

#19574

Paul Rubin <no.email@nospam.invalid> writes:
>Bernd Paysan <bernd.paysan@gmx.de> writes:
>> : curry ( lit xt -- xt' )  >r >r
>>   :noname r> postpone literal r> compile, postpone ; ;
>
>I can't really understand that without studying deep-down parts of Forth
>compilation that I haven't had to use so far.

Given your interests, I would highly recommend studying these features
soon.  E.g., take a look at

http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/POSTPONE-Tutorial.html
http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Literal-Tutorial.html
http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Advanced-macros-Tutorial.html
http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Compiling-words.html

Deep down?  Not really.

>One thing I'd wonder is
>whether you can have a mutable cell in the closure.  E.g. a classic
>Scheme closure is:
>
>   (define (counter)
>     (let ((n 0))
>       (lambda ()
>          (set! n (1+ n))
>          n)))
>

Sure:

: docounter ( addr -- n )
  1 over +! @ ;

: counter ( -- )
  here 0 , >r :noname r> postpone literal postpone docounter postpone ; ;

counter alias a
counter alias b
a . a . a . b . b . a .

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

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

#19521

On Feb 6, 1:29 am, Paul Rubin <no.em...@nospam.invalid> wrote:
> The closure is the callback expression

I like that term, "callback," as it is pretty self-descriptive ---
terms such as "closure," "quotation" and "lambda" don't really provide
any hint as to what they mean. "Closure" seems to indicate that
something is being closed, but what? "Quotation" seems to indicated a
text string containing prose, but that is not it. "Lambda" is just a
Greek letter, and it has no meaning whatsoever.

In my novice package I used the term "toucher" which was really dumb
sounding --- I'm going to drop that.

I have been thinking of using the term "operative" --- that is quite
descriptive, as the creator function is sending it out into the world,
but it maintains communication with the creator function by way of the
creator function's local variables which it has access to. Besides
that, it gives programming a cloak-and-dagger aspect! :-)

Does anybody other than the Python crowd use the term "callback"? If
it is popular, maybe I will go with it, as it is at least somewhat
self-descriptive.

> the
> point is that it creates a callable object that wraps the value of k,
> and passes that into the bowels of the GUI framework, which squirrels it
> away and calls it through some inscrutable mechanism (maybe in another
> thread, etc.) when the user presses buttons.  It would be useless if
> the closure didn't persist after the make_keyboard call returned.

I don't get at all what the point is of having a quotation, or
callback function, be executable after the creator has gone out of
scope. What is it calling back to? It is like E.T. trying to phone
home, but there is no planet there anymore.

I really don't get what the point of this is. Why not just use :NONAME
instead???

Allowing a quotation to be executable after the creator function has
gone out of scope, requires that the creator function's local
variables be in the heap rather than on a locals stack --- but
ALLOCATE is typically very slow compared to a stack, and GC is very
messy in Forth --- that is an incredibly complicated solution to a non-
problem.

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

#19487

On Feb 5, 11:21 am, Paul Rubin <no.em...@nospam.invalid> wrote:
> Andrew Haley <andre...@littlepinkcloud.invalid> writes:
> > I think closures are more C++ than C.  Closures are really just about
> > notational convenience and expressiveness.  There is nothing that you
> > can't write in C, but it might be a lot of C.
>
> C++11 has anonymous functions but they're not Scheme-like closures from
> what I can tell.  Closures seem much less useful without garbage
> collection.  Their point is that any variables that are bound in the
> surrounding context but free in the nested function, have their values
> copied into the closure when the closure is created, and the closure
> (with those values) stays around after the surrounding function has
> returned.  Languages without first-class functions usually do this sort
> of thing with OOP or similar.

I think that GC is totally wrong for Forth. If people want GC, then
they should program in Scheme or one of the many Scheme-derived
languages, but not in Forth --- Forth is for micro-controllers, and
there is no way to distinguish between integers and pointers, so GC is
just not a good idea. I also think that OOP is totally wrong for
Forth, for the same reasons.

My closures are pretty simple. They do NOT "stay around after the
surrounding function has returned" --- if the creator function (what
you call surrounding function, or some call parent function) has gone
out of scope, executing the closure will abort the program with a
helpful error message. Also, my closures can't be nested, so they
can't be used for control-structures (IF, WHILE, etc.) and/or stack-
manipulation (DIP, etc.) as done in Factor (I didn't really like
Factor, as I thought that the quotations were overused). My closures
(or quotations, whatever you want to call them) are primarily only for
iterators. These are similar to EACH in my novice package. The
iterator typically iterates through a data structure (list, tree,
whatever), and applies the closure to every node --- the closure can
communicate with its creator function by way of the creator function's
local variables, which the closure has access to. The purpose of this
is to save the programmer from using cut-and-paste code to iterate
through data structures, which makes his source-code bloated,
difficult to read and error-prone. There are two kinds of factoring;
internal and external. External has always been used in Forth, and was
championed by Chuck Moore as a fundamental aspect of Forth
programming. Internal requires closures, and is largely unknown to
Forth programmers.

What I'm doing is pretty simple. I am keeping it simple so that it
will work on micro-controllers. That is a big part of why I'm
targeting the PIC24 first. The PIC24 is pretty small by modern
standards, so if I can get my language to work on it, then it should
work on anything. Getting a language to work on the ARM isn't going to
do me much good, as the ARM is a pretty big processor and it has
already been done to death. Slava told me that he is targeting the ARM
with Factor, and that he thinks the ColdFire is the smallest processor
that could support Factor. By comparison, the ColdFire and ARM are
gigantic processors from my perspective. My background is in writing
MFX for the MiniForth --- and the MiniForth is an extremely low-level
processor (it was built on a PLD), which makes the PIC24 look like a
giant.

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

#19489

On Feb 5, 4:05 am, "Rod Pemberton" <do_not_h...@notemailnotz.cnm>
wrote:
> "Hugh Aguilar" <hughaguila...@yahoo.com> wrote in message
>
> news:a4032a5a-73c6-485e-8ffa-2ec01da40f51@po6g2000pbb.googlegroups.com...
> ...
>
> > By comparison, Straight Forth will be all about
> > supporting modern concepts such as closures ---
>
> People keep telling me C needs this closure concept also.  I have
> yet to run into some situation that can't be coded in C.  I've
> coded alot of simple stuff and well as some really complex stuff.
> So, what do I need closures for?  I suspect the same issue I have
> with not needing them is true for Forth too.  I.e., closures are
> desired by you because it fits your coding style or perhaps your
> way of thinking, but they're not _really_ needed.  If they're not
> *really* needed, should the be present in the language proper?
> That's really a question for comp.lang.misc.

Of course I'm implementing closures because they fit my programming
style. Who else would I care about other than myself?

> However, I think your goal actually requires more than just
> eliminating all the ancient Forth cruft.  I think you should start
> by naming things what they should've be named, e.g., logical not
> named NOT, etc.  The names need to make sense.  ANS and earlier
> standards renamed a few things to prevent namespace collisions.
> Unfortunately, that means that some names make no sense.  That
> alienates programmers.  Also, I think you should adopt C style
> symbol operators instead of using word names, e.g., AND, OR, XOR,
> NOT, etc for logical and binary operations.  Most currently
> successful modern languages have adopted C's style of naming for
> such operators.  Forth needs some minimal syntax, like braces { },
> needs some operators other than +! to manipulate variables
> directly, etc.  Non-use of variables, specifically, heavy
> dependence on the stack, also leads to hard to comprehend code.

I am renaming some words. For example, NOT will do what 0= currently
does in ANS-Forth. I will have FLIP for doing a logical not.

I don't think that symbolic tokens && || etc. are a good idea --- I
think that AND and OR etc. are more readable. I'm not firm on this
though --- maybe I will take your suggestion about using C-style names
rather than Pascal-style names.

I have no idea what { } braces are going to do for me. Can you
elaborate on this?

I have a lot of words similar to +! but for other kinds of operations
--- -! *! /! mod! and! or! xor! etc.. These not only improve the
readability, but they are make a VM simpler (that is actually why C
originally had += etc., because it was originally a VM similar to
Forth).

> Once
> you start radically changing things on your own to "fix" Forth,
> i.e., StraightForth, it's not really going to be Forth anymore, at
> least not in the classic sense.  That's something I think you
> haven't truly accepted yet.  If you did, we'd be seeing your
> progress reports, your questions, your website, etc.  I.e.,
> StraightForth is a stalled idea since it seems apparent you're not
> actually working on it.  If you're attempting to inspire interest
> in it to attract developers, perhaps you just need to ask.

Straight Forth won't be anything like ANS-Forth --- Straight Forth is
the future, and ANS-Forth is the past.

Straight Forth has been stalled several times. I get depressed, and I
stop working on it. Forth is really dead, and it has a very bad
reputation as being a haven for incompetents (it is difficult to fake
competence in C as almost everybody knows C, but a phony can fake
expertise in Forth and imagine that he's fooling everybody, as very
few people know enough about Forth to readily distinguish between
baloney and fact) --- because of this, the vast majority of
programmers will ignore anything related to Forth without looking at
it at all, and Straight Forth would be doomed just because of the word
Forth being part of the name.

Recently however, I have come up with several ideas that have gotten
me excited about the project again (not closures or getting rid of DO
loops, which are old ideas for me, and not all that innovative) ---
because of this, I am now working diligently on Straight Forth again.
I threw out everything that I wrote previously, and started over from
scratch. I've done that more than once already, but hopefully what
I've got going this time is the design that I ultimately want, and I
will carry it through to completion.

Anyway, what is the hurry? Nobody else is doing anything innovative at
all in Forth, so no matter how long I take I will still be the
firstust with the mostust. Well, Passaniti has written a Forth-like
interpreter in Perl --- that has really got me shaking in my boots
(from laughter!).

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

#19451

"Hugh Aguilar" <hughaguilar96@yahoo.com> wrote in message
news:2bb0e774-9b80-44ae-8873-0d16dbb07335@t6g2000pba.googlegroups.com...
...

> I am getting rid of DO loops altogether in Straight Forth. I'm
> also getting rid of >R R@ R> etc., or at least deprecating them.

Sigh ...  Hugh, Hugh, Hugh!  How many  _years_  have you been
saying this?  Just do it already.

Years ago, a friend of a friend of mine always just happened to
come around at the same time that I'd be telling a story he'd
already heard to someone who hadn't already heard that story
before.  Of course, this guy would interrupt and point out just
how many times he had heard the story previously.  ... 2 ... 3 ...
8 ...  He was really irritating.  Of course, he probably thought I
was really irritating for telling the same story over and over.
He probably thought I was a bore too or perhaps forgetful.  But, I
wasn't telling *him* the story over and over.  I only told him the
story once.  I was telling another person or people the story for
the first time.  He consistently butted into or joined the telling
of the story to others.  From my perspective, he had no tact or
was inconsiderate or rude.  He wouldn't let me tell my stories to
someone new without aggravating me by pointing out that he'd heard
it already.  Even though it was clear he was the only one present
uninterested hearing my story, he wouldn't leave the area.  If he
had thought about who was present at the time each story was told,
he might've realized that *he* was the only person consistently
present.

So, from my perspective, you're the bore in this case ...  I guess
that makes me the irritant.  ;-)  Of course, Mark or anyone else
here could be the irritant, since everyone here for more than a
year or two has heard you say you're going to eliminate >R R@ R>
from StraightForth over and over and over ... yet again.  We're
waiting.  We're hoping.  Just do it already.

> I use BEGIN loops with local variables for iteration. DO loops
> were invented in the 1970s, prior to Forth having local
> variables --- I and J are just crude implementations of
> local variables.

I wouldn't know about that.

I and J do need to save and move around _two_ data items, at least
in my current implementation ...

> I think that DO loops are overly complicated.

I agree that the *implementation* of DO loops is overly
complicated.  Their use seems simple enough, though.

> It is weird to have I and J available only in the loop
> and not outside.

Huh?  Do you mean have I and J available only in the _inner_
loop of two loops, with the outer loop's I equivalent to the inner
loop's J, and not have either available outside both loops, or
somesuch ... ?

> Also, if you have nested loops, I means one
> thing in the outer loop and something else in the inner loop ---
> that's confusing.

That's simply because I and J are stacked and not in memory as
named variables.  If you use variables, I will always be I and J
will always be J, yes?  Then, Forth becomes more like the BASIC
that you desire in regards to I and J and likely K too.  It's a
simple change.  Do it, already.  Of course, *NOT* using the a
stack for I and J, wouldn't be the "Forth way", i.e., "you can't
do that" ...

> Also, it is very confusing that >R R@ R> etc. can be
> used in a colon word, but they can't carry values into the DO
> loop --- so they can't really be used as local variables, which
> is their intended purpose.

Personally, I don't "see" use as "local variables" as the intended
purpose of >R R@ R> and/or RDROP etc.  The purpose is to
effectively implement either 1) an "infinite" tape as it's known
for a Turing machine, or 2) the equivalent of stack frames for a
0-operand language.  Basically, with >R R@ R> both the
data/parameter stack and the return/control stack, become a single
stack for manipulating data.  >R R@ R> function similarly to a
stack pointer, e.g., ESP and EBP combination for 32-bit x86
assembly, allowing the coder to move up and down the stack to the
collection of data items they wish to manipulate.  Each collection
of data items can be viewed as a stack frame.

(Recently, you said you finally learned something from me ...  Did
you learn something from this last paragraph?  If not, I have to
assume it's a fault on your part, not mine.)

> DO loops are also anti-intuitive and confusing when
> you are descending rather than ascending. All in all, DO
> loops are an ugly kludge from the 1970s that can be discarded.

Sigh, transparent, I'll feign that I'm not being baited ...

So, what type of looping construct do you recommend, Hugh?  Have
you created a new one?  Are you willing to share it with others
here or is it proprietary?  I've not yet noticed you starting a
thread on a new loop method for Forth.  If I have to, desire to,
or it results in better code, I can use a while(1) loop in C - the
simplest available for C - for any situation that requires a loop.
However, C provides a richer set of loop constructs, where less
coding is required.  Are you stating that you'd like to eliminate
higher level loops in Forth?

> Also, I have separate stacks for single-precision and
> double-precision data (and a third stack for floats) --- 

Massive overkill?

> I don't jumble different types of data together on the same
> stack as done in ANS-Forth, which is another 1970s kludge
> (jumbling everything together was originally done
> due to a shortage of registers and shortage of memory).

True, probably.  Although, early Forths likely didn't have as many
different types of data either.  I.e., they didn't need multiple
stacks, in the first place.  So, why implement them?  That begs
the question of what is the actually the cause and what is the
effect.


Rod Pemberton

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

#19488

On Feb 5, 4:04 am, "Rod Pemberton" <do_not_h...@notemailnotz.cnm>
wrote:
> "Hugh Aguilar" <hughaguila...@yahoo.com> wrote in message
> > I think that DO loops are overly complicated.
>
> I agree that the *implementation* of DO loops is overly
> complicated.  Their use seems simple enough, though.
>
> > It is weird to have I and J available only in the loop
> > and not outside.
>
> Huh?  Do you mean have I and J available only in the _inner_
> loop of two loops, with the outer loop's I equivalent to the inner
> loop's J, and not have either available outside both loops, or
> somesuch ... ?
>
> > Also, if you have nested loops, I means one
> > thing in the outer loop and something else in the inner loop ---
> > that's confusing.
>
> That's simply because I and J are stacked and not in memory as
> named variables.  If you use variables, I will always be I and J
> will always be J, yes?  Then, Forth becomes more like the BASIC
> that you desire in regards to I and J and likely K too.  It's a
> simple change.  Do it, already.  Of course, *NOT* using the a
> stack for I and J, wouldn't be the "Forth way", i.e., "you can't
> do that" ...
>
> > Also, it is very confusing that >R R@ R> etc. can be
> > used in a colon word, but they can't carry values into the DO
> > loop --- so they can't really be used as local variables, which
> > is their intended purpose.
>
> Personally, I don't "see" use as "local variables" as the intended
> purpose of >R R@ R> and/or RDROP etc.  The purpose is to
> effectively implement either 1) an "infinite" tape as it's known
> for a Turing machine, or 2) the equivalent of stack frames for a
> 0-operand language.  Basically, with >R R@ R> both the
> data/parameter stack and the return/control stack, become a single
> stack for manipulating data.  >R R@ R> function similarly to a
> stack pointer, e.g., ESP and EBP combination for 32-bit x86
> assembly, allowing the coder to move up and down the stack to the
> collection of data items they wish to manipulate.  Each collection
> of data items can be viewed as a stack frame.
>
> (Recently, you said you finally learned something from me ...  Did
> you learn something from this last paragraph?  If not, I have to
> assume it's a fault on your part, not mine.)
>
> > DO loops are also anti-intuitive and confusing when
> > you are descending rather than ascending. All in all, DO
> > loops are an ugly kludge from the 1970s that can be discarded.
>
> Sigh, transparent, I'll feign that I'm not being baited ...
>
> So, what type of looping construct do you recommend, Hugh?  Have
> you created a new one?  Are you willing to share it with others
> here or is it proprietary?  I've not yet noticed you starting a
> thread on a new loop method for Forth.  If I have to, desire to,
> or it results in better code, I can use a while(1) loop in C - the
> simplest available for C - for any situation that requires a loop.
> However, C provides a richer set of loop constructs, where less
> coding is required.  Are you stating that you'd like to eliminate
> higher level loops in Forth?

DO loops are not just complicated to implement, but they are also
complicated to learn, and they are error-prone to use. My loops are
much more similar to C's than Forth's.

> > Also, I have separate stacks for single-precision and
> > double-precision data (and a third stack for floats) ---
>
> Massive overkill?
>
> > I don't jumble different types of data together on the same
> > stack as done in ANS-Forth, which is another 1970s kludge
> > (jumbling everything together was originally done
> > due to a shortage of registers and shortage of memory).
>
> True, probably.  Although, early Forths likely didn't have as many
> different types of data either.  I.e., they didn't need multiple
> stacks, in the first place.  So, why implement them?  That begs
> the question of what is the actually the cause and what is the
> effect.

Using multiple stacks actually simplifies the user's source-code
considerably. Most of the stack-juggling that gives Forth a reputation
for unreadability, is due to having too much data on the stack, and
having double-width data mixed together with single-width data on the
same stack. By having one stack for single-width and another stack for
double-width, I eliminate a lot of stack-juggling --- this is a very
Forth-like solution, as it also eliminates the need for local
variables (which Forth purists don't like, and which are the sign of
the recalcitrant C programmer).

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

#18865

On 1/16/2013 10:01 AM, Peter Jakacki wrote:
>
> There is no reason why we can't have more than two stacks in Forth
> especially considering that the return stack normally gets loop
> parameters and other stuff shoved onto it when this could lead to crashes
> if this stack has "junk" on it when Forth exits from a word. So I tend to
> use a LOOP stack to hold the stack index and limits plus in Tachyon I
> introduced the BRANCH stack which holds the backward branch address of
> loops rather than having to read these from slow hub RAM each time and
> calculating the branch.

Using a separate stack for the loop parameters won't prevent bugs in 
your programs.  If you mismanage any of the stacks you will have a bug. 
  It may not cause a "crash", but what's the difference?  Loops out of 
control aren't a lot different from a crash.

I haven't looked at your forth.  Just not enough hours in the day...

Rick

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

#18889

U=In comp.lang.forth,comp.arch.embedded On Sun, 13 Jan 2013 13:55:22
GMT, Peter Jakacki <peterjakacki@gmail.com> wrote:


>Yes, when you run a task in a cog then that is all it has to do. There is 
>no need for task switching or interrupts etc. Some of my biggest 
>headaches had to do with mysterious glitches which always end up being 
>traced back to the wrong interrupts at the wrong time, but only 
>sometimes, just to make it harder to find.

   So you're PREVENTED from using interrupts to make programming
easier. 

>
>The P2 which is due to be released soon 

... still has zero interrupts.

Yes, I first saw the propellor mentioned years ago, the 8 32-bit cores
thing sounds nice, but no interrupts was a deal killer for me. A year
or two back (with maybe earlier mention of the P2) I looked on the
"official" support/discussion forums for the Propellor and saw this
longish thread on "why doesn't it have interrupts" and there were
posts there that covered every objection I've had or seen to a
microcontroller not having interrupts, even  "why not add interrupts?
It would take very little silicon and you don't have to use 'em if you
don't want to." It's against that designer guru guy's religion or
something.

As far as I know there's no other microcontroller that doesn't have
interrupts, and I can't recall one that didn't. The Apple ][ didn't
use interrupts even though the 6502 had them. Maybe there were some
4-bit microprocessors that didn't have any interrupts.

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

#18891

Ben Bradley wrote:

> U=In comp.lang.forth,comp.arch.embedded On Sun, 13 Jan 2013 13:55:22
> GMT, Peter Jakacki <peterjakacki@gmail.com> wrote:

[%X]

>>The P2 which is due to be released soon
> 
> ... still has zero interrupts.
> 
> Yes, I first saw the propellor mentioned years ago, the 8 32-bit cores
> thing sounds nice, but no interrupts was a deal killer for me. A year
> or two back (with maybe earlier mention of the P2) I looked on the
> "official" support/discussion forums for the Propellor and saw this
> longish thread on "why doesn't it have interrupts" and there were
> posts there that covered every objection I've had or seen to a
> microcontroller not having interrupts, even  "why not add interrupts?
> It would take very little silicon and you don't have to use 'em if you
> don't want to." It's against that designer guru guy's religion or
> something.
> 
> As far as I know there's no other microcontroller that doesn't have
> interrupts, and I can't recall one that didn't. The Apple ][ didn't
> use interrupts even though the 6502 had them. Maybe there were some
> 4-bit microprocessors that didn't have any interrupts.

One question you should ask yourself is why you think a parallel processor 
(particularly the mesh organised ones) really need to include interrupts. 
You have many processors, all the same, simple, no frills. You can afford to 
dedicate a processor to deal with inputs that need to be responded to 
rapidly without the need for interrupts. I know that, to some, it might seem 
a waste of a processor, but with heavily parallel chips you could afford to 
think about how you allocate I/O around the processor array.

Check back in the history of processors and you will see why the interrupt 
was thought to be necessary in the first place. With the world heading to 
the much more use of multi-parallel processor I suspect the need for 
interrupts will wane.

-- 
********************************************************************
Paul E. Bennett...............<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

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

#18892

On 01/19/2013 11:06 AM, Paul E. Bennett wrote:

>> As far as I know there's no other microcontroller that doesn't have
>> interrupts, and I can't recall one that didn't. The Apple ][ didn't
>> use interrupts even though the 6502 had them. Maybe there were some
>> 4-bit microprocessors that didn't have any interrupts.
>
> One question you should ask yourself is why you think a parallel processor
> (particularly the mesh organised ones) really need to include interrupts.
> You have many processors, all the same, simple, no frills. You can afford to
> dedicate a processor to deal with inputs that need to be responded to
> rapidly without the need for interrupts. I know that, to some, it might seem
> a waste of a processor, but with heavily parallel chips you could afford to
> think about how you allocate I/O around the processor array.
>
> Check back in the history of processors and you will see why the interrupt
> was thought to be necessary in the first place. With the world heading to
> the much more use of multi-parallel processor I suspect the need for
> interrupts will wane.

Why not let the end user decide whether interrupts are useful ? Adding 
the support is not that complicated, and allows you to have a single 
processor performing multiple tasks, and still achieve low latency 
response to external events.

If I need a fast and predictable (but very simple) response to an 
external event, it is a waste to dedicate an entire processor to the 
job. If you don't care about wasting silicon, why not waste some on some 
interrupt logic, and offer the best of both worlds ?

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

#18893

On 19.01.2013 11:06, Paul E. Bennett wrote:
>  You can afford to
> dedicate a processor to deal with inputs that need to be responded to
> rapidly without the need for interrupts. I know that, to some, it might seem
> a waste of a processor, but with heavily parallel chips you could afford to
> think about how you allocate I/O around the processor array.

While this is true, polling produces heat.
BTW can unused cogs be sent to sleep to reduce power consumption?

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

#18894

A. K. wrote:

> On 19.01.2013 11:06, Paul E. Bennett wrote:
>>  You can afford to
>> dedicate a processor to deal with inputs that need to be responded to
>> rapidly without the need for interrupts. I know that, to some, it
>> might seem a waste of a processor, but with heavily parallel chips
>> you could afford to think about how you allocate I/O around the
>> processor array.
> 
> While this is true, polling produces heat.
> BTW can unused cogs be sent to sleep to reduce power consumption?

Yes, it's called "waiting".  You can wait for one event (counter, IO 
port changing polarity):

http://www.parallax.com/portals/0/help/P8X32A/QnaMobile/Advanced/Content/QnaTopics/QnaCogs.htm

About interrupts or not: I've written an interrupt controller for the 
b16, but never actually used it.  The thing I used was derived from the 
interrupt controller, but did only provide a generic wait functionality 
- you can wait for whatever set of events you like to, read out the 
event mask and decide what to do.  That's, because typical 
microcontroller programs don't have a "main task", they have several 
event-related tasks, which, in an interrupt based system, would all be 
interrupt handler code.  You don't want nested interrupts, so 
essentially, all these short programs would run with interrupts 
disabled.

The wait+dispatch in software functionality does the same thing with 
less amount of hardware.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#18895

(Please do not snip newsgroups by using "followup to", unless the post 
really is off-topic in a group.)


On 19/01/13 11:06, Paul E. Bennett wrote:
> Ben Bradley wrote:
>
>> U=In comp.lang.forth,comp.arch.embedded On Sun, 13 Jan 2013 13:55:22
>> GMT, Peter Jakacki <peterjakacki@gmail.com> wrote:
>
> [%X]
>
>>> The P2 which is due to be released soon
>>
>> ... still has zero interrupts.
>>
>> Yes, I first saw the propellor mentioned years ago, the 8 32-bit cores
>> thing sounds nice, but no interrupts was a deal killer for me. A year
>> or two back (with maybe earlier mention of the P2) I looked on the
>> "official" support/discussion forums for the Propellor and saw this
>> longish thread on "why doesn't it have interrupts" and there were
>> posts there that covered every objection I've had or seen to a
>> microcontroller not having interrupts, even  "why not add interrupts?
>> It would take very little silicon and you don't have to use 'em if you
>> don't want to." It's against that designer guru guy's religion or
>> something.
>>
>> As far as I know there's no other microcontroller that doesn't have
>> interrupts, and I can't recall one that didn't. The Apple ][ didn't
>> use interrupts even though the 6502 had them. Maybe there were some
>> 4-bit microprocessors that didn't have any interrupts.

Were there not small Microchip PIC devices without interrupts?  The 
PIC12 series, or something like that (I didn't use them myself).

>
> One question you should ask yourself is why you think a parallel processor
> (particularly the mesh organised ones) really need to include interrupts.
> You have many processors, all the same, simple, no frills. You can afford to
> dedicate a processor to deal with inputs that need to be responded to
> rapidly without the need for interrupts. I know that, to some, it might seem
> a waste of a processor, but with heavily parallel chips you could afford to
> think about how you allocate I/O around the processor array.
>

That argument might have merit /if/ this chip had many processors.  It 
only has 8.  I think the idea of splitting a design into multiple 
simple, semi-independent tasks that all work on their own 
cpu/core/thread, in their own little worlds, is very elegant.  It can 
give great modularisation, re-use of software-components, and easy 
testing.  But you need /many/ more than 8 threads for such a system with 
real-world programs - otherwise you have to combine tasks within the 
same thread, and you have lost all the elegance.

So then you might have a system with lots more cores - say 64 cores. 
Then you have enough to do quite a number of tasks.  But to get that 
with a realistic price, power and size, these cores will be very simple 
and slow - which means that you can't do tasks that require a single 
core running quickly.

What makes a lot more sense is to have a cpu that has hardware support 
for a RTOS, and is able to switch rapidly between different tasks.  That 
way demanding tasks can get the cpu time they need, while you can also 
have lots of very simple tasks that give you the modularisation in code 
without having to dedicate lots of silicon.  The XMOS does a bit of 
this, in that it has 8 threads per cpu that can run up to 100 MIPS each 
(IIRC), but with a total of 500 MIPS per cpu, and it also has 
inter-process communication in hardware.


> Check back in the history of processors and you will see why the interrupt
> was thought to be necessary in the first place. With the world heading to
> the much more use of multi-parallel processor I suspect the need for
> interrupts will wane.
>

Look how many interrupts a modern PC or large embedded system has - they 
outnumber the number of cores by 50 to 1 at least.  Interrupts are not 
going away.

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

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

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

csiph-web