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

I beleive that forth could supplant ruby and perl and python if it wanted to

Started by	quiet_lad <gavcomedy@gmail.com>
First post	2012-05-15 23:27 -0700
Last post	2012-05-18 22:58 -0700
Articles	20 on this page of 158 — 33 participants

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

  I beleive that forth could supplant ruby and perl and python if it wanted to quiet_lad <gavcomedy@gmail.com> - 2012-05-15 23:27 -0700
    Re: I beleive that forth could supplant ruby and perl and python if it wanted to marko <marko@marko.marko> - 2012-05-16 17:50 +1000
    Re: I beleive that forth could supplant ruby and perl and python if it wanted to "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-16 06:51 -0400
    Re: I beleive that forth could supplant ruby and perl and python if it wanted to BruceMcF <agila61@netscape.net> - 2012-05-16 07:59 -0700
      Re: I beleive that forth could supplant ruby and perl and python if it wanted to Jason Damisch <jasondamisch@yahoo.com> - 2012-05-16 09:28 -0700
        Re: I beleive that forth could supplant ruby and perl and python if it wanted to "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-17 04:08 -0400
          Re: I beleive that forth could supplant ruby and perl and python if it wanted to "Elizabeth D. Rather" <erather@forth.com> - 2012-05-16 22:22 -1000
            Re: I beleive that forth could supplant ruby and perl and python if it wanted to "A. K." <akk@nospam.org> - 2012-05-17 11:43 +0200
            Re: I beleive that forth could supplant ruby and perl and python if it wanted to "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-17 10:22 -0400
              Re: I beleive that forth could supplant ruby and perl and python if it wanted to "A. K." <akk@nospam.org> - 2012-05-17 17:03 +0200
                Re: I beleive that forth could supplant ruby and perl and python if it wanted to Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-18 01:15 +0200
                Re: I beleive that forth could supplant ruby and perl and python if it wanted to "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-17 19:19 -0400
                  Re: I beleive that forth could supplant ruby and perl and python if it wanted to Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-18 12:40 +0000
              Re: I beleive that forth could supplant ruby and perl and python if it wanted to Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-18 00:17 +0200
            Re: I beleive that forth could supplant ruby and perl and python if it wanted to vandys@vsta.org - 2012-05-17 16:02 +0000
              Re: I beleive that forth could supplant ruby and perl and python if it wanted to "A. K." <akk@nospam.org> - 2012-05-17 18:08 +0200
                Re: I beleive that forth could supplant ruby and perl and python if it wanted to vandys@vsta.org - 2012-05-17 16:58 +0000
              Re: I beleive that forth could supplant ruby and perl and python if it   to Nomen Nescio <nobody@dizum.com> - 2012-05-17 19:03 +0200
              Re: I beleive that forth could supplant ruby and perl and python if it wanted to Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-17 12:27 -0500
                Re: I beleive that forth could supplant ruby and perl and python if it wanted to vandys@vsta.org - 2012-05-17 18:52 +0000
                  Re: I beleive that forth could supplant ruby and perl and python if it wanted to Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-17 18:18 -0500
                  Re: I beleive that forth could supplant ruby and perl and python if it wanted to Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-05-18 01:39 -0700
                    Re: I beleive that forth could supplant ruby and perl and python if it wanted to Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-18 04:50 -0500
                      Re: I beleive that forth could supplant ruby and perl and python if it wanted to Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-05-18 04:40 -0700
                        Re: I beleive that forth could supplant ruby and perl and python if it wanted to humptydumpty <ouatubi@gmail.com> - 2012-05-18 15:15 +0300
                          Re: I beleive that forth could supplant ruby and perl and python if it wanted to "Elizabeth D. Rather" <erather@forth.com> - 2012-05-18 08:02 -1000
                Re: I beleive that forth could supplant ruby and perl and python if it wanted to Paul Rubin <no.email@nospam.invalid> - 2012-05-17 12:40 -0700
                  Re: I beleive that forth could supplant ruby and perl and python if it wanted to Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-17 18:32 -0500
                    Re: I beleive that forth could supplant ruby and perl and python if it wanted to Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-18 01:45 -0500
                      Re: I beleive that forth could supplant ruby and perl and python if it wanted to Paul Rubin <no.email@nospam.invalid> - 2012-05-19 11:28 -0700
                Re: I beleive that forth could supplant ruby and perl and python if it wanted to "Peter Knaggs" <pjk@bcs.org.uk> - 2012-05-17 21:38 +0100
                  Re: I beleive that forth could supplant ruby and perl and python if it wanted to vandys@vsta.org - 2012-05-17 21:17 +0000
                    Re: I beleive that forth could supplant ruby and perl and python if it wanted to stephenXXX@mpeforth.com (Stephen Pelc) - 2012-05-18 09:41 +0000
                      Re: I beleive that forth could supplant ruby and perl and python if it wanted to Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-18 04:55 -0500
                        Re: I beleive that forth could supplant ruby and perl and python if it wanted to stephenXXX@mpeforth.com (Stephen Pelc) - 2012-05-18 13:50 +0000
                      Re: I beleive that forth could supplant ruby and perl and python if it wanted to Mark Wills <markrobertwills@yahoo.co.uk> - 2012-05-18 03:24 -0700
                        Re: I beleive that forth could supplant ruby and perl and python if it wanted to Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-18 06:10 -0500
                        Re: I beleive that forth could supplant ruby and perl and python if it wanted to "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-18 08:10 -0400
                          Re: I beleive that forth could supplant ruby and perl and python if it wanted to Mark Wills <forthfreak@gmail.com> - 2012-05-18 05:57 -0700
                            Re: I beleive that forth could supplant ruby and perl and python if it wanted to "Elizabeth D. Rather" <erather@forth.com> - 2012-05-18 08:14 -1000
                        Re: I beleive that forth could supplant ruby and perl and python if it wanted to John Passaniti <john.passaniti@gmail.com> - 2012-05-18 10:01 -0700
                      VFX code quality (was: I beleive that forth could supplant ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-18 12:58 +0000
                        Re: VFX code quality Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-18 09:43 -0500
                          Re: VFX code quality anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-19 10:54 +0000
                            Re: VFX code quality Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-19 11:43 -0500
                              Re: VFX code quality anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-22 08:26 +0000
                                Re: VFX code quality Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-22 03:52 -0500
                                  Re: VFX code quality Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-22 04:02 -0500
                                    Re: VFX code quality anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-22 09:25 +0000
                                      Re: VFX code quality Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-30 23:39 +0200
                                        Re: VFX code quality anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-31 15:07 +0000
                                          Re: VFX code quality Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-31 20:24 +0200
                        Re: VFX code quality (was: I beleive that forth could supplant ...) stephenXXX@mpeforth.com (Stephen Pelc) - 2012-05-18 15:25 +0000
                          Re: VFX code quality (was: I beleive that forth could supplant ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-19 11:31 +0000
                          Re: VFX code quality (was: I beleive that forth could supplant ...) Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-20 17:41 +0200
                            Re: VFX code quality Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-20 12:49 -0500
                              Re: VFX code quality Paul Rubin <no.email@nospam.invalid> - 2012-05-20 11:43 -0700
                                Re: VFX code quality "Elizabeth D. Rather" <erather@forth.com> - 2012-05-20 14:01 -1000
                                  Re: VFX code quality Paul Rubin <no.email@nospam.invalid> - 2012-05-20 19:10 -0700
                                    Re: VFX code quality "Elizabeth D. Rather" <erather@forth.com> - 2012-05-20 17:05 -1000
                                      Re: VFX code quality Paul Rubin <no.email@nospam.invalid> - 2012-05-20 20:38 -0700
                                        Re: VFX code quality "Elizabeth D. Rather" <erather@forth.com> - 2012-05-20 21:37 -1000
                                          Re: VFX code quality Paul Rubin <no.email@nospam.invalid> - 2012-05-21 01:27 -0700
                                            Re: VFX code quality m.a.m.hendrix@tue.nl - 2012-05-21 01:52 -0700
                                              Re: VFX code quality Ecki <ecki@intershop.de> - 2012-05-21 11:06 +0200
                                                Re: VFX code quality mhx@iae.nl (Marcel Hendrix) - 2012-05-21 20:34 +0200
                                                  Re: VFX code quality Ecki <ecki@intershop.de> - 2012-05-22 08:54 +0200
                                              Re: VFX code quality anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-21 14:36 +0000
                                                Re: VFX code quality mhx@iae.nl (Marcel Hendrix) - 2012-05-21 20:33 +0200
                                            Re: VFX code quality Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-21 04:29 -0500
                                              Re: VFX code quality Paul Rubin <no.email@nospam.invalid> - 2012-05-21 08:39 -0700
                                                Re: VFX code quality Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-21 15:22 -0500
                                                  Re: VFX code quality Paul Rubin <no.email@nospam.invalid> - 2012-05-22 12:47 -0700
                                                    Re: VFX code quality "Elizabeth D. Rather" <erather@forth.com> - 2012-05-22 11:25 -1000
                                                    Re: VFX code quality Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-23 03:19 -0500
                                                      Re: VFX code quality Paul Rubin <no.email@nospam.invalid> - 2012-05-24 22:51 -0700
                                                        Re: VFX code quality Paul Rubin <no.email@nospam.invalid> - 2012-05-24 23:16 -0700
                                                    Re: VFX code quality Fritz Wuehler <fritz@spamexpire-201205.rodent.frell.theremailer.net> - 2012-05-23 17:36 +0200
                                            Re: VFX code quality Doug Hoffman <glidedog@gmail.com> - 2012-05-21 12:57 -0400
                                              Re: VFX code quality "Elizabeth D. Rather" <erather@forth.com> - 2012-05-21 08:42 -1000
                                                Re: VFX code quality Doug Hoffman <glidedog@gmail.com> - 2012-05-21 19:41 -0400
                                                  Re: VFX code quality Paul Rubin <no.email@nospam.invalid> - 2012-05-21 21:53 -0700
                                                    Re: VFX code quality Doug Hoffman <glidedog@gmail.com> - 2012-05-22 07:10 -0400
                                            Re: VFX code quality "Elizabeth D. Rather" <erather@forth.com> - 2012-05-21 08:36 -1000
                                              Re: VFX code quality Paul Rubin <no.email@nospam.invalid> - 2012-05-21 21:46 -0700
                                                Re: VFX code quality "Elizabeth D. Rather" <erather@forth.com> - 2012-05-21 20:30 -1000
                                            Re: VFX code quality David Kuehling <dvdkhlng@gmx.de> - 2012-05-22 14:06 +0200
                                              Re: VFX code quality Doug Hoffman <glidedog@gmail.com> - 2012-05-22 08:59 -0400
                                                FP locals (was: VFX code quality) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-22 13:39 +0000
                                                  Re: FP locals Doug Hoffman <glidedog@gmail.com> - 2012-05-22 14:03 -0400
                                                  Re: FP locals (was: VFX code quality) C G Montgomery <cgm@physics.utoledo.edu> - 2012-05-22 18:09 -0400
                                                    Re: FP locals (was: VFX code quality) Krishna Myneni <krishna.myneni@ccreweb.org> - 2012-05-23 03:47 -0700
                                                      Re: FP locals (was: VFX code quality) "Ed" <invalid@nospam.com> - 2012-05-26 21:03 +1000
                                                        Re: FP locals (was: VFX code quality) Krishna Myneni <krishna.myneni@ccreweb.org> - 2012-05-26 04:40 -0700
                                                          Re: FP locals (was: VFX code quality) mhx@iae.nl (Marcel Hendrix) - 2012-05-26 18:27 +0200
                                                            Re: FP locals (was: VFX code quality) Krishna Myneni <krishna.myneni@ccreweb.org> - 2012-05-26 12:55 -0700
                                                              Re: FP locals (was: VFX code quality) BruceMcF <agila61@netscape.net> - 2012-05-26 14:54 -0700
                                                                Re: FP locals (was: VFX code quality) Krishna Myneni <krishna.myneni@ccreweb.org> - 2012-05-26 22:02 -0700
                                                              Re: FP locals (was: VFX code quality) mhx@iae.nl (Marcel Hendrix) - 2012-05-27 08:50 +0200
                                                                Re: FP locals (was: VFX code quality) Krishna Myneni <krishna.myneni@ccreweb.org> - 2012-05-27 05:26 -0700
                                              Re: VFX code quality BruceMcF <agila61@netscape.net> - 2012-05-22 09:04 -0700
                                        Re: VFX code quality "A. K." <akk@nospam.org> - 2012-05-21 09:55 +0200
                                          Re: VFX code quality Paul Rubin <no.email@nospam.invalid> - 2012-05-21 01:22 -0700
                                            Re: VFX code quality "A. K." <akk@nospam.org> - 2012-05-21 14:19 +0200
                                              Re: VFX code quality Paul Rubin <no.email@nospam.invalid> - 2012-05-22 12:33 -0700
                                                Re: VFX code quality "A. K." <akk@nospam.org> - 2012-05-22 23:14 +0200
                                        Re: VFX code quality mhx@iae.nl (Marcel Hendrix) - 2012-05-21 20:31 +0200
                                          Re: VFX code quality Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-21 15:17 -0500
                                          Re: VFX code quality BruceMcF <agila61@netscape.net> - 2012-05-21 13:50 -0700
                                            Re: VFX code quality BruceMcF <agila61@netscape.net> - 2012-05-21 16:47 -0700
                                              Re: VFX code quality "Harry Vaderchi" <admin@127.0.0.1> - 2012-05-22 09:57 +0100
                                                Re: VFX code quality BruceMcF <agila61@netscape.net> - 2012-05-22 04:39 -0700
                                                  Re: VFX code quality mhx@iae.nl (Marcel Hendrix) - 2012-05-23 20:25 +0200
                                                    Re: VFX code quality BruceMcF <agila61@netscape.net> - 2012-05-23 13:47 -0700
                                        Re: VFX code quality humptydumpty <ouatubi@gmail.com> - 2012-05-21 20:23 +0000
                                    Re: VFX code quality BruceMcF <agila61@netscape.net> - 2012-05-20 20:22 -0700
                                    Re: VFX code quality Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-21 10:57 +0000
                              Re: VFX code quality Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-21 01:35 +0200
                              Re: VFX code quality Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-05-20 22:44 -0700
                                Re: VFX code quality Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-05-20 22:53 -0700
                                Re: VFX code quality Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-21 04:32 -0500
                                  Re: VFX code quality "Elizabeth D. Rather" <erather@forth.com> - 2012-05-21 08:44 -1000
                      Re: I beleive that forth could supplant ruby and perl and python if it wanted to Paul Rubin <no.email@nospam.invalid> - 2012-05-20 00:58 -0700
                        Re: I beleive that forth could supplant ruby and perl and python if it wanted to stephenXXX@mpeforth.com (Stephen Pelc) - 2012-05-20 15:09 +0000
                    Re: I beleive that forth could supplant ruby and perl and python if it wanted to "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-18 07:20 -0400
                      Re: I beleive that forth could supplant ruby and perl and python if it wanted to Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-18 10:22 -0500
                        Re: I beleive that forth could supplant ruby and perl and python if it wanted to "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-18 22:09 -0400
                          Re: I beleive that forth could supplant ruby and perl and python if it wanted to Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-19 04:20 -0500
                            Re: I beleive that forth could supplant ruby and perl and python if it wanted to Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-19 13:19 +0000
                  Re: I beleive that forth could supplant ruby and perl and python if it wanted to Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-17 18:33 -0500
                    Re: I beleive that forth could supplant ruby and perl and python if it wanted to Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-05-18 01:49 -0700
                    Re: I beleive that forth could supplant ruby and perl and python if it wanted to Paul Rubin <no.email@nospam.invalid> - 2012-05-18 07:59 -0700
                      Re: I beleive that forth could supplant ruby and perl and python if it wanted to Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-18 10:32 -0500
                        Re: I beleive that forth could supplant ruby and perl and python if it wanted to Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-20 17:24 +0200
                        Re: I beleive that forth could supplant ruby and perl and python if it wanted to Paul Rubin <no.email@nospam.invalid> - 2012-05-20 15:43 -0700
                          Re: I beleive that forth could supplant ruby and perl and python if it wanted to BruceMcF <agila61@netscape.net> - 2012-05-20 16:03 -0700
                            Re: I beleive that forth could supplant ruby and perl and python if it wanted to Paul Rubin <no.email@nospam.invalid> - 2012-05-20 16:34 -0700
                              Re: I beleive that forth could supplant ruby and perl and python if it wanted to BruceMcF <agila61@netscape.net> - 2012-05-20 17:02 -0700
                              Re: I beleive that forth could supplant ruby and perl and python if it wanted to Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-21 04:46 -0500
                                Re: I beleive that forth could supplant ruby and perl and python if it wanted to Paul Rubin <no.email@nospam.invalid> - 2012-05-21 08:33 -0700
                                  Re: I beleive that forth could supplant ruby and perl and python if it wanted to BruceMcF <agila61@netscape.net> - 2012-05-21 12:10 -0700
                          Re: I beleive that forth could supplant ruby and perl and python if it wanted to Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-21 04:40 -0500
                            address units (was: I beleive that forth could supplant ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-21 14:40 +0000
                              Re: address units Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-21 10:07 -0500
                          Re: I beleive that forth could supplant ruby and perl and python if it wanted to Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-21 10:59 +0000
                          Re: I beleive that forth could supplant ruby and perl and python if it wanted to anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-21 14:22 +0000
                Re: I beleive that forth could supplant ruby and perl and python if it wanted to Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-18 00:43 +0200
                  Re: I beleive that forth could supplant ruby and perl and python if it wanted to vandys@vsta.org - 2012-05-17 23:10 +0000
                  Re: I beleive that forth could supplant ruby and perl and python if it wanted to Doug Hoffman <glidedog@gmail.com> - 2012-05-17 19:24 -0400
                  Re: I beleive that forth could supplant ruby and perl and python if it wanted to Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-17 18:38 -0500
              Re: I beleive that forth could supplant ruby and perl and python if it wanted to Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-17 22:30 +0000
          Re: I beleive that forth could supplant ruby and perl and python if it wanted to BruceMcF <agila61@netscape.net> - 2012-05-17 10:59 -0700
            Re: I beleive that forth could supplant ruby and perl and python if it wanted to Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2012-05-20 13:14 +0100
    Re: I beleive that forth could supplant ruby and perl and python if it wanted to marko <marko@marko.marko> - 2012-05-18 11:46 +1000
      Re: I beleive that forth could supplant ruby and perl and python if it wanted to "Elizabeth D. Rather" <erather@forth.com> - 2012-05-17 20:10 -1000
      Re: I beleive that forth could supplant ruby and perl and python if it wanted to Arnold Doray <invalid@invalid.com> - 2012-05-18 10:32 +0000
        Re: I beleive that forth could supplant ruby and perl and python if it wanted to marko <marko@marko.marko> - 2012-05-18 21:27 +1000
    Re: I beleive that forth could supplant ruby and perl and python if it wanted to Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-05-18 22:58 -0700

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

#12248

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2012-05-17 18:18 -0500
Message-ID	<-MidndeM3PXLGijSnZ2dnUVZ_rSdnZ2d@supernews.com>
In reply to	#12238

vandys@vsta.org wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
> 
>>> void
>>> memcopy(char *src, char *dest, int count)
>>> {
>>>    while (count--) {
>>>        *dest++ = *src++;
>>>    }
>>> }
>>> ...
> 
> ( Presumably:
> : memcopy ( src dest count -- )
>>  over + swap ?do  dup c@ i c!  1+  loop drop
> ( ; )
> 
> Andrew, you're one of the top "real" Forth coders on the group, and
> yes, this is probably the best one can do WRT Forth style.  Because
> of the stack gymnastics I would've added some stack comments too.

Maybe.  This is pretty vanilla Forth, really.

> As somebody pretty familiar with both C and Forth, it took me quite a bit
> longer to convince myself of the Forth code.
> 
>> I'm not so sure.  For many things, Forth is a very neat environment in
>> which you can get things done.
> 
> How would you modify your version of the code to carry a sum?  (Let's assume
> we want to keep the code reentrant, so no global variable.)  I'm guessing
> it'd be time to break out locals.

Could be.  Maybe do it on the stack.  Locals are there to be useful.
But I rather think you're moving the goalposts.  :-)

>> As a recent example that I can speak of, I wrote an experimental
>> software transactional memory system.  I know how hard it is to do
>> this in other languages.
> 
> That seems like apples and oranges.  The GCC stuff is to integrate
> shared memory semantics into basic memory references.  You seem to
> be talking about something more like Python Durus?  Where you have
> your own level of objects which are used to fetch and store values?

No, I redefined @ ! and so on, so that you can just write normal Forth
(with some restrictions such as no I/O operations) and it works
transactionally.  It's a matter of recompiling and it's a transaction.

Andrew.

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

#12262

From	Hugh Aguilar <hughaguilar96@yahoo.com>
Date	2012-05-18 01:39 -0700
Message-ID	<8fe2cc47-4f15-421c-bf2d-f0ca5f8f4f0c@x6g2000pbh.googlegroups.com>
In reply to	#12238

On May 17, 11:52 am, van...@vsta.org wrote:
> Andrew Haley <andre...@littlepinkcloud.invalid> wrote:
> >> void
> >> memcopy(char *src, char *dest, int count)
> >> {
> >>    while (count--) {
> >>        *dest++ = *src++;
> >>    }
> >> }
> >> ...
>
> ( Presumably:
> : memcopy ( src dest count -- )>  over + swap ?do  dup c@ i c!  1+  loop drop
>
> ( ; )
>
> Andrew, you're one of the top "real" Forth coders on the group, and
> yes, this is probably the best one can do WRT Forth style.  Because
> of the stack gymnastics I would've added some stack comments too.
> As somebody pretty familiar with both C and Forth, it took me quite a bit
> longer to convince myself of the Forth code.

: memcopy ( src dest count -- )
    over + swap ?do  dup c@ i c!  1+  loop drop ;

Wow! I wish I were a "real" Forth programmer!

Just for the sake of simplicity, lets assume that we know ahead of
time that the destination is below the source. We still have the
problem that DO loops are generally inefficient. Here is a version
that uses a BEGIN loop (notice how similar this is to EXCHANGE in the
novice package):

: memcopy ( src dest count -- )
    begin  dup while
        rover c@  rover c!
        rot 1+  rot 1+  rot 1-  repeat
    3drop ;

Note that ROVER is defined like this:

macro: rover ( a b c -- a b c a )
    2 pick ;

If being a "real" Forth programmer involves writing mind-blowing code,
here is a version that uses coroutines:

: get-data ( src dst cnt -- )
    begin  3dup dive  dup while  rot 1+  rot 1+  rot 1-  repeat
3drop ;

: put-data ( src dst cnt -- )
    get-data
    begin
        dup while  drop  swap c@ swap c!  dive  repeat  3drop ;

There is actually less "stack juggling" in this version, as we don't
need to use ROVER to access the pointers. That is the upside of mind-
blowing complexity. :-)

Note that DIVE is defined like this:

: dive ( -- )              \ r: ret-adr ip -- ip ret-adr
    2r>  >r >r ;

\ the return stack is from the perspective of the word that is calling
DIVE

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

#12265

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2012-05-18 04:50 -0500
Message-ID	<X6OdndxV_vTNhivSnZ2dnUVZ_tqdnZ2d@supernews.com>
In reply to	#12262

Hugh Aguilar <hughaguilar96@yahoo.com> wrote:
> On May 17, 11:52?am, van...@vsta.org wrote:
>> Andrew Haley <andre...@littlepinkcloud.invalid> wrote:
>> >> void
>> >> memcopy(char *src, char *dest, int count)
>> >> {
>> >> ? ?while (count--) {
>> >> ? ? ? ?*dest++ = *src++;
>> >> ? ?}
>> >> }
>> >> ...
>>
>> ( Presumably:
>> : memcopy ( src dest count -- )> ?over + swap ?do ?dup c@ i c! ?1+ ?loop drop
>>
>> ( ; )
>>
>> Andrew, you're one of the top "real" Forth coders on the group, and
>> yes, this is probably the best one can do WRT Forth style. ?Because
>> of the stack gymnastics I would've added some stack comments too.
>> As somebody pretty familiar with both C and Forth, it took me quite a bit
>> longer to convince myself of the Forth code.
> 
> : memcopy ( src dest count -- )
>    over + swap ?do  dup c@ i c! 1+  loop drop ;

Let's try this with VFX.  The inner loop is:

1:        MOVZX     EDX, Byte Ptr 0 [EBX]
          MOV       ECX, [ESP]
          MOV       0 [ECX], DL
          INC       EBX
          ADD       [ESP], 01
          ADD       [ESP+04], 01
          JNO       1

It's not perfect because the loop parameters are kept in memory,
presumably because x86/32 is desperately short of registers, but it's
not bad.

> Wow! I wish I were a "real" Forth programmer!

Don't we all.

> Just for the sake of simplicity, lets assume that we know ahead of
> time that the destination is below the source. We still have the
> problem that DO loops are generally inefficient. Here is a version
> that uses a BEGIN loop (notice how similar this is to EXCHANGE in the
> novice package):
> 
> : memcopy ( src dest count -- )
>    begin  dup while
>        rover c@  rover c!
>        rot 1+  rot 1+  rot 1-  repeat
>    3drop ;
> 
> Note that ROVER is defined like this:
> 
> macro: rover ( a b c -- a b c a )
>    2 pick ;

The inner loop is:

2:       TEST      EBX, EBX
         JZ/E      2
         MOV       EDX, [EBP+04]
         MOVZX     EDX, Byte Ptr 0 [EDX]
         MOV       ECX, [EBP]
         MOV       0 [ECX], DL
         MOV       EDX, [EBP+04]
         INC       EDX
         MOV       ECX, [EBP]
         INC       ECX
         DEC       EBX
         MOV       [EBP], ECX
         MOV       [EBP+04], EDX
         JMP       1
1:

So, you've succeeded in making the code much harder to understand and
you've made it slower.  What was it you were trying to achieve?

Andrew.

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

#12272

From	Hugh Aguilar <hughaguilar96@yahoo.com>
Date	2012-05-18 04:40 -0700
Message-ID	<d0031b0e-d1e2-43cd-9c6d-8425a6667dcd@ki5g2000pbb.googlegroups.com>
In reply to	#12265

On May 18, 2:50 am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> So, you've succeeded in making the code much harder to understand and
> you've made it slower.  What was it you were trying to achieve?

I don't think that the BEGIN version is "much harder to understand"
--- personally, I've thought that DO loops were confusing since 1984
--- I won't support DO loops at all in Straight Forth.

Anyway, here it is in SwiftForth:

: memcopy ( src dest count -- )
    over + swap ?do  dup c@ i c!  1+  loop drop ;  ok
see memcopy
480B1F   0 [EBP] EBX ADD                035D00
480B22   0 [EBP] EAX MOV                8B4500
480B25   EBX 0 [EBP] MOV                895D00
480B28   EAX EBX MOV                    8BD8
480B2A   0 [EBP] EBX CMP                3B5D00
480B2D   480B3A JNZ                     750B
480B2F   4 [EBP] EBX MOV                8B5D04
480B32   8 # EBP ADD                    83C508
480B35   480B70 JMP                     E936000000
480B3A   40235F ( (DO) ) CALL           E82018F8FF
480B3F   4 # EBP SUB                    83ED04
480B42   EBX 0 [EBP] MOV                895D00
480B45   EAX EAX XOR                    31C0
480B47   0 [EBX] AL MOV                 8A03
480B49   EAX EBX MOV                    8BD8
480B4B   4 # EBP SUB                    83ED04
480B4E   EBX 0 [EBP] MOV                895D00
480B51   0 [ESP] EBX MOV                8B1C24
480B54   4 [ESP] EBX ADD                035C2404
480B58   0 [EBP] EAX MOV                8B4500
480B5B   AL 0 [EBX] MOV                 8803
480B5D   4 [EBP] EBX MOV                8B5D04
480B60   8 # EBP ADD                    83C508
480B63   EBX INC                        43
480B64   0 [ESP] INC                    FF0424
480B67   480B3F JNO                     0F81D2FFFFFF
480B6D   8 # ESP ADD                    83C408
480B70   0 [EBP] EBX MOV                8B5D00
480B73   4 # EBP ADD                    83C504
480B76   RET                            C3 ok
see (do)
40235F   EDX POP                        5A
402360   0 [EBP] EAX MOV                8B4500
402363   -80000000 # EAX ADD            0500000080
402368   EAX PUSH                       50
402369   EAX EBX SUB                    29C3
40236B   EBX PUSH                       53
40236C   4 [EBP] EBX MOV                8B5D04
40236F   8 # EBP ADD                    83C508
402372   EDX JMP                        FFE2 ok

And here is the other version:

: memcopy ( src dest count -- )
    begin  dup while
        rover c@  rover c!
        rot 1+  rot 1+  rot 1-  repeat
    3drop ;  ok
see memcopy
480B8F   EBX EBX OR                     09DB
480B91   480BEC JZ                      0F8455000000
480B97   4 # EBP SUB                    83ED04
480B9A   EBX 0 [EBP] MOV                895D00
480B9D   8 [EBP] EBX MOV                8B5D08
480BA0   EAX EAX XOR                    31C0
480BA2   0 [EBX] AL MOV                 8A03
480BA4   EAX EBX MOV                    8BD8
480BA6   4 # EBP SUB                    83ED04
480BA9   EBX 0 [EBP] MOV                895D00
480BAC   8 [EBP] EBX MOV                8B5D08
480BAF   0 [EBP] EAX MOV                8B4500
480BB2   AL 0 [EBX] MOV                 8803
480BB4   4 [EBP] EBX MOV                8B5D04
480BB7   8 # EBP ADD                    83C508
480BBA   EBX ECX MOV                    8BCB
480BBC   4 [EBP] EBX MOV                8B5D04
480BBF   0 [EBP] EAX MOV                8B4500
480BC2   EAX 4 [EBP] MOV                894504
480BC5   ECX 0 [EBP] MOV                894D00
480BC8   EBX INC                        43
480BC9   EBX ECX MOV                    8BCB
480BCB   4 [EBP] EBX MOV                8B5D04
480BCE   0 [EBP] EAX MOV                8B4500
480BD1   EAX 4 [EBP] MOV                894504
480BD4   ECX 0 [EBP] MOV                894D00
480BD7   EBX INC                        43
480BD8   EBX ECX MOV                    8BCB
480BDA   4 [EBP] EBX MOV                8B5D04
480BDD   0 [EBP] EAX MOV                8B4500
480BE0   EAX 4 [EBP] MOV                894504
480BE3   ECX 0 [EBP] MOV                894D00
480BE6   EBX DEC                        4B
480BE7   480B8F JMP                     E9A3FFFFFF
480BEC   8 [EBP] EBX MOV                8B5D08
480BEF   C # EBP ADD                    83C50C
480BF2   RET                            C3 ok

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

#12275

From	humptydumpty <ouatubi@gmail.com>
Date	2012-05-18 15:15 +0300
Message-ID	<jp5efu$94d$1@dont-email.me>
In reply to	#12272

Hugh Aguilar wrote:

> On May 18, 2:50 am, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>> So, you've succeeded in making the code much harder to understand and
>> you've made it slower.  What was it you were trying to achieve?
> 
> I don't think that the BEGIN version is "much harder to understand"
> --- personally, I've thought that DO loops were confusing since 1984
> --- I won't support DO loops at all in Straight Forth.
> 
> Anyway, here it is in SwiftForth:
> 
> : memcopy ( src dest count -- )
>     over + swap ?do  dup c@ i c!  1+  loop drop ;  ok
> see memcopy
> 480B1F   0 [EBP] EBX ADD                035D00
> 480B22   0 [EBP] EAX MOV                8B4500
> 480B25   EBX 0 [EBP] MOV                895D00
> 480B28   EAX EBX MOV                    8BD8
> 480B2A   0 [EBP] EBX CMP                3B5D00
> 480B2D   480B3A JNZ                     750B
> 480B2F   4 [EBP] EBX MOV                8B5D04
> 480B32   8 # EBP ADD                    83C508
> 480B35   480B70 JMP                     E936000000
> 480B3A   40235F ( (DO) ) CALL           E82018F8FF
> 480B3F   4 # EBP SUB                    83ED04
> 480B42   EBX 0 [EBP] MOV                895D00
> 480B45   EAX EAX XOR                    31C0
> 480B47   0 [EBX] AL MOV                 8A03
> 480B49   EAX EBX MOV                    8BD8
> 480B4B   4 # EBP SUB                    83ED04
> 480B4E   EBX 0 [EBP] MOV                895D00
> 480B51   0 [ESP] EBX MOV                8B1C24
> 480B54   4 [ESP] EBX ADD                035C2404
> 480B58   0 [EBP] EAX MOV                8B4500
> 480B5B   AL 0 [EBX] MOV                 8803
> 480B5D   4 [EBP] EBX MOV                8B5D04
> 480B60   8 # EBP ADD                    83C508
> 480B63   EBX INC                        43
> 480B64   0 [ESP] INC                    FF0424
> 480B67   480B3F JNO                     0F81D2FFFFFF
> 480B6D   8 # ESP ADD                    83C408
> 480B70   0 [EBP] EBX MOV                8B5D00
> 480B73   4 # EBP ADD                    83C504
> 480B76   RET                            C3 ok
> see (do)
> 40235F   EDX POP                        5A
> 402360   0 [EBP] EAX MOV                8B4500
> 402363   -80000000 # EAX ADD            0500000080
> 402368   EAX PUSH                       50
> 402369   EAX EBX SUB                    29C3
> 40236B   EBX PUSH                       53
> 40236C   4 [EBP] EBX MOV                8B5D04
> 40236F   8 # EBP ADD                    83C508
> 402372   EDX JMP                        FFE2 ok
> 
> And here is the other version:
> 
> : memcopy ( src dest count -- )
>     begin  dup while
>         rover c@  rover c!
>         rot 1+  rot 1+  rot 1-  repeat
>     3drop ;  ok
> see memcopy
> 480B8F   EBX EBX OR                     09DB
> 480B91   480BEC JZ                      0F8455000000
> 480B97   4 # EBP SUB                    83ED04
> 480B9A   EBX 0 [EBP] MOV                895D00
> 480B9D   8 [EBP] EBX MOV                8B5D08
> 480BA0   EAX EAX XOR                    31C0
> 480BA2   0 [EBX] AL MOV                 8A03
> 480BA4   EAX EBX MOV                    8BD8
> 480BA6   4 # EBP SUB                    83ED04
> 480BA9   EBX 0 [EBP] MOV                895D00
> 480BAC   8 [EBP] EBX MOV                8B5D08
> 480BAF   0 [EBP] EAX MOV                8B4500
> 480BB2   AL 0 [EBX] MOV                 8803
> 480BB4   4 [EBP] EBX MOV                8B5D04
> 480BB7   8 # EBP ADD                    83C508
> 480BBA   EBX ECX MOV                    8BCB
> 480BBC   4 [EBP] EBX MOV                8B5D04
> 480BBF   0 [EBP] EAX MOV                8B4500
> 480BC2   EAX 4 [EBP] MOV                894504
> 480BC5   ECX 0 [EBP] MOV                894D00
> 480BC8   EBX INC                        43
> 480BC9   EBX ECX MOV                    8BCB
> 480BCB   4 [EBP] EBX MOV                8B5D04
> 480BCE   0 [EBP] EAX MOV                8B4500
> 480BD1   EAX 4 [EBP] MOV                894504
> 480BD4   ECX 0 [EBP] MOV                894D00
> 480BD7   EBX INC                        43
> 480BD8   EBX ECX MOV                    8BCB
> 480BDA   4 [EBP] EBX MOV                8B5D04
> 480BDD   0 [EBP] EAX MOV                8B4500
> 480BE0   EAX 4 [EBP] MOV                894504
> 480BE3   ECX 0 [EBP] MOV                894D00
> 480BE6   EBX DEC                        4B
> 480BE7   480B8F JMP                     E9A3FFFFFF
> 480BEC   8 [EBP] EBX MOV                8B5D08
> 480BEF   C # EBP ADD                    83C50C
> 480BF2   RET                            C3 ok

Hi!

Yet another version:
8<---
: c@!++  ( src dest -- src+1 dest+1 )
  over c@ over c! 1+ swap 1+ swap ;

: memcopy ( src dest count -- )
  BEGIN  dup
  WHILE -rot c@!++ rot 1-
  REPEAT 2drop drop ;
--->8

Have a nice day,
humptydumpty

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

#12288

From	"Elizabeth D. Rather" <erather@forth.com>
Date	2012-05-18 08:02 -1000
Message-ID	<fKCdnYq64KNPEyvSnZ2dnUVZ_qmdnZ2d@supernews.com>
In reply to	#12275

On 5/18/12 2:15 AM, humptydumpty wrote:
> Hugh Aguilar wrote:
>
...
>> >  Anyway, here it is in SwiftForth:

Please note that he has a very old version of SwiftForth.

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]

#12239

From	Paul Rubin <no.email@nospam.invalid>
Date	2012-05-17 12:40 -0700
Message-ID	<7xr4uippdp.fsf@ruckus.brouhaha.com>
In reply to	#12234

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> ... the GCC people have spent a long time working on STM, and it
> requires big changes in the guts of the compiler...  In an extensible
> language, you can do this by writing a program: you don't have to
> touch the compiler.

But it looks like there are several C library implementations:

  http://en.wikipedia.org/wiki/Software_transactional_memory#C.2FC.2B.2B

I'd imagine it imposing some style constraints, but otherwise just
needing a few asm intrinsics rather than serious compiler hacking.  I'm
not sure but I don't think Haskell's implementation required changing
the compiler.  It's just some FFI calls to assembly language routines,
I'd imagine (I haven't looked).

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

#12251

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2012-05-17 18:32 -0500
Message-ID	<wLGdndLbSfnrFyjSnZ2dnUVZ_uOdnZ2d@supernews.com>
In reply to	#12239

Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> ... the GCC people have spent a long time working on STM, and it
>> requires big changes in the guts of the compiler...  In an extensible
>> language, you can do this by writing a program: you don't have to
>> touch the compiler.
> 
> But it looks like there are several C library implementations:
> 
>  http://en.wikipedia.org/wiki/Software_transactional_memory#C.2FC.2B.2B

There are, yes, if you want to do it all with library calls.  (And
they're complicated: feel free to compare and contrast.)  Language
binding and the way it fits with everything else is important.  You
really want to be able to say something like

atomic {
   node.next = head; head = node;
}

or

also atomic 
: insert ( node)   head @ over !  head ! ;
only forth

> I'd imagine it imposing some style constraints, but otherwise just
> needing a few asm intrinsics rather than serious compiler hacking.
> I'm not sure but I don't think Haskell's implementation required
> changing the compiler.

I'm pretty sure it did, but then Haskell has to do its shared
persistent storage through state monads anyway.

Andrew.

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

#12260

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2012-05-18 01:45 -0500
Message-ID	<98-dnYFAcaW_bSjSnZ2dnUVZ_uSdnZ2d@supernews.com>
In reply to	#12251

Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
> Paul Rubin <no.email@nospam.invalid> wrote:

>> 
>> But it looks like there are several C library implementations:
>> 
>>  http://en.wikipedia.org/wiki/Software_transactional_memory#C.2FC.2B.2B
> 
> There are, yes, if you want to do it all with library calls.  (And
> they're complicated: feel free to compare and contrast.)  Language
> binding and the way it fits with everything else is important.  You
> really want to be able to say something like
> 
> atomic {
>   node.next = head; head = node;

Oops, should be

  node->next = head; head = node;

> }
> 
> or
> 
> also atomic 
> : insert ( node)   head @ over !  head ! ;
> only forth

FYI, I think a C library call version might look like

  {
    sigjmp_buf retry;
    sigsetjmp (&retry);

    TxStart (self, retry, false);
    TxStore (self, &(node->next), TxLoad (self, &head));
    TxStore (self, &head, node);
    TxCommit (self);
  }

Andrew.

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

#12303

From	Paul Rubin <no.email@nospam.invalid>
Date	2012-05-19 11:28 -0700
Message-ID	<7xr4ugc9ez.fsf@ruckus.brouhaha.com>
In reply to	#12260

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> FYI, I think a C library call version might look like
>
>   {
>     sigjmp_buf retry;
>     sigsetjmp (&retry);
>
>     TxStart (self, retry, false);
>     TxStore (self, &(node->next), TxLoad (self, &head));
>     TxStore (self, &head, node);
>     TxCommit (self);
>   }

Yeah, that's kind of ugly but lots of interpreters are written that way.
Maybe it could be a bit nicer with C++ operator overloading.

Also might be possible to use a wrapper function to remove some
boilerplate.  With GCC nested functions:

    {
        void action (self) {
           TxStore (self, &(node->next), TxLoad (self, &head));
           TxStore (self, &head, node);
        }
        atomically (action);
    }

where atomically is a library function that sets up the transaction and
retry and so forth.  This is sort of what Haskell does, though syntax
sugar in the language papers over the nested functions.

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

#12241

From	"Peter Knaggs" <pjk@bcs.org.uk>
Date	2012-05-17 21:38 +0100
Message-ID	<op.wegzmomwsu5d0p@david>
In reply to	#12234

Andrew Haley wrote:
>
> But since you ask, it's:
>
>   over + swap ?do  dup c@ i c!  1+  loop drop

This makes the, very common, assumption that a character is one
address unit wide.  A portable version would be:

   chars over + swap ?do count i c! [ 1 chars ] literal +loop drop

and we also have

: movesum ( src dest count -- sum )
   chars over + 0 swap rot ?do
     swap count dup i c! rot +
   [ 1 chars ] literal +loop nip
;

Of course if you make sum a local variable it is a little easer.

-- 
Peter Knaggs

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

#12242

From	vandys@vsta.org
Date	2012-05-17 21:17 +0000
Message-ID	<a1l87gFvfoU1@mid.individual.net>
In reply to	#12241

Peter Knaggs <pjk@bcs.org.uk> wrote:
> : movesum ( src dest count -- sum )
>   chars over + 0 swap rot ?do
>     swap count dup i c! rot +
>   [ 1 chars ] literal +loop nip
> ;

I suspect only the most fervent Forth'er would argue that the Forth version
is easier to read or to write.  The source would bulk up a bit--but probably
be easier to follow--if local variables were used.  As it is, the stack
gymnastics are about par for the course.

Also, can anybody feed that into their compiler and get better code than gcc
produced?  Omitting the procedure call noise, at -O2 the code is:

(count in EBX, src in EDI, dest in ESI)

        xorl    %edx, %edx
        testl   %ebx, %ebx
        je      .L3
.L6:
        movsbl  (%edi,%edx),%ecx
        movb    %cl, (%esi,%edx)
        addl    $1, %edx
        addl    %ecx, %eax
        cmpl    %ebx, %edx
        jne     .L6
.L3:

-- 
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html

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

#12264

From	stephenXXX@mpeforth.com (Stephen Pelc)
Date	2012-05-18 09:41 +0000
Message-ID	<4fb612ab.267100980@192.168.0.50>
In reply to	#12242

On 17 May 2012 21:17:36 GMT, vandys@vsta.org wrote:

>Also, can anybody feed that into their compiler and get better code than gcc
>produced?  Omitting the procedure call noise, at -O2 the code is:
>
>(count in EBX, src in EDI, dest in ESI)
>
>        xorl    %edx, %edx
>        testl   %ebx, %ebx
>        je      .L3
>.L6:
>        movsbl  (%edi,%edx),%ecx
>        movb    %cl, (%esi,%edx)
>        addl    $1, %edx
>        addl    %ecx, %eax
>        cmpl    %ebx, %edx
>        jne     .L6
>.L3:

I tried the following on VFX:

: movesum  \ src dest len -- sum
  0 -rot  bounds ?do                  \ -- src sum
    over c@ dup i c! +  swap 1+ swap
  loop
  nip
;

The inner loop is
\ .L6
( 004C7E80    8B5500 )                MOV       EDX, [EBP]
( 004C7E83    0FB612 )                MOVZX     EDX, Byte Ptr 0 [EDX]
( 004C7E86    8B0C24 )                MOV       ECX, [ESP]
( 004C7E89    8811 )                  MOV       0 [ECX], DL
( 004C7E8B    03DA )                  ADD       EBX, EDX
( 004C7E8D    8B5500 )                MOV       EDX, [EBP]
( 004C7E90    42 )                    INC       EDX
( 004C7E91    83042401 )              ADD       [ESP], 01
( 004C7E95    8344240401 )            ADD       [ESP+04], 01
( 004C7E9A    895500 )                MOV       [EBP], EDX
( 004C7E9D    71E1 )                  JNO       004C7E80
\ .L3

That's 11 instructions versus 6. Not so good. What would we need
to do to improve this? Remember that the design decisions and
financing of gcc and VFX are very different. gcc is supported by
major corporations. VFX is designed to be a fast one-pass compiler
for Forth.

What's really killing us here is the memory traffic. The memory
traffic arrives because
a) we generate a canonical stack at loop boundaries,
b) Forth is bad at handling four items

There are two solutions
a) adjust the canonical stack model at inner block
boundaries. This is doable at the expense of complexity
and the x86 code generator is already 6000 lines of source.
b) Use register-based locals. I believe Marcel does this
in some versions of iForth.

I'm already getting complaints that the VFX compiler is not fast
enough. Let's change the comparisons. VFX compiles 1M lines
of Forth source code in about 40 seconds on an i7. How long
does gcc take at -O2 ? Heavens to Murgatroyd, if you stay with
C, you'll never get any work done! And you have surrendered
your Open Source soul to Intel and AMD!

Teasing aside, there are reasons for the differences. If I
spent as much time and effort on VFX as has been spent on gcc,
I'm sure I could get similar results. A more productive
focus is to ask what Forth is good for and to understand the
design decisions in the compilers for Forth and C.

So, where do I get benefit from Forth? From the use of an
interactive, extensible language. I spent some of Wednesday
listening to a presentation about the debug tools needed for
gdb. I was appalled by the technology required when you use
the wrong approach to debugging.

But thanks for retriggering the code generation competition.
I now have work to do ...

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#12266

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2012-05-18 04:55 -0500
Message-ID	<X6Odnd9V_vQKgSvSnZ2dnUVZ_tqdnZ2d@supernews.com>
In reply to	#12264

Stephen Pelc <stephenXXX@mpeforth.com> wrote:

> What's really killing us here is the memory traffic. The memory
> traffic arrives because
> a) we generate a canonical stack at loop boundaries,
> b) Forth is bad at handling four items
> 
> There are two solutions
> a) adjust the canonical stack model at inner block
> boundaries. This is doable at the expense of complexity
> and the x86 code generator is already 6000 lines of source.
> b) Use register-based locals. I believe Marcel does this
> in some versions of iForth.
>
> I'm already getting complaints that the VFX compiler is not fast
> enough. Let's change the comparisons. VFX compiles 1M lines
> of Forth source code in about 40 seconds on an i7. How long
> does gcc take at -O2 ? Heavens to Murgatroyd, if you stay with
> C, you'll never get any work done! And you have surrendered
> your Open Source soul to Intel and AMD!

LOL!  I would have thought the more interesting question was whether
to stick with the register-starved x86/32 model.  64-bit is where
you'll get the big win with locals and/or stack in registers.

But really, why is all this micro-optimization such a huge deal
anyway?  I think it's rather silly.  Are your customers clamouring for
better code generation?

Andrew.

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

#12280

From	stephenXXX@mpeforth.com (Stephen Pelc)
Date	2012-05-18 13:50 +0000
Message-ID	<4fb65051.282883445@192.168.0.50>
In reply to	#12266

On Fri, 18 May 2012 04:55:35 -0500, Andrew Haley
<andrew29@littlepinkcloud.invalid> wrote:

>LOL!  I would have thought the more interesting question was whether
>to stick with the register-starved x86/32 model.  64-bit is where
>you'll get the big win with locals and/or stack in registers.

Sure.

>But really, why is all this micro-optimization such a huge deal
>anyway?  I think it's rather silly.  Are your customers clamouring for
>better code generation?

I didn't start this one!

No, our customers are not clamouring for better code generation.
For us, it's mostly good enough. However, performance is an
enabling technology to permit us to write portable libraries.
Especially in the embedded space, portable libraries for things
like FAT file systems, USB stacks and a TCP/IP stack are a
big win.

That having been said, I am personally always interested in seeing
what needs to be done to write better/faster code. The code generator
is one part of the chain.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#12268

From	Mark Wills <markrobertwills@yahoo.co.uk>
Date	2012-05-18 03:24 -0700
Message-ID	<f0902853-ea0e-4891-9240-366ee2902b8f@d17g2000vbv.googlegroups.com>
In reply to	#12264

On May 18, 10:41 am, stephen...@mpeforth.com (Stephen Pelc) wrote:
> On 17 May 2012 21:17:36 GMT, van...@vsta.org wrote:
>
>
>
>
>
> >Also, can anybody feed that into their compiler and get better code than gcc
> >produced?  Omitting the procedure call noise, at -O2 the code is:
>
> >(count in EBX, src in EDI, dest in ESI)
>
> >        xorl    %edx, %edx
> >        testl   %ebx, %ebx
> >        je      .L3
> >.L6:
> >        movsbl  (%edi,%edx),%ecx
> >        movb    %cl, (%esi,%edx)
> >        addl    $1, %edx
> >        addl    %ecx, %eax
> >        cmpl    %ebx, %edx
> >        jne     .L6
> >.L3:
>
> I tried the following on VFX:
>
> : movesum  \ src dest len -- sum
>   0 -rot  bounds ?do                  \ -- src sum
>     over c@ dup i c! +  swap 1+ swap
>   loop
>   nip
> ;
>
> The inner loop is
> \ .L6
> ( 004C7E80    8B5500 )                MOV       EDX, [EBP]
> ( 004C7E83    0FB612 )                MOVZX     EDX, Byte Ptr 0 [EDX]
> ( 004C7E86    8B0C24 )                MOV       ECX, [ESP]
> ( 004C7E89    8811 )                  MOV       0 [ECX], DL
> ( 004C7E8B    03DA )                  ADD       EBX, EDX
> ( 004C7E8D    8B5500 )                MOV       EDX, [EBP]
> ( 004C7E90    42 )                    INC       EDX
> ( 004C7E91    83042401 )              ADD       [ESP], 01
> ( 004C7E95    8344240401 )            ADD       [ESP+04], 01
> ( 004C7E9A    895500 )                MOV       [EBP], EDX
> ( 004C7E9D    71E1 )                  JNO       004C7E80
> \ .L3
>
> That's 11 instructions versus 6. Not so good. What would we need
> to do to improve this? Remember that the design decisions and
> financing of gcc and VFX are very different. gcc is supported by
> major corporations. VFX is designed to be a fast one-pass compiler
> for Forth.
>
> What's really killing us here is the memory traffic. The memory
> traffic arrives because
> a) we generate a canonical stack at loop boundaries,
> b) Forth is bad at handling four items
>
> There are two solutions
> a) adjust the canonical stack model at inner block
> boundaries. This is doable at the expense of complexity
> and the x86 code generator is already 6000 lines of source.
> b) Use register-based locals. I believe Marcel does this
> in some versions of iForth.
>
> I'm already getting complaints that the VFX compiler is not fast
> enough. Let's change the comparisons. VFX compiles 1M lines
> of Forth source code in about 40 seconds on an i7. How long
> does gcc take at -O2 ? Heavens to Murgatroyd, if you stay with
> C, you'll never get any work done! And you have surrendered
> your Open Source soul to Intel and AMD!
>
> Teasing aside, there are reasons for the differences. If I
> spent as much time and effort on VFX as has been spent on gcc,
> I'm sure I could get similar results. A more productive
> focus is to ask what Forth is good for and to understand the
> design decisions in the compilers for Forth and C.
>
> So, where do I get benefit from Forth? From the use of an
> interactive, extensible language. I spent some of Wednesday
> listening to a presentation about the debug tools needed for
> gdb. I was appalled by the technology required when you use
> the wrong approach to debugging.
>
> But thanks for retriggering the code generation competition.
> I now have work to do ...
>
> Stephen
>
> --
> Stephen Pelc, stephen...@mpeforth.com
> MicroProcessor Engineering Ltd - More Real, Less Time
> 133 Hill Lane, Southampton SO15 5AF, England
> tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
> web:http://www.mpeforth.com- free VFX Forth downloads- Hide quoted text -
>
> - Show quoted text -

Introduce the concept of registers into the Forth language.

Seriously. Where stack juggling becomes an issue, registers are the
antidote. It would often pay off to spend some time getting data from
the stack into registers, performing the work with the registers, and
populating the stack again. Problem solved.

For example, what if the memcpy routine could be written in Forth like
this:

: memcpy ( src dst cnt --)
  ->R0  \ count to R0
  ->R1  \ dst to R1
  ->R2  \ src to r2
  BEGIN
    (R2+)->(R0+) \ copy source to destination with post increment
    R0-- \ decrement count
    R0-> \ push count to stack
  UNTIL
;

It's not machine code. But it looks like it. It's Forth. The point is,
the stack isn't used until the end where the count is placed on the
stack as a parameter to UNTIL.

I think it's neat. This wouldn't be a good idea on native
(registerless) Forth CPUs however. I admit that. Just build DMA in and
you don't need a memcpy ;-)

However, this discussion raises an interesting point. Most Forth
programmers would have the ability to drop into assembler and simply
write something in machine code if they needed to - if they thought
the stack was a bottleneck in a particular routine, for example. Most
C programmers wouldn't know how to do that. I make that statement,
because I just asked an office of 9 software engineers (who code C
(not C++) day in day out) if they could write memcpy in assembler for
PC104 stacks that we use. They all said they wouldn't know how to do
it, but then they all pointed out that they wouldn't have to - there
are library calls in QNX to do it all for you!

"Oooooooooohhhhhhhh!" I said. "That's okay then, forget I asked" :-)

*THAT* is the difference between C and Forth. The difference is
between the chair and the keyboard, in the caliber of the programmer.

That's not to say all C programmers fit into that category, of course.

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

#12269

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2012-05-18 06:10 -0500
Message-ID	<T9WdnScsyZeqsyvSnZ2dnUVZ_oKdnZ2d@supernews.com>
In reply to	#12268

Mark Wills <markrobertwills@yahoo.co.uk> wrote:
> 
> Introduce the concept of registers into the Forth language.

What on Earth for?  Just use locals.  Put locals in registers.

> Seriously. Where stack juggling becomes an issue, registers are the
> antidote. It would often pay off to spend some time getting data from
> the stack into registers, performing the work with the registers, and
> populating the stack again. Problem solved.
> 
> For example, what if the memcpy routine could be written in Forth like
> this:
> 
> : memcpy ( src dst cnt --)
>  ->R0  \ count to R0
>  ->R1  \ dst to R1
>  ->R2  \ src to r2
>  BEGIN
>    (R2+)->(R0+) \ copy source to destination with post increment
>    R0-- \ decrement count
>    R0-> \ push count to stack
>  UNTIL
> ;
> 
> It's not machine code.

Yes it is!  Why wouldn't

: memcopy { s d n}
  begin
    s c@ d c!
    1 +to s  1 +to d
    -1 +to n
  n 0= until ;

generate the same code?  No reason I can see.

Andrew.

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

#12274

From	"Rod Pemberton" <do_not_have@notemailntt.cmm>
Date	2012-05-18 08:10 -0400
Message-ID	<jp5e5s$n5s$1@speranza.aioe.org>
In reply to	#12268

"Mark Wills" <markrobertwills@yahoo.co.uk> wrote in message
news:f0902853-ea0e-4891-9240-366ee2902b8f@d17g2000vbv.googlegroups.com...
...

> Introduce the concept of registers into the Forth language.
>
> Seriously. Where stack juggling becomes an issue, registers are the
> antidote. It would often pay off to spend some time getting data from
> the stack into registers, performing the work with the registers, and
> populating the stack again. Problem solved.

How do you keep track of which register is in use?  Is it entirely up to the
programmer to remember, just like with items on the data stack?  Do you
require they be "empty" upon exiting a high-level word?  C compilers use a
register allocator to keep track.

> However, this discussion raises an interesting point. Most Forth
> programmers would have the ability to drop into assembler and simply
> write something in machine code if they needed to - if they thought
> the stack was a bottleneck in a particular routine, for example. Most
> C programmers wouldn't know how to do that.

I'm not sure why you'd say that about C programmers.  Even the oldest,
simplest C compilers have inline assembly.

> I make that statement, because I just asked an office of 9 software
> engineers (who code C (not C++) day in day out) if they could write
> memcpy in assembler for PC104 stacks that we use. They all said they
> wouldn't know how to do it, but then they all pointed out that they
> wouldn't have to - there are library calls in QNX to do it all for you!

From your description, I'd take it they were saying they didn't know enough
about "PC104" to implement stacks in assembly, not that they didn't know to
implement a stack in assembly.

> *THAT* is the difference between C and Forth. The difference is
> between the chair and the keyboard, in the caliber of the programmer.

They probably didn't understand why you'd want memcpy to be written in
assembler instead of C.  First, C has a stack built in.  Second, in general,
it's a few lines of C which map almost directly to assembly and which
generally optimize well.


Rod Pemberton

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

#12277

From	Mark Wills <forthfreak@gmail.com>
Date	2012-05-18 05:57 -0700
Message-ID	<e3bdcf3c-21be-48d0-a0e0-df3aad36c12f@f30g2000vbz.googlegroups.com>
In reply to	#12274

On May 18, 1:10 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
wrote:

>
> How do you keep track of which register is in use?  Is it entirely up to the
> programmer to remember, just like with items on the data stack?  Do you
> require they be "empty" upon exiting a high-level word?  C compilers use a
> register allocator to keep track.
>

What difference does that make? "Keeping track" of a register is no
harder than "keeping track" of a local variable!

A PC104 is an embedded computer. The boards are stacked, one on top of
the other. I wasn't referring to Forth stacks in my earlier post!

https://en.wikipedia.org/wiki/PC/104

A quick coffee machine chat this AM reveals that in-line assembly (or,
in fact, any assembly) is not allowed. It contravenes the company
coding standards, written in conjunction with Lloyds. I wasn't aware
of that.

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

#12289

From	"Elizabeth D. Rather" <erather@forth.com>
Date	2012-05-18 08:14 -1000
Message-ID	<gKidnd56ReHqDCvSnZ2dnUVZ_vidnZ2d@supernews.com>
In reply to	#12277

On 5/18/12 2:57 AM, Mark Wills wrote:
> On May 18, 1:10 pm, "Rod Pemberton"<do_not_h...@notemailntt.cmm>
> wrote:
>
>>
>> How do you keep track of which register is in use?  Is it entirely up to the
>> programmer to remember, just like with items on the data stack?  Do you
>> require they be "empty" upon exiting a high-level word?  C compilers use a
>> register allocator to keep track.
>>
>
>
> What difference does that make? "Keeping track" of a register is no
> harder than "keeping track" of a local variable!

If you're talking about using real registers you have not only the 
problem of machine dependence (which, of course, you do with assembler), 
but also the fact that many if not most Forths use registers internally 
in specific ways (e.g. as stack pointers) and have rules about stack 
usage for user code.

If you're talking about locals pretending to be registers, just use locals.

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]

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

csiph-web

I beleive that forth could supplant ruby and perl and python if it wanted to

Contents

#12248

#12262

#12265

#12272

#12275

#12288

#12239

#12251

#12260

#12303

#12241

#12242

#12264

#12266

#12280

#12268

#12269

#12274

#12277

#12289