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

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

Examples of current implementations in Forth for bachelor thesis

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

Contents

  Examples of current implementations in Forth for bachelor thesis Oliver Bach <decfreak@googlemail.com> - 2013-01-10 17:28 -0800
    Re: Examples of current implementations in Forth for bachelor thesis Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-10 19:52 -0800
    Re: Examples of current implementations in Forth for bachelor thesis "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-01-11 03:35 -0500
      Re: Examples of current implementations in Forth for bachelor thesis Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-14 15:13 -0800
        Re: Examples of current implementations in Forth for bachelor thesis "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-01-14 21:16 -0500
          Re: Examples of current implementations in Forth for bachelor thesis Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-15 14:47 -0800
            Re: Examples of current implementations in Forth for bachelor thesis rickman <gnuarm@gmail.com> - 2013-01-18 23:24 -0500
    Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-11 04:08 -0800
    Re: Examples of current implementations in Forth for bachelor thesis Spam@ControlQ.com - 2013-01-11 13:09 -0500
      Re: Examples of current implementations in Forth for bachelor thesis Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2013-01-12 11:59 +0100
    Re: Examples of current implementations in Forth for bachelor thesis "Elizabeth D. Rather" <erather@forth.com> - 2013-01-13 07:41 +1300
      Re: Examples of current implementations in Forth for bachelor thesis Chris <xrissmith@me.com> - 2013-01-12 21:05 -0800
        Re: Examples of current implementations in Forth for bachelor thesis "Elizabeth D. Rather" <erather@forth.com> - 2013-01-13 22:26 +1300
    Re: Examples of current implementations in Forth for bachelor thesis gavino_himself <visploveslisp@gmail.com> - 2013-01-13 18:41 -0800
    Re: Examples of current implementations in Forth for bachelor thesis Paul Rubin <no.email@nospam.invalid> - 2013-01-17 23:42 -0800
      Re: Examples of current implementations in Forth for bachelor thesis Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-19 18:21 -0800
        Re: Examples of current implementations in Forth for bachelor thesis Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-20 14:26 +0100
          Re: Examples of current implementations in Forth for bachelor thesis Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-20 10:58 -0600
          Re: Examples of current implementations in Forth for bachelor thesis Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-20 15:46 -0800
            Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-21 01:51 -0800
              Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-21 04:10 -0800
                Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-21 04:45 -0800
                  Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-21 04:48 -0800
                  Re: Examples of current implementations in Forth for bachelor thesis Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-21 22:01 +0100
                    Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-21 13:42 -0800
                      Re: Examples of current implementations in Forth for bachelor thesis Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-22 02:18 +0100
                        Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-22 01:06 -0800
                    Re: Examples of current implementations in Forth for bachelor thesis Lauri Alanko <la@iki.fi> - 2013-02-01 04:54 +0000
                      Re: Examples of current implementations in Forth for bachelor thesis "Elizabeth D. Rather" <erather@forth.com> - 2013-01-31 19:34 -1000
                      Re: Examples of current implementations in Forth for bachelor thesis Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-02 16:32 +0100
                        Re: Examples of current implementations in Forth for bachelor thesis stephenXXX@mpeforth.com (Stephen Pelc) - 2013-02-02 18:17 +0000
                      Re: Examples of current implementations in Forth for bachelor thesis albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-02 17:51 +0000
              Re: Examples of current implementations in Forth for bachelor thesis albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-01-21 14:55 +0000
            Re: Examples of current implementations in Forth for bachelor thesis "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-01-22 03:18 -0500
              Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-22 01:10 -0800
                Re: Examples of current implementations in Forth for bachelor thesis Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-22 03:31 -0600
                  Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-22 03:41 -0800
                  Re: Examples of current implementations in Forth for bachelor thesis "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-01-22 14:36 -0500
                    Re: Examples of current implementations in Forth for bachelor thesis Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-22 17:23 -0600
                    Re: Examples of current implementations in Forth for bachelor thesis rickman <gnuarm@gmail.com> - 2013-01-25 09:38 -0500
                Re: Examples of current implementations in Forth for bachelor thesis "A. K." <akk@nospam.org> - 2013-01-22 12:52 +0100
                  Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-22 04:31 -0800
                    Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-22 04:35 -0800
                      Re: Examples of current implementations in Forth for bachelor thesis "A. K." <akk@nospam.org> - 2013-01-22 18:22 +0100
                        Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-22 09:40 -0800
                          Re: Examples of current implementations in Forth for bachelor thesis "A. K." <akk@nospam.org> - 2013-01-22 21:02 +0100
                            Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-22 13:30 -0800
                              Re: Examples of current implementations in Forth for bachelor thesis "A. K." <akk@nospam.org> - 2013-01-22 23:07 +0100
                                Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-22 15:16 -0800
                        Re: Examples of current implementations in Forth for bachelor thesis rickman <gnuarm@gmail.com> - 2013-01-23 13:07 -0500
                          Re: Examples of current implementations in Forth for bachelor thesis "A. K." <akk@nospam.org> - 2013-01-25 08:33 +0100
                            Re: Examples of current implementations in Forth for bachelor thesis rickman <gnuarm@gmail.com> - 2013-01-25 16:46 -0500
                              Re: Examples of current implementations in Forth for bachelor thesis "A. K." <akk@nospam.org> - 2013-01-25 23:31 +0100
                                Re: Examples of current implementations in Forth for bachelor thesis rickman <gnuarm@gmail.com> - 2013-01-26 18:09 -0500
                                  Re: Examples of current implementations in Forth for bachelor thesis "A. K." <akk@nospam.org> - 2013-01-27 10:15 +0100
                                    Re: Examples of current implementations in Forth for bachelor thesis rickman <gnuarm@gmail.com> - 2013-01-31 14:41 -0500
                                      Re: Examples of current implementations in Forth for bachelor thesis "A. K." <akk@nospam.org> - 2013-01-31 21:03 +0100
                                        Re: Examples of current implementations in Forth for bachelor thesis mhx@iae.nl (Marcel Hendrix) - 2013-01-31 21:44 +0200
                                          Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-31 23:16 -0800
                                        Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-31 12:47 -0800
                                          Re: Examples of current implementations in Forth for bachelor thesis "A. K." <akk@nospam.org> - 2013-02-01 08:23 +0100
                    Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-22 04:48 -0800
                      Re: Examples of current implementations in Forth for bachelor thesis Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-22 17:30 +0100
                  Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-22 04:32 -0800
                Re: Examples of current implementations in Forth for bachelor thesis "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-01-22 14:35 -0500
                  Re: Examples of current implementations in Forth for bachelor thesis Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-22 17:29 -0600
                  Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-23 02:21 -0800
                    Re: Examples of current implementations in Forth for bachelor thesis Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-23 04:43 -0600
                      Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-23 03:28 -0800
                        Re: Examples of current implementations in Forth for bachelor thesis Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-23 09:19 -0600
                          Re: Examples of current implementations in Forth for bachelor thesis Paul Rubin <no.email@nospam.invalid> - 2013-01-23 09:24 -0800
                            Re: Examples of current implementations in Forth for bachelor thesis Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-23 12:01 -0600
                          Re: Examples of current implementations in Forth for bachelor thesis David Thompson <dave.thompson2@verizon.net> - 2013-02-04 03:09 -0500
                    Re: Examples of current implementations in Forth for bachelor thesis rickman <gnuarm@gmail.com> - 2013-01-25 09:59 -0500
                      Re: Examples of current implementations in Forth for bachelor thesis Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-26 03:05 -0600
                        Re: Examples of current implementations in Forth for bachelor thesis Alex McDonald <blog@rivadpm.com> - 2013-01-26 04:38 -0800
                          Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <markrobertwills@yahoo.co.uk> - 2013-01-26 07:19 -0800
                          Re: Examples of current implementations in Forth for bachelor thesis Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-26 13:13 -0600
                            Re: Examples of current implementations in Forth for bachelor thesis rickman <gnuarm@gmail.com> - 2013-01-26 17:00 -0500
                            Re: Examples of current implementations in Forth for bachelor thesis None <vandys@vsta.org> - 2013-01-26 22:04 +0000
              Re: Examples of current implementations in Forth for bachelor thesis kenney@cix.compulink.co.uk - 2013-01-22 18:20 -0600
                Re: Examples of current implementations in Forth for bachelor thesis Mark Wills <forthfreak@gmail.com> - 2013-01-22 23:25 -0800
                Re: Examples of current implementations in Forth for bachelor thesis Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-23 03:02 -0600
              Re: Examples of current implementations in Forth for bachelor thesis Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-24 18:28 -0800
                Re: Examples of current implementations in Forth for bachelor thesis Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-25 16:57 +0100
                  Re: Examples of current implementations in Forth for bachelor thesis Paul Rubin <no.email@nospam.invalid> - 2013-01-25 08:41 -0800
                    Re: Examples of current implementations in Forth for bachelor thesis Coos Haak <chforth@hccnet.nl> - 2013-01-25 20:04 +0100
                      Re: Examples of current implementations in Forth for bachelor thesis "Elizabeth D. Rather" <erather@forth.com> - 2013-01-26 09:25 +1300
                      Re: Examples of current implementations in Forth for bachelor thesis Paul Rubin <no.email@nospam.invalid> - 2013-01-26 13:16 -0800
                  Re: Examples of current implementations in Forth for bachelor thesis Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-30 18:40 -0800
                    Re: Examples of current implementations in Forth for bachelor thesis Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-31 15:15 +0100
                      Re: Examples of current implementations in Forth for bachelor thesis anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-31 15:55 +0000
                        Re: Examples of current implementations in Forth for bachelor thesis mhx@iae.nl (Marcel Hendrix) - 2013-02-24 00:57 +0200
                      Re: Examples of current implementations in Forth for bachelor thesis Brad Eckert <hwfwguy@gmail.com> - 2013-01-31 09:01 -0800
                        Re: Examples of current implementations in Forth for bachelor thesis Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-31 19:41 +0100
                          Re: Examples of current implementations in Forth for bachelor thesis anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-01 16:08 +0000
                            Re: Examples of current implementations in Forth for bachelor thesis albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-02 02:16 +0000
                              Re: Examples of current implementations in Forth for bachelor thesis Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-02 16:38 +0100
                              Re: Examples of current implementations in Forth for bachelor thesis anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-04 14:50 +0000
                      Re: Examples of current implementations in Forth for bachelor thesis Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-06 00:32 -0800
                        Re: Examples of current implementations in Forth for bachelor thesis Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-06 19:39 +0100

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

#18996

On 22.01.2013 10:10, Mark Wills wrote:
> What if performance is not the main metric? What if application
> security (in terms of not crashing) is the main goal? You seem to have
> an obsession with performance. Where I work, "must not fail" is tens
> of millions of dollars more important than "must be fast". We couldn't
> give a shit about its performance, quite frankly.

This is the best statement I've read in c.l.f. since long.

Nearly all control systems today are graphically "programmed" by 
connecting software blocks in CAE systems. Unparamaterized/unconnected 
I/Os are detected immediately (so there is nothing like stack mismatch 
as in Forth development). Only thoroughly tested blocks with inherent 
self-monitoring and error-detection are provided in libraries. Many DCS 
even go as far as not providing a user programming language at all, you 
have to build macros from those blocks.

Benefit: Code runtime is slow but safe. And during engineering you don't 
waste time with software debugging, you can visually concentrate on your 
algorithms.

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

#18997

On Jan 22, 11:52 am, "A. K." <a...@nospam.org> wrote:
> On 22.01.2013 10:10, Mark Wills wrote:
>
> > What if performance is not the main metric? What if application
> > security (in terms of not crashing) is the main goal? You seem to have
> > an obsession with performance. Where I work, "must not fail" is tens
> > of millions of dollars more important than "must be fast". We couldn't
> > give a shit about its performance, quite frankly.
>
> This is the best statement I've read in c.l.f. since long.
>
> Nearly all control systems today are graphically "programmed" by
> connecting software blocks in CAE systems. Unparamaterized/unconnected
> I/Os are detected immediately (so there is nothing like stack mismatch
> as in Forth development). Only thoroughly tested blocks with inherent
> self-monitoring and error-detection are provided in libraries. Many DCS
> even go as far as not providing a user programming language at all, you
> have to build macros from those blocks.
>
> Benefit: Code runtime is slow but safe. And during engineering you don't
> waste time with software debugging, you can visually concentrate on your
> algorithms.

Fully agree. And in most (if not all) cases, the code that is
developed, be it ladder logic, sequential function charts, and the
like all run inside a VM. That way, if the worst *should* happen and
the VM falls over, your *server* _does not_ fall over, it can detect
the VM crash and re-start it. Allen Bradley PLCs run a number of VMs
on a single PLC - one for each task. If a task/program crashes (I've
*never* seen it happen in over 20 years of experience) the rest of the
system stays up, no problem at all.

If you study IEC 61131 part 3 you'll find the definition for a virtual
assembly languge called IL (Instruction List) which is used in control
systems - SCADA systems, DCS, ICSS and the like. IL runs in a virtual
machine. Ladder logic, FBDs etc all compile down to IL.

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

#18999

On Jan 22, 12:31 pm, Mark Wills <forthfr...@gmail.com> wrote:
> On Jan 22, 11:52 am, "A. K." <a...@nospam.org> wrote:
>
>
>
>
>
> > On 22.01.2013 10:10, Mark Wills wrote:
>
> > > What if performance is not the main metric? What if application
> > > security (in terms of not crashing) is the main goal? You seem to have
> > > an obsession with performance. Where I work, "must not fail" is tens
> > > of millions of dollars more important than "must be fast". We couldn't
> > > give a shit about its performance, quite frankly.
>
> > This is the best statement I've read in c.l.f. since long.
>
> > Nearly all control systems today are graphically "programmed" by
> > connecting software blocks in CAE systems. Unparamaterized/unconnected
> > I/Os are detected immediately (so there is nothing like stack mismatch
> > as in Forth development). Only thoroughly tested blocks with inherent
> > self-monitoring and error-detection are provided in libraries. Many DCS
> > even go as far as not providing a user programming language at all, you
> > have to build macros from those blocks.
>
> > Benefit: Code runtime is slow but safe. And during engineering you don't
> > waste time with software debugging, you can visually concentrate on your
> > algorithms.
>
> Fully agree. And in most (if not all) cases, the code that is
> developed, be it ladder logic, sequential function charts, and the
> like all run inside a VM. That way, if the worst *should* happen and
> the VM falls over, your *server* _does not_ fall over, it can detect
> the VM crash and re-start it. Allen Bradley PLCs run a number of VMs
> on a single PLC - one for each task. If a task/program crashes (I've
> *never* seen it happen in over 20 years of experience) the rest of the
> system stays up, no problem at all.
>
> If you study IEC 61131 part 3 you'll find the definition for a virtual
> assembly languge called IL (Instruction List) which is used in control
> systems - SCADA systems, DCS, ICSS and the like. IL runs in a virtual
> machine. Ladder logic, FBDs etc all compile down to IL.- Hide quoted text -
>
> - Show quoted text -

Note also that IL is stack based :-)

http://en.wikipedia.org/wiki/Instruction_list

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

#19005

On 22.01.2013 13:35, Mark Wills wrote:

> Note also that IL is stack based :-)
>
> http://en.wikipedia.org/wiki/Instruction_list
>

True, and note also that one of the most important operators in IL is 
the closing bracket ) that does not exist in Forth.  ;-)

I.e. your have OR like in Forth and OR( .. ) where the .. represents 
another internal calculation block/path, i.e. OR( is a delayed OR until 
it is resolved by ). I always wondered why this idea never found its way 
into Forth, it's so simple...

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

#19006

On Jan 22, 5:22 pm, "A. K." <a...@nospam.org> wrote:
> On 22.01.2013 13:35, Mark Wills wrote:
>
> > Note also that IL is stack based :-)
>
> >http://en.wikipedia.org/wiki/Instruction_list
>
> True, and note also that one of the most important operators in IL is
> the closing bracket ) that does not exist in Forth.  ;-)
>
> I.e. your have OR like in Forth and OR( .. ) where the .. represents
> another internal calculation block/path, i.e. OR( is a delayed OR until
> it is resolved by ). I always wondered why this idea never found its way
> into Forth, it's so simple...

Because OR( A B ) is expressed as A B OR in Forth, much as PLUS( A B )
would be A B +. Forth doesn't have operator precedence. Or am I
missing something?

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

#19014

On 22.01.2013 18:40, Alex McDonald wrote:
> On Jan 22, 5:22 pm, "A. K." <a...@nospam.org> wrote:
>> On 22.01.2013 13:35, Mark Wills wrote:
>>
>>> Note also that IL is stack based :-)
>>
>>> http://en.wikipedia.org/wiki/Instruction_list
>>
>> True, and note also that one of the most important operators in IL is
>> the closing bracket ) that does not exist in Forth.  ;-)
>>
>> I.e. your have OR like in Forth and OR( .. ) where the .. represents
>> another internal calculation block/path, i.e. OR( is a delayed OR until
>> it is resolved by ). I always wondered why this idea never found its way
>> into Forth, it's so simple...
>
> Because OR( A B ) is expressed as A B OR in Forth, much as PLUS( A B )
> would be A B +. Forth doesn't have operator precedence. Or am I
> missing something?
>

In traditional Forth it could require a third stack, say called T.
OR( then is a bit like
: OR(  ['] OR >T >T ;
: )    T> T> EXECUTE ;

Well, not exactly, compile-time and run-time stack depth check is 
missing, then you may have bits instead of words....

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

#19015

On Jan 22, 8:02 pm, "A. K." <a...@nospam.org> wrote:
> On 22.01.2013 18:40, Alex McDonald wrote:
>
>
>
>
>
>
>
>
>
> > On Jan 22, 5:22 pm, "A. K." <a...@nospam.org> wrote:
> >> On 22.01.2013 13:35, Mark Wills wrote:
>
> >>> Note also that IL is stack based :-)
>
> >>>http://en.wikipedia.org/wiki/Instruction_list
>
> >> True, and note also that one of the most important operators in IL is
> >> the closing bracket ) that does not exist in Forth.  ;-)
>
> >> I.e. your have OR like in Forth and OR( .. ) where the .. represents
> >> another internal calculation block/path, i.e. OR( is a delayed OR until
> >> it is resolved by ). I always wondered why this idea never found its way
> >> into Forth, it's so simple...
>
> > Because OR( A B ) is expressed as A B OR in Forth, much as PLUS( A B )
> > would be A B +. Forth doesn't have operator precedence. Or am I
> > missing something?
>
> In traditional Forth it could require a third stack, say called T.
> OR( then is a bit like
> : OR(  ['] OR >T >T ;
> : )    T> T> EXECUTE ;
>
> Well, not exactly, compile-time and run-time stack depth check is
> missing, then you may have bits instead of words....

STC Experimental 32bit: 0.06.06 Build: 203
: or( ['] or >r ; inline  ok
: ) r> execute ; inline  ok
: testit or( 1 2 ) ;  ok
testit . 3  ok

But why would you want to do this?

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

#19016

On 22.01.2013 22:30, Alex McDonald wrote:
> On Jan 22, 8:02 pm, "A. K." <a...@nospam.org> wrote:
>> On 22.01.2013 18:40, Alex McDonald wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> On Jan 22, 5:22 pm, "A. K." <a...@nospam.org> wrote:
>>>> On 22.01.2013 13:35, Mark Wills wrote:
>>
>>>>> Note also that IL is stack based :-)
>>
>>>>> http://en.wikipedia.org/wiki/Instruction_list
>>
>>>> True, and note also that one of the most important operators in IL is
>>>> the closing bracket ) that does not exist in Forth.  ;-)
>>
>>>> I.e. your have OR like in Forth and OR( .. ) where the .. represents
>>>> another internal calculation block/path, i.e. OR( is a delayed OR until
>>>> it is resolved by ). I always wondered why this idea never found its way
>>>> into Forth, it's so simple...
>>
>>> Because OR( A B ) is expressed as A B OR in Forth, much as PLUS( A B )
>>> would be A B +. Forth doesn't have operator precedence. Or am I
>>> missing something?
>>
>> In traditional Forth it could require a third stack, say called T.
>> OR( then is a bit like
>> : OR(  ['] OR >T >T ;
>> : )    T> T> EXECUTE ;
>>
>> Well, not exactly, compile-time and run-time stack depth check is
>> missing, then you may have bits instead of words....
>
> STC Experimental 32bit: 0.06.06 Build: 203
> : or( ['] or >r ; inline  ok
> : ) r> execute ; inline  ok
> : testit or( 1 2 ) ;  ok
> testit . 3  ok
>
> But why would you want to do this?
>

Volatility of data, parallel execution within different time slots, or 
between different CPUs in an heavily parallel system. It is not Forth 
after all, so it's a poor man's method to process things in an atomic 
way.  ;-)

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

#19024

On Jan 22, 10:07 pm, "A. K." <a...@nospam.org> wrote:
> On 22.01.2013 22:30, Alex McDonald wrote:
>
>
>
>
>
>
>
>
>
> > On Jan 22, 8:02 pm, "A. K." <a...@nospam.org> wrote:
> >> On 22.01.2013 18:40, Alex McDonald wrote:
>
> >>> On Jan 22, 5:22 pm, "A. K." <a...@nospam.org> wrote:
> >>>> On 22.01.2013 13:35, Mark Wills wrote:
>
> >>>>> Note also that IL is stack based :-)
>
> >>>>>http://en.wikipedia.org/wiki/Instruction_list
>
> >>>> True, and note also that one of the most important operators in IL is
> >>>> the closing bracket ) that does not exist in Forth.  ;-)
>
> >>>> I.e. your have OR like in Forth and OR( .. ) where the .. represents
> >>>> another internal calculation block/path, i.e. OR( is a delayed OR until
> >>>> it is resolved by ). I always wondered why this idea never found its way
> >>>> into Forth, it's so simple...
>
> >>> Because OR( A B ) is expressed as A B OR in Forth, much as PLUS( A B )
> >>> would be A B +. Forth doesn't have operator precedence. Or am I
> >>> missing something?
>
> >> In traditional Forth it could require a third stack, say called T.
> >> OR( then is a bit like
> >> : OR(  ['] OR >T >T ;
> >> : )    T> T> EXECUTE ;
>
> >> Well, not exactly, compile-time and run-time stack depth check is
> >> missing, then you may have bits instead of words....
>
> > STC Experimental 32bit: 0.06.06 Build: 203
> > : or( ['] or >r ; inline  ok
> > : ) r> execute ; inline  ok
> > : testit or( 1 2 ) ;  ok
> > testit . 3  ok
>
> > But why would you want to do this?
>
> Volatility of data, parallel execution within different time slots, or
> between different CPUs in an heavily parallel system. It is not Forth
> after all, so it's a poor man's method to process things in an atomic
> way.  ;-)

If OR( is a scheduling word, and ) waits in which case

: schedule ( xt cpu -- c ) ( schedule xt on cpu, generate completion
token )
    ... ;
: wait ( c -- n ) ( wait on completion token, return result )
    ... ;
: or() ( xt1 xt2 -- n )
    CPU-A schedule swap CPU-B schedule
    wait swap wait or ;

' A ' B OR()

That can be done in some Forths; Win32Forth for example supports tasks
with private stacks, and lightweight thread/fiber support is available
through the OS. I don't know what you mean by volatility.

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

#19102

On 1/22/2013 12:22 PM, A. K. wrote:
> On 22.01.2013 13:35, Mark Wills wrote:
>
>> Note also that IL is stack based :-)
>>
>> http://en.wikipedia.org/wiki/Instruction_list
>>
>
> True, and note also that one of the most important operators in IL is
> the closing bracket ) that does not exist in Forth. ;-)
>
> I.e. your have OR like in Forth and OR( .. ) where the .. represents
> another internal calculation block/path, i.e. OR( is a delayed OR until
> it is resolved by ). I always wondered why this idea never found its way
> into Forth, it's so simple...

What would be the point?

Rick

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

#19122

On 23.01.2013 19:07, rickman wrote:
> On 1/22/2013 12:22 PM, A. K. wrote:
>> On 22.01.2013 13:35, Mark Wills wrote:
>>
>>> Note also that IL is stack based :-)
>>>
>>> http://en.wikipedia.org/wiki/Instruction_list
>>>
>>
>> True, and note also that one of the most important operators in IL is
>> the closing bracket ) that does not exist in Forth. ;-)
>>
>> I.e. your have OR like in Forth and OR( .. ) where the .. represents
>> another internal calculation block/path, i.e. OR( is a delayed OR until
>> it is resolved by ). I always wondered why this idea never found its way
>> into Forth, it's so simple...
>
> What would be the point?
>
> Rick

When you do a lot of logic calculations, they tend to be nested very 
often to several levels. With modified operators { modified by the 
trailing opening bracket ( } you can save a bunch of OVERs and PICKs 
etc, making for more readable code. As I said, it's not a big deal, but 
it translates also easier to contact or ladder diagrams used by control 
engineers.

I remember also an extended version, that went:
OR( <calc1> | <calc2> )
where the modifier ( saved the stack, | reinstated it for <calc2> on top 
of the result of <calc1>, and ) resolved the delayed operator OR. Of 
course it was slow. But with today's optimizing compilers?

"When I was young.." sang Eric Burdon...  ;-))

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

#19155

On 1/25/2013 2:33 AM, A. K. wrote:
> On 23.01.2013 19:07, rickman wrote:
>> On 1/22/2013 12:22 PM, A. K. wrote:
>>> On 22.01.2013 13:35, Mark Wills wrote:
>>>
>>>> Note also that IL is stack based :-)
>>>>
>>>> http://en.wikipedia.org/wiki/Instruction_list
>>>>
>>>
>>> True, and note also that one of the most important operators in IL is
>>> the closing bracket ) that does not exist in Forth. ;-)
>>>
>>> I.e. your have OR like in Forth and OR( .. ) where the .. represents
>>> another internal calculation block/path, i.e. OR( is a delayed OR until
>>> it is resolved by ). I always wondered why this idea never found its way
>>> into Forth, it's so simple...
>>
>> What would be the point?
>>
>> Rick
>
> When you do a lot of logic calculations, they tend to be nested very
> often to several levels. With modified operators { modified by the
> trailing opening bracket ( } you can save a bunch of OVERs and PICKs
> etc, making for more readable code.

I am missing something.  I don't see how the use of prefix operators 
change anything with stack operators.  Your idea is just an issue of 
syntax and all the same calculations and stack operations have to be done.
OR( Acalc Bcalc ) is no different from Acalc Bcalc OR in existing Forth.

Or am I missing something else?


> As I said, it's not a big deal, but
> it translates also easier to contact or ladder diagrams used by control
> engineers.
>
> I remember also an extended version, that went:
> OR( <calc1> | <calc2> )
> where the modifier ( saved the stack, | reinstated it for <calc2> on top
> of the result of <calc1>, and ) resolved the delayed operator OR. Of
> course it was slow. But with today's optimizing compilers?

Saved how much of the stack?  Wouldn't that be important for the word to 
know?

Rick

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

#19157

On 25.01.2013 22:46, rickman wrote:
> On 1/25/2013 2:33 AM, A. K. wrote:
>> On 23.01.2013 19:07, rickman wrote:
>>> On 1/22/2013 12:22 PM, A. K. wrote:
>>>> On 22.01.2013 13:35, Mark Wills wrote:
>>>>
>>>>> Note also that IL is stack based :-)
>>>>>
>>>>> http://en.wikipedia.org/wiki/Instruction_list
>>>>>
>>>>
>>>> True, and note also that one of the most important operators in IL is
>>>> the closing bracket ) that does not exist in Forth. ;-)
>>>>
>>>> I.e. your have OR like in Forth and OR( .. ) where the .. represents
>>>> another internal calculation block/path, i.e. OR( is a delayed OR until
>>>> it is resolved by ). I always wondered why this idea never found its
>>>> way
>>>> into Forth, it's so simple...
>>>
>>> What would be the point?
>>>
>>> Rick
>>
>> When you do a lot of logic calculations, they tend to be nested very
>> often to several levels. With modified operators { modified by the
>> trailing opening bracket ( } you can save a bunch of OVERs and PICKs
>> etc, making for more readable code.
>
> I am missing something.  I don't see how the use of prefix operators
> change anything with stack operators.  Your idea is just an issue of
> syntax and all the same calculations and stack operations have to be done.
> OR( Acalc Bcalc ) is no different from Acalc Bcalc OR in existing Forth.
>
> Or am I missing something else?
>
>
>> As I said, it's not a big deal, but
>> it translates also easier to contact or ladder diagrams used by control
>> engineers.
>>
>> I remember also an extended version, that went:
>> OR( <calc1> | <calc2> )
>> where the modifier ( saved the stack, | reinstated it for <calc2> on top
>> of the result of <calc1>, and ) resolved the delayed operator OR. Of
>> course it was slow. But with today's optimizing compilers?
>
> Saved how much of the stack?  Wouldn't that be important for the word to
> know?
>
> Rick

As already stated, this is not Forth, but a low-lecel postfix DSL for 
controller programming. However it is close enough to Forth to be 
implemented easily in Forth.

That said, the use of ( as operator modifier can
a) make the source code more readable for humans
b) make the automatic code generation from ladder diagrams etc to 
program code more straightforward
c) allow for easy stack depth check during compile-time
d) compile a task switch lock (for atomic calculations) or task slice 
timeout monitoring along with the calculation
e) allow for computing parallel input chains in parallel execution 
threads eg on different CPU cores.

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

#19182

On 1/25/2013 5:31 PM, A. K. wrote:
> On 25.01.2013 22:46, rickman wrote:
>> On 1/25/2013 2:33 AM, A. K. wrote:
>>> On 23.01.2013 19:07, rickman wrote:
>>>> On 1/22/2013 12:22 PM, A. K. wrote:
>>>>> On 22.01.2013 13:35, Mark Wills wrote:
>>>>>
>>>>>> Note also that IL is stack based :-)
>>>>>>
>>>>>> http://en.wikipedia.org/wiki/Instruction_list
>>>>>>
>>>>>
>>>>> True, and note also that one of the most important operators in IL is
>>>>> the closing bracket ) that does not exist in Forth. ;-)
>>>>>
>>>>> I.e. your have OR like in Forth and OR( .. ) where the .. represents
>>>>> another internal calculation block/path, i.e. OR( is a delayed OR
>>>>> until
>>>>> it is resolved by ). I always wondered why this idea never found its
>>>>> way
>>>>> into Forth, it's so simple...
>>>>
>>>> What would be the point?
>>>>
>>>> Rick
>>>
>>> When you do a lot of logic calculations, they tend to be nested very
>>> often to several levels. With modified operators { modified by the
>>> trailing opening bracket ( } you can save a bunch of OVERs and PICKs
>>> etc, making for more readable code.
>>
>> I am missing something. I don't see how the use of prefix operators
>> change anything with stack operators. Your idea is just an issue of
>> syntax and all the same calculations and stack operations have to be
>> done.
>> OR( Acalc Bcalc ) is no different from Acalc Bcalc OR in existing Forth.
>>
>> Or am I missing something else?
>>
>>
>>> As I said, it's not a big deal, but
>>> it translates also easier to contact or ladder diagrams used by control
>>> engineers.
>>>
>>> I remember also an extended version, that went:
>>> OR( <calc1> | <calc2> )
>>> where the modifier ( saved the stack, | reinstated it for <calc2> on top
>>> of the result of <calc1>, and ) resolved the delayed operator OR. Of
>>> course it was slow. But with today's optimizing compilers?
>>
>> Saved how much of the stack? Wouldn't that be important for the word to
>> know?
>>
>> Rick
>
> As already stated, this is not Forth, but a low-lecel postfix DSL for
> controller programming. However it is close enough to Forth to be
> implemented easily in Forth.

Not sure why you say that now.  Read your post from above...

> True, and note also that one of the most important operators in IL is
> the closing bracket ) that does not exist in *Forth*.
>
> I.e. your have OR like in Forth and OR( .. ) where the .. represents
> another internal calculation block/path, i.e. OR( is a delayed OR until
> it is resolved by ). I always wondered why this idea never found its
> way
> into *Forth*, it's so simple...

emphasis added.  BTW, what is a DSL?


> That said, the use of ( as operator modifier can
> a) make the source code more readable for humans

I don't want to be argumentative, but "readable" is subjective.  More 
importantly none of this stuff is ever readable when it is complex.  I 
have coded in Forth, C, Pascal, Occam, Lisp, VHDL, Verilog and assembly. 
  I have never seen a complex logic expression that was clear in any of 
these languages.


> b) make the automatic code generation from ladder diagrams etc to
> program code more straightforward

I have no background in formal code generation, but I don't think this 
is really an issue.  I think conversion between infix, postfix and 
prefix is a very simple process to automate.  In fact, your description 
of how your new word would work is essentially a mapping of prefix 
notation to postfix execution.


> c) allow for easy stack depth check during compile-time

Really?  Easier than postfix?  I don't think it gets any easier than 
postfix and prefix requires stacking of the operator!


> d) compile a task switch lock (for atomic calculations) or task slice
> timeout monitoring along with the calculation

I don't follow how this falls out of prefix notation at all.


> e) allow for computing parallel input chains in parallel execution
> threads eg on different CPU cores.

How does that work differently in postfix?

Rick

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

#19188

On 27.01.2013 00:09, rickman wrote:
> <snipped a lot>
> How does that work differently in postfix?
>
> Rick

(DSL = domain specific language)

You are mentally stuck in a wrong path. It is still a postfix system. 
Some delayed operators do not make a system prefix. There is no operator 
precedence tree or shunting yard algorithm working. Brackets ( alone 
still start comments.

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

#19326

On 1/27/2013 4:15 AM, A. K. wrote:
> On 27.01.2013 00:09, rickman wrote:
>> <snipped a lot>
>> On some other day, A. K. wrote:
>>> e) allow for computing parallel input chains in parallel execution
>>> threads eg on different CPU cores.
>>
>> How does that work differently in postfix?
>>
>> Rick
>
> (DSL = domain specific language)
>
> You are mentally stuck in a wrong path. It is still a postfix system.
> Some delayed operators do not make a system prefix. There is no operator
> precedence tree or shunting yard algorithm working. Brackets ( alone
> still start comments.

Your reply is a non-sequitur.  You say your "DSL" lets you perform 
parallel execution.  So how is that different from Forth?  Or maybe I 
don't understand what you are comparing your DSL to?

-- 

Rick

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

#19328

On 31.01.2013 20:41, rickman wrote:
> Your reply is a non-sequitur.  You say your "DSL" lets you perform
> parallel execution.  So how is that different from Forth?  Or maybe I
> don't understand what you are comparing your DSL to?
>

To put it simply:

OPERATOR( <commands1> | <commands2> | <commands3> )

will be compiled to executing the three Forth-like command sequences in 
parallel threads or CPU cores. Their outputs will be stacked. When the 
last command sequence has finished, parallelism ends, and OPERATOR is 
executed on the stack. It is a rather primitive scheme, but the compiler 
has to know the arity of operators of course.

AFAIK Forth has no commands for controlling parallel execution at all.

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

#19331

"A. K." <akk@nospam.org> writes Re: Examples of current implementations in Forth for bachelor thesis

[..]
> To put it simply:

> OPERATOR( <commands1> | <commands2> | <commands3> )

> will be compiled to executing the three Forth-like command sequences in 
> parallel threads or CPU cores. Their outputs will be stacked. When the 
> last command sequence has finished, parallelism ends, and OPERATOR is 
> executed on the stack. It is a rather primitive scheme, but the compiler 
> has to know the arity of operators of course.

> AFAIK Forth has no commands for controlling parallel execution at all.

iForth (and tForth) have them, since about 1998.

#100000000 VALUE #runs
0 VALUE sum1
#1024 ALLOT ( you figure it out :-)
0 VALUE sum2

: PERF ( -- )
	PAR
	 STARTP  #runs 0 ?DO  1 +TO sum1  LOOP   ENDP
	 STARTP	 #runs 0 ?DO  2 +TO sum2  LOOP   ENDP
	ENDPAR
	sum1 sum2 + ." sum = " . ;

The two STARTP's run on different cores. And yes, PERF runs twice as fast
as the same computation on a single core.

-marcel

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

#19342

On Jan 31, 7:44 pm, m...@iae.nl (Marcel Hendrix) wrote:
> "A. K." <a...@nospam.org> writes Re: Examples of current implementations in Forth for bachelor thesis
>
> [..]
>
> > To put it simply:
> > OPERATOR( <commands1> | <commands2> | <commands3> )
> > will be compiled to executing the three Forth-like command sequences in
> > parallel threads or CPU cores. Their outputs will be stacked. When the
> > last command sequence has finished, parallelism ends, and OPERATOR is
> > executed on the stack. It is a rather primitive scheme, but the compiler
> > has to know the arity of operators of course.
> > AFAIK Forth has no commands for controlling parallel execution at all.
>
> iForth (and tForth) have them, since about 1998.
>
> #100000000 VALUE #runs
> 0 VALUE sum1
> #1024 ALLOT ( you figure it out :-)
> 0 VALUE sum2
>
> : PERF ( -- )
>         PAR
>          STARTP  #runs 0 ?DO  1 +TO sum1  LOOP   ENDP
>          STARTP  #runs 0 ?DO  2 +TO sum2  LOOP   ENDP
>         ENDPAR
>         sum1 sum2 + ." sum = " . ;
>
> The two STARTP's run on different cores. And yes, PERF runs twice as fast
> as the same computation on a single core.
>
> -marcel

So is ENDPAR a blocking call that waits for both processes to
terminate?

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

#19332

On Jan 31, 8:03 pm, "A. K." <a...@nospam.org> wrote:
> On 31.01.2013 20:41, rickman wrote:
>
> > Your reply is a non-sequitur.  You say your "DSL" lets you perform
> > parallel execution.  So how is that different from Forth?  Or maybe I
> > don't understand what you are comparing your DSL to?
>
> To put it simply:
>
> OPERATOR( <commands1> | <commands2> | <commands3> )
>
> will be compiled to executing the three Forth-like command sequences in
> parallel threads or CPU cores. Their outputs will be stacked. When the
> last command sequence has finished, parallelism ends, and OPERATOR is
> executed on the stack. It is a rather primitive scheme, but the compiler
> has to know the arity of operators of course.
>
> AFAIK Forth has no commands for controlling parallel execution at all.

PARALLEL FORTH: The new approach

Michael Montvelishsky, Saransk Russia

http://www.ultratechnology.com/4thpar.html

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

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

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

csiph-web