Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #12206 > unrolled thread
| 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 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2012-05-22 09:04 -0700 |
| Subject | Re: VFX code quality |
| Message-ID | <1bc37263-eca3-4388-a570-8a984443aa29@em1g2000vbb.googlegroups.com> |
| In reply to | #12379 |
On May 22, 8:06 am, David Kuehling <dvdkh...@gmx.de> wrote:
> >>>>> "Paul" == Paul Rubin <no.em...@nospam.invalid> writes:
> > "Elizabeth D. Rather" <erat...@forth.com> writes:
> >>> : z* ( a b c d -- ac-bd bc+ad ) .... ;
>
> >> I don't understand your stack comment (I'm no mathematician)
> > ac-bd just means a*c minus b*d. So the word takes 4 parameters
> > a,b,c,d representing the two complex numbers a+bi and c+di. It
> > multiplies them leaving the single complex number (ac-bd) + i*(bc+ad),
> > as two coefficients on the stack. It's trivial with locals:
> > : z* { a b c d -- x y } a c * b d * - b c * a d * + ;
> > doing it without locals seems quite inconvenient. I think Chuck might
> > have used globals.
>
> Well not too inconvenient, this is what I came up some time ago:
>
> : z* ( n1 n2 n3 n4 -- n5 n6 )
> 2OVER 2OVER
> -ROT r* -ROT r* r+ >R ( imag )
> ROT r* >R r* R> r- ( real )
> R> ;
>
> this is for single-cell entities. Of course with floats you can't use>R R> which would screw you.
Yes, if X@ X! Y@ Y! are for integral coordinates, you'd need FX@ FX!
FY@ FY! for something along the lines of:
: Fac-bd ( F: a b | d=X c=Y -- ac-bd ) FX@ F* FNEGATE FSWAP FY@ F* F
+ ;
: Fbc+ad ( F: a b | d=X c=Y -- bc+ad ) FY@ F* FSWAP FX@ F* F+ ;
: z* ( F: a b c d -- ac-bd bc+ad ) FX! FY! FOVER FOVER Fac-bd FROT
FROT Fbc+ad ;
[toc] | [prev] | [next] | [standalone]
| From | "A. K." <akk@nospam.org> |
|---|---|
| Date | 2012-05-21 09:55 +0200 |
| Subject | Re: VFX code quality |
| Message-ID | <4fb9f4e3$0$6566$9b4e6d93@newsspool4.arcor-online.net> |
| In reply to | #12326 |
On 21.05.2012 05:38, Paul Rubin wrote: > "Elizabeth D. Rather"<erather@forth.com> writes: >> We rarely use variables for a truly "temporary" result, that's what >> the data stack is for. User variables are allocated and managed >> conservatively. > > Here's a simple arithmetic problem (multiplying complex numbers) > that I remember having trouble with: > > : z* ( a b c d -- ac-bd bc+ad ) > .... ; > > I found it pretty complicated to do that without some form of temp > variables, even worse if all the data (args and return values) are > floating point numbers rather than ints. Any advice? Sometimes I use "my poor man's locals" with three fast&simple but non-standard words RP@ and RP! (get/set rstack depth) and RPICK (like PICK but from the rstack) Then it's just: : Z* 2>r 2>r 2>r 2>r rp@ >r \ note rstack elements ... \ do your arithmetics by rpicking r@ rp! ;
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-05-21 01:22 -0700 |
| Subject | Re: VFX code quality |
| Message-ID | <7xtxzac5a3.fsf@ruckus.brouhaha.com> |
| In reply to | #12331 |
"A. K." <akk@nospam.org> writes: > Sometimes I use "my poor man's locals" with three fast&simple but > non-standard words > RP@ and RP! (get/set rstack depth) > and RPICK (like PICK but from the rstack) I see, then the R stack is used as an array. > Then it's just: > : Z* > 2>r 2>r 2>r 2>r rp@ >r \ note rstack elements > ... \ do your arithmetics by rpicking > r@ rp! ; It looks neat, but what are you using rp@ and rp! for here?
[toc] | [prev] | [next] | [standalone]
| From | "A. K." <akk@nospam.org> |
|---|---|
| Date | 2012-05-21 14:19 +0200 |
| Subject | Re: VFX code quality |
| Message-ID | <4fba32c5$0$6558$9b4e6d93@newsspool4.arcor-online.net> |
| In reply to | #12332 |
On 21.05.2012 10:22, Paul Rubin wrote: > "A. K."<akk@nospam.org> writes: >> Sometimes I use "my poor man's locals" with three fast&simple but >> non-standard words >> RP@ and RP! (get/set rstack depth) >> and RPICK (like PICK but from the rstack) > > I see, then the R stack is used as an array. > >> Then it's just: >> : Z* >> 2>r 2>r 2>r 2>r rp@ >r \ note rstack elements >> ... \ do your arithmetics by rpicking >> r@ rp! ; > > It looks neat, but what are you using rp@ and rp! for here? Sorry, I didn't have my coffee this morning... ;) ... and without thinking mixed 2 different implementations to nonsense. It's rather : Z* 2>r 2>r 2>r 2>r \ re-imag complex pairs ... \ do your arithmetics by rpicking 8 radjust ; (radjust: cells rp@ + rp! --- depending on how rp@/rp! are implemented)
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-05-22 12:33 -0700 |
| Subject | Re: VFX code quality |
| Message-ID | <7xr4uc9fk7.fsf@ruckus.brouhaha.com> |
| In reply to | #12342 |
"A. K." <akk@nospam.org> writes: > It's rather> > : Z* > 2>r 2>r 2>r 2>r \ re-imag complex pairs > ... \ do your arithmetics by rpicking > 8 radjust ; > (radjust: cells rp@ + rp! --- depending on how rp@/rp! are implemented) I see. Of course you could use regular PICK instead. The advantage of rpick is that the return stack presumably doesn't change as often inside the word, so you don't need to track the moving stack offsets as much. But depending on style, it can still change sometimes. Maybe the next step is to have the interpreter assign a register as a frame pointer, and offset from that. It begins to sound sort of like re-inventing C ;-).
[toc] | [prev] | [next] | [standalone]
| From | "A. K." <akk@nospam.org> |
|---|---|
| Date | 2012-05-22 23:14 +0200 |
| Subject | Re: VFX code quality |
| Message-ID | <4fbc0187$0$6584$9b4e6d93@newsspool3.arcor-online.net> |
| In reply to | #12391 |
On 22.05.2012 21:33, Paul Rubin wrote: > "A. K."<akk@nospam.org> writes: >> It's rather> >> : Z* >> 2>r 2>r 2>r 2>r \ re-imag complex pairs >> ... \ do your arithmetics by rpicking >> 8 radjust ; >> (radjust: cells rp@ + rp! --- depending on how rp@/rp! are implemented) > > I see. Of course you could use regular PICK instead. The advantage of > rpick is that the return stack presumably doesn't change as often inside > the word, so you don't need to track the moving stack offsets as much. > But depending on style, it can still change sometimes. Maybe the next > step is to have the interpreter assign a register as a frame pointer, > and offset from that. It begins to sound sort of like re-inventing C ;-). :-) I _really_ don't care, it just works fine 90 %.
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2012-05-21 20:31 +0200 |
| Subject | Re: VFX code quality |
| Message-ID | <78041514988435@frunobulax.edu> |
| In reply to | #12326 |
Paul Rubin <no.email@nospam.invalid> writes Re: VFX code quality
[..]
> Standard Forth has PICK but no obvious (maybe I'm missing something)
> O(1) way to write to an arbitrary location in the stack.
Interesting, that would be a game-changer!
: z* ( a b c d -- ac-bd bc+ad )
params| a b c d | a c * b d * - b c * a d * + ;
: 0pick dup ;
: 1pick over ;
: 2pick 2>r dup 2r> rot ;
: 3pick 2>r over 2r> rot ;
: b+cpick >r 2dup r> -rot ;
: a+dpick 3pick 1pick ;
: a+cpick 3pick 2pick ;
: a+bpick 2over ;
: b+dpick dup 3pick swap ;
: c+dpick 2dup ;
: z* ( a b c d -- ac-bd ad+bc )
a+dpick * >r b+cpick * r> + >r
b+dpick * >r a+cpick * r> - >r 4drop 2r> ;
$01248F80 : [trashed]
$01248F8A pop rbx
$01248F8B pop rdi
$01248F8C pop rax
$01248F8D pop rdx
$01248F8E mov r9, rdx
$01248F91 imul r9, rbx
$01248F95 mov r10, rax
$01248F98 imul r10, rdi
$01248F9C mov r11, rax
$01248F9F imul r11, rbx
$01248FA3 mov r12, rdx
$01248FA6 imul r12, rdi
$01248FAA sub r12, r11
$01248FAD lea rbx, [r10 r9*1 ] qword
$01248FB1 push rbx
$01248FB2 push r12
$01248FB4 ;
It takes some getting used to, but it is obviously a huge improvement
in readability and code quality now these pesky locals are gone.
-marcel
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-05-21 15:17 -0500 |
| Subject | Re: VFX code quality |
| Message-ID | <dpudnaWjPIdfPyfSnZ2dnUVZ_vKdnZ2d@supernews.com> |
| In reply to | #12350 |
Marcel Hendrix <mhx@iae.nl> wrote: > Paul Rubin <no.email@nospam.invalid> writes Re: VFX code quality > [..] >> Standard Forth has PICK but no obvious (maybe I'm missing something) >> O(1) way to write to an arbitrary location in the stack. > > Interesting, that would be a game-changer! > > : z* ( a b c d -- ac-bd bc+ad ) > params| a b c d | a c * b d * - b c * a d * + ; > > : 0pick dup ; > : 1pick over ; > : 2pick 2>r dup 2r> rot ; > : 3pick 2>r over 2r> rot ; > > : b+cpick >r 2dup r> -rot ; > : a+dpick 3pick 1pick ; > : a+cpick 3pick 2pick ; > : a+bpick 2over ; > : b+dpick dup 3pick swap ; > : c+dpick 2dup ; > > : z* ( a b c d -- ac-bd ad+bc ) > a+dpick * >r b+cpick * r> + >r > b+dpick * >r a+cpick * r> - >r 4drop 2r> ; Agh! My eyes are bleeding. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2012-05-21 13:50 -0700 |
| Subject | Re: VFX code quality |
| Message-ID | <7b5a13d2-df8b-4711-b8fc-fda32a41c0b0@n5g2000pbg.googlegroups.com> |
| In reply to | #12350 |
On May 21, 2:31 pm, m...@iae.nl (Marcel Hendrix) wrote:
> Paul Rubin <no.em...@nospam.invalid> writes Re: VFX code quality
> [..]
>
>> Standard Forth has PICK but no obvious (maybe I'm missing
>> something) O(1) way to write to an arbitrary location in the
>> stack.
> Interesting, that would be a game-changer!
> : z* ( a b c d -- ac-bd bc+ad )
> params| a b c d | a c * b d * - b c * a d * + ;
> : 0pick dup ;
> : 1pick over ;
> : 2pick 2>r dup 2r> rot ;
> : 3pick 2>r over 2r> rot ;
> : b+cpick >r 2dup r> -rot ;
> : a+dpick 3pick 1pick ;
> : a+cpick 3pick 2pick ;
> : a+bpick 2over ;
> : b+dpick dup 3pick swap ;
> : c+dpick 2dup ;
> : z* ( a b c d -- ac-bd ad+bc )
> a+dpick * >r b+cpick * r> + >r
> b+dpick * >r a+cpick * r> - >r 4drop 2r> ;
> It takes some getting used to, but it is obviously a huge
> improvement in readability and code quality now these pesky
> locals are gone.
That is compared to both
: z* { a b c d -- ac-bd ad+bd }
a c * b d * - a d * b d * + ;
and to ...
: 4DUP ( x1 x2 x3 x4 -- x1 x2 x3 x4 x1 x2 x3 x4 ) 2OVER 2OVER ;
: ac-bd ( a b c d -- ac-bd ) ROT * NEGATE -ROT * + ;
: ad+bd ( a b c d -- ad+bd ) NIP TUCK * -ROT * + ;
: z* a b c d -- ac-bd ad+bd ) 4DUP ab+bd >R ac-bd R> ;
... yeah, sure.
[toc] | [prev] | [next] | [standalone]
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2012-05-21 16:47 -0700 |
| Subject | Re: VFX code quality |
| Message-ID | <120c3ef4-3abc-4bc2-9f3a-c3bf99ca0011@ra8g2000pbc.googlegroups.com> |
| In reply to | #12360 |
On May 21, 4:50 pm, BruceMcF <agil...@netscape.net> wrote: > : 4DUP ( x1 x2 x3 x4 -- x1 x2 x3 x4 x1 x2 x3 x4 ) 2OVER 2OVER ; > : ac-bd ( a b c d -- ac-bd ) ROT * NEGATE -ROT * + ; > : ad+bd ( a b c d -- ad+bd ) NIP TUCK * -ROT * + ; > > : z* a b c d -- ac-bd ad+bd ) 4DUP ab+bd >R ac-bd R> ; : z* a b c d -- ac-bd ad+bd ) 4DUP ad+bd >R ac-bd R> ;
[toc] | [prev] | [next] | [standalone]
| From | "Harry Vaderchi" <admin@127.0.0.1> |
|---|---|
| Date | 2012-05-22 09:57 +0100 |
| Subject | Re: VFX code quality |
| Message-ID | <op.wepchfwy1r0rdn@dell3100> |
| In reply to | #12362 |
On Tue, 22 May 2012 00:47:12 +0100, BruceMcF <agila61@netscape.net> wrote: > On May 21, 4:50 pm, BruceMcF <agil...@netscape.net> wrote: > >> : 4DUP ( x1 x2 x3 x4 -- x1 x2 x3 x4 x1 x2 x3 x4 ) 2OVER 2OVER ; >> : ac-bd ( a b c d -- ac-bd ) ROT * NEGATE -ROT * + ; >> : ad+bd ( a b c d -- ad+bd ) NIP TUCK * -ROT * + ; >> >> : z* a b c d -- ac-bd ad+bd ) 4DUP ab+bd >R ac-bd R> ; > > : z* a b c d -- ac-bd ad+bd ) 4DUP ad+bd >R ac-bd R> ; I think you want ac-bd and ad+bc that last one is bc not bd. -- [dash dash space newline 4line sig] Albi CNU
[toc] | [prev] | [next] | [standalone]
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2012-05-22 04:39 -0700 |
| Subject | Re: VFX code quality |
| Message-ID | <cffbaad7-0b70-43f5-b18b-0f9087868735@t23g2000yqj.googlegroups.com> |
| In reply to | #12370 |
On May 22, 4:57 am, "Harry Vaderchi" <ad...@127.0.0.1> wrote: > On Tue, 22 May 2012 00:47:12 +0100, BruceMcF <agil...@netscape.net> wrote: > > On May 21, 4:50 pm, BruceMcF <agil...@netscape.net> wrote: > > >> : 4DUP ( x1 x2 x3 x4 -- x1 x2 x3 x4 x1 x2 x3 x4 ) 2OVER 2OVER ; > >> : ac-bd ( a b c d -- ac-bd ) ROT * NEGATE -ROT * + ; > >> : ad+bd ( a b c d -- ad+bd ) NIP TUCK * -ROT * + ; > > >> : z* a b c d -- ac-bd ad+bd ) 4DUP ab+bd >R ac-bd R> ; > > > : z* a b c d -- ac-bd ad+bd ) 4DUP ad+bd >R ac-bd R> ; > > I think you want ac-bd and ad+bc > that last one is bc not bd. I thought I had copied and pasted that stack comment ~ it looked weird to me that the four operands were not used. : ac-bd ( a b c d -- ac-bd ) ROT * NEGATE -ROT * + ; : ad+bc ( a b c d -- ad+bc ) -ROT * -ROT * + ; : z* ( a b c d -- ac-bd ad+bc ) 4DUP ab+bc >R ac-bd R> ; As far as the global scratch variables approach: : ac-bd ( a b | x=d y=c -- ac-bd ) X@ * NEGATE SWAP Y@ * + ; : ad+bc ( a b | x=d y=c -- ad+bc ) Y@ * SWAP X@ * + ; : z* ( a b c d -- ac-bd ad+bc ) X! Y! 2DUP ad+bc >R ac-bd R> ;
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2012-05-23 20:25 +0200 |
| Subject | Re: VFX code quality |
| Message-ID | <56101512988435@frunobulax.edu> |
| In reply to | #12378 |
BruceMcF <agila61@netscape.net> writes Re: VFX code quality
>>> On Tue, 22 May 2012 00:47:12 +0100, BruceMcF <agil...@netscape.net> wrote=
[..]
>> : ac-bd ( a b c d -- ac-bd ) ROT * NEGATE -ROT * + ;
>> : ad+bc ( a b c d -- ad+bc ) -ROT * -ROT * + ;
>> : z* ( a b c d -- ac-bd ad+bc ) 4DUP ad+bc >R ac-bd R> ;
> I thought I had copied and pasted that stack comment ~ it looked weird
> to me that the four operands were not used.
FORTH> ' z* idis
$01248B80 : [trashed]
$01248B8A pop rbx
$01248B8B pop rdi
$01248B8C pop rax
$01248B8D pop rdx
$01248B8E mov r9, rax
$01248B91 imul r9, rdi
$01248B95 mov r10, rdx
$01248B98 imul r10, rbx
$01248B9C imul rbx, rax
$01248BA0 neg rbx
$01248BA3 imul rdx, rdi
$01248BA7 lea rbx, [rbx rdx*1] qword
$01248BAB push rbx
$01248BAC lea rbx, [r9 r10*1] qword
$01248BB0 push rbx
$01248BB1 ;
> As far as the global scratch variables approach:
0 VALUE x : X@ x ; : X! TO x ;
0 VALUE y : Y@ y ; : Y! TO y ;
> : ac-bd ( a b | x=d y=c -- ac-bd ) X@ * NEGATE SWAP Y@ * + ;
> : ad+bc ( a b | x=d y=c -- ad+bc ) Y@ * SWAP X@ * + ;
> : z* ( a b c d -- ac-bd ad+bc ) X! Y! 2DUP ad+bc >R ac-bd R> ;
FORTH> ' z* idis
$0124C680 : [trashed]
$0124C68A pop rbx
$0124C68B mov $01016000 qword-offset, rbx
$0124C692 pop rbx
$0124C693 mov $01016008 qword-offset, rbx
$0124C69A pop rbx
$0124C69B pop rdi
$0124C69C mov rax, rbx
$0124C69F imul rax, $01016008 qword-offset
$0124C6A7 mov rdx, rdi
$0124C6AA imul rdx, $01016000 qword-offset
$0124C6B2 imul rbx, $01016000 qword-offset
$0124C6BA neg rbx
$0124C6BD imul rdi, $01016008 qword-offset
$0124C6C5 lea rbx, [rbx rdi*1] qword
$0124C6C9 push rbx
$0124C6CA lea rbx, [rax rdx*1] qword
$0124C6CE push rbx
$0124C6CF ;
I doubt it makes a significant difference either way.
One other optimization trick would be to 'remember' memory variables
in spare registers.
-marcel
[toc] | [prev] | [next] | [standalone]
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2012-05-23 13:47 -0700 |
| Subject | Re: VFX code quality |
| Message-ID | <277a1560-a0eb-4cc3-9643-a5c95916ab22@e9g2000pbh.googlegroups.com> |
| In reply to | #12407 |
On May 23, 2:25 pm, m...@iae.nl (Marcel Hendrix) wrote:
> One other optimization trick would be to 'remember' memory variables
> in spare registers.
Yes, before the days of optimizing compilers, that's why the global
variables are X@ X! Y@ Y! Z@ Z! so that if you have spare registers,
you allocate them to X, Y, and Z (in that order) and the balance are
in memory. Back in the old days, the primitives on a 6502 with would
be:
XFETCH:
LDA XREG+1
PHA
LDA XREG
PHA
JMP NEXT
... with XREG in the byte-addressed zero page in a system with free
zero page space, and out in regular word-addressed memory in a system
with no zero space to spare.
(The same would apply to FX@ FX! FY@ FY! FZ@ FZ! if you have spare
floating point registers.)
Then @X !X etc. would be:
FETCHX:
LDY #1
LDA (XREG),Y
PHA
DEY
LDA (XREG),Y
PHA
JMP NEXT
FETCHY:
LDY #1
LDA (YREG),Y
PHA
DEY
LDA (YREG),Y
PHA
JMP NEXT
... on the fortunate system with sufficient zero-page space and:
FETCHX:
LDA XREG
STA W
LDA XREG+1
STA W+1
JMP FETCHW
...
FETCHY:
LDA YREG
STA W
LDA YREG+1
STA W+1
JMP FETCHW
...
FETCHW:
LDY #1
LDA (W),Y
PHA
DEY
LDA (W),Y
PHA
JMP NEXT
... on the system where XREG is elsewhere in memory.
I'd assume that the similar difference in speed would apply to X in
register and in memory, just a lot shorter primitives, for a system,
say, with a spare register for X but with Y in regular memory.
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2012-05-21 20:23 +0000 |
| Subject | Re: VFX code quality |
| Message-ID | <jpe875$8qu$1@dont-email.me> |
| In reply to | #12326 |
On Sun, 20 May 2012 20:38:47 -0700, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> We rarely use variables for a truly "temporary" result, that's what the >> data stack is for. User variables are allocated and managed >> conservatively. > > Here's a simple arithmetic problem (multiplying complex numbers) that I > remember having trouble with: > > : z* ( a b c d -- ac-bd bc+ad ) > .... ; > > I found it pretty complicated to do that without some form of temp > variables, even worse if all the data (args and return values) are > floating point numbers rather than ints. Any advice? Hi! A possible one using dictionary as temporary storage: 8<--- : -f.allot [ -1 floats ] literal allot ; : *re ( F: a b c d -- ac-bd ) fswap here f, f* fswap f@ f* fswap f- -f.allot ; : *im ( F: a b c d -- ad+bc ) here f, f* fswap f@ f* f+ -f.allot ; : -4f.allot [ -4 floats ] literal allot ; : float- ( F: a -- a-floats ) [ -1 floats ] literal + ; : f@- ( a -- a-float ; F: -- x ) dup f@ float- ; : z* ( F: a b c d -- ac-bd ad+bc ) f, f, f, f, here float- f@- f@- f@- f@- *re [ 4 floats ] literal + f@- f@- f@- f@- *im drop -4f.allot ; --->8 Have a nice day, humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2012-05-20 20:22 -0700 |
| Subject | Re: VFX code quality |
| Message-ID | <1c776e7c-4d94-46c7-a631-04e398dc9278@w13g2000vbc.googlegroups.com> |
| In reply to | #12323 |
On May 20, 10:10 pm, Paul Rubin <no.em...@nospam.invalid> wrote: > One reason C code is more likely to > keep stuff on the stack is that it considers the stack to be randomly > addressible, while Forth traditionally avoids PICK. Though if you want a randomly accessible stack, you can always build one. > A Forth program would probably use globals for > that stuff. The C++ code puts it on the stack since it considers the > stack to be randomly addressible. Or globals or dedicated stack pads holding the addresses of structures. If those are created and consumed on the fly, they'd often be allocated and returned to the heap, either individually or in a structure pool.
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2012-05-21 10:57 +0000 |
| Subject | Re: VFX code quality |
| Message-ID | <m4dd38.mmq@spenarnc.xs4all.nl> |
| In reply to | #12323 |
In article <7x8vgmffmz.fsf@ruckus.brouhaha.com>, Paul Rubin <no.email@nospam.invalid> wrote: >"Elizabeth D. Rather" <erather@forth.com> writes: >> In the first place, "re-entrancy" is only an issue in the presence of >> multiple tasks. For people using single-threaded Forths, it isn't an >> issue at all. > >If you're doing anything at interrupt level, that counts as >multitasking, and re-entrancy matters. And these days, it seems like >almost every program I deal with is multi-threaded (maybe that's just >me). Single-threading seems like a 20th-century thing. Within a thread you're single threading. So you're wrong. Re-entrancy matters for library functions. not for thread specific functions. Normal library functions (D.R) CMOVE or TYPE can be called from other Forth instances. The bottom line is that we just keep track of what to share and what not ourselves. > >> Variables that might have re-entrancy issues or which tasks need >> private copies are defined as "user variables" (every task has a >> private copy). > >In this case you're burning memory unnecessarily, if you're using a >variable for some temporary result, and you have a copy in every task >when it's if variable will be never active in more than one or two tasks >simultaneously. The usual approach is to put the variable on the stack. But we do that all the time! A variable not on the stack is rare. > >> ALLOT yes, FORGET almost never. Given that Forth is extremely >> parsimonious with memory, it's rarely necessary to worry about >> temporarily allocating space. Temporary arrays can go in the >> unallocated space at PAD, and ALLOCATE/FREE is useful >> sometimes. Programmers coming from other languages tend to worry a lot >> more about releasing space than Forth programmers. > >I hope that doesn't mean you're programming in a way that simply leaks >space. Also, ALLOCATE is even clumsier than ALLOT compared to >straightforward stack allocation. > >>> this keeps going so that when you get further down the call chain, there >>> is quite a bit less stuff on the data stack. > >> Except when we're having to call C (or other language) routines, Forth >> programs don't use very much stack space. We have done studies on a >> few large applications and found that they rarely get more than 8-10 >> elements deep. > >Yes, partly a matter of calling conventions, partly a matter of coding >style, and probably partly a matter of what the applications do (Forth >applications are simply less likely to be the kinds of applications that >munch on large volumes of data). One reason C code is more likely to >keep stuff on the stack is that it considers the stack to be randomly >addressible, while Forth traditionally avoids PICK. > >Right now I'm messing with some C++ code that crunches XML documents >that can be megabytes in size (they are usually smaller), extracting >different fields and computing stuff. So there have to be a few dozen >variables active (across multiple call frames), keeping track of what's >in the different input buffers, copying stuff out of fields for >processing, and so on. A Forth program would probably use globals for >that stuff. The C++ code puts it on the stack since it considers the >stack to be randomly addressible. That would be a good benchmark: to compare that written in Forth. Groetjes Albert -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-05-21 01:35 +0200 |
| Subject | Re: VFX code quality |
| Message-ID | <jpbv49$p3u$1@online.de> |
| In reply to | #12313 |
Andrew Haley wrote: > Well, not necessarily. If locals are a super-efficient way of using > registers in colon definitions, then they're an easy way to write > fiddly low-level words that use multiple operands, maybe as good as > dropping into asm. That's a nice thing, isn't it? How many of those fiddly low-level words do you write? I've just finished writing the code for our (Forth Gesellschaft) LinuxTag eye- catcher (a new version of our Triceps robot), and for reliability reasons, it will run on the b16 FPGA board. So no locals, no assembler to drop down to, just 16 stack elements deep, and as usual, the program size should not exceed 2k by much. The new triceps has much more demanding trigonometry than the old one. I actually profit from placing intermediate results into global variables, because they are easy to inspect by the debugger (b16 is a Forth processor, but its Forth is just an assembler, i.e. edit-upload- run style programming. Uploading is quick, so no real problem). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2012-05-20 22:44 -0700 |
| Subject | Re: VFX code quality |
| Message-ID | <f66b6a3c-a55b-47ae-a238-464d4ab1ba1d@pr7g2000pbb.googlegroups.com> |
| In reply to | #12313 |
On May 20, 10:49 am, Andrew Haley <andre...@littlepinkcloud.invalid> wrote: > Bernd Paysan <bernd.pay...@gmx.de> wrote: > > Stephen Pelc wrote: > >> If we get better handling of the third and fourth items on > >> the Forth data stack (even if we have to invent some notation), > >> then the need for locals is reduced. Some systems already have > >> words such as THIRD and FOURTH, albeit as macros for x PICK. > > > But they are used rarely (and should so). > > > Locals are used for words where you can't figure out how to reduce the > > stack pressure so that it can be written nicely. Locals in a word are a > > warning label, and my dominant usage of locals is when calling C > > functions. The warning label means "bad factoring, cluttered stack", > > Well, not necessarily. If locals are a super-efficient way of using > registers in colon definitions, then they're an easy way to write > fiddly low-level words that use multiple operands, maybe as good as > dropping into asm. That's a nice thing, isn't it? > > Andrew. Locals are only "a super-efficient way of using registers in colon definitions" if those colon definitions are gigantic. In well-factored Forth though, they tend to be quite small (3 to 4 lines typically, and rarely more than 7 lines). I've seen C programs in which the functions were gigantic --- you had to scroll through them --- they were like mini-programs. In this case, it makes sense to put the locals into registers because they are going to stay there for a long time. In a short Forth colon word, it doesn't necessarily make sense --- you have to save/restore all of those registers with every function call and exit --- if you are only accessing the local once or twice, it would be more efficient to just use a local stack and dispense with all of that save/restore overhead.
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2012-05-20 22:53 -0700 |
| Subject | Re: VFX code quality |
| Message-ID | <8d921fcb-7184-422f-840a-bdf0ea83d8de@ri8g2000pbc.googlegroups.com> |
| In reply to | #12328 |
On May 20, 10:44 pm, Hugh Aguilar <hughaguila...@yahoo.com> wrote: > it would be more efficient to just > use a local stack and dispense with all of that save/restore overhead. For example, the PIC24 accesses a register or a memory address in 1 clock cycle. Unless you are using the register as a pointer to indirectly access memory (which you can't do with a memory variable), then you might as well just access your data in memory.
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web