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 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-05-21 04:32 -0500 |
| Subject | Re: VFX code quality |
| Message-ID | <15OdnUjsqb8nlifSnZ2dnUVZ_qadnZ2d@supernews.com> |
| In reply to | #12328 |
Hugh Aguilar <hughaguilar96@yahoo.com> wrote: > On May 20, 10:49?am, Andrew Haley <andre...@littlepinkcloud.invalid> > wrote: >> >> 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? > > Locals are only "a super-efficient way of using registers in colon > definitions" if those colon definitions are gigantic. Not at all. See the complex multiplication examople upthread. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-05-21 08:44 -1000 |
| Subject | Re: VFX code quality |
| Message-ID | <GJCdnZG0-bO8ECfSnZ2dnUVZ_rqdnZ2d@supernews.com> |
| In reply to | #12337 |
On 5/20/12 11:32 PM, Andrew Haley wrote: > Hugh Aguilar<hughaguilar96@yahoo.com> wrote: ... >> Locals are only "a super-efficient way of using registers in colon >> definitions" if those colon definitions are gigantic. > > Not at all. See the complex multiplication examople upthread. Plus, if a colon definition is "gigantic" it needs to be refactored and rewritten. 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]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-05-20 00:58 -0700 |
| Message-ID | <7xehqfe11i.fsf@ruckus.brouhaha.com> |
| In reply to | #12264 |
stephenXXX@mpeforth.com (Stephen Pelc) writes: > 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. ... VFX compiles 1M > lines of Forth source code in about 40 seconds on an i7. How long does > gcc take at -O2 ? According to http://tinycc.org GCC compiles around 100 KLOC/sec (after cpp expansion) on a 2.4 GHz Pentium 4, and TinyCC is about 9x faster, about 859K LOC/sec. OTOH, the header expansion bloats that test code by about 25x, so in another sense you're looking at around 30 sec for a million lines, same ballpark as VFX. As TinyCC and GCC are batch compilers you can presumably say "make -j8" on a quad-core i7 (8 threads) and get maybe 5x speedup. I'd guess you have a way to do something comparable with VFX. TinyCC generates code that runs maybe 2x slower than GCC optimized code: VFX might do a bit better than that, but perhaps TinyCC is more comparable to VFX than GCC is. TinyCC has around 80 KLOC of source code (in C) though that includes an assembler, linker, cpp, etc. I think you mentioned someplace that VFX was around 6 KLOC, which is impressive. I'm guessing VFX is written in horizontal style, so each line has as much content as several typical C lines, but still, that's pretty small for a serious compiler. I thought http://www.complang.tuwien.ac.at/anton/euroforth/ef00/pelc00a.pdf was pretty interesting, though for reasons understood, it's not very detailed. I wonder if you've got any reading suggestions for general info (not Forth-specific) about how to write this class of code generator (i.e. something fast and simple, that still makes some reasonable global optimization efforts). I read the Dragon book long ago, but it's pretty old by now.
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2012-05-20 15:09 +0000 |
| Message-ID | <4fb8fcfc.458166449@192.168.0.50> |
| In reply to | #12306 |
On Sun, 20 May 2012 00:58:49 -0700, Paul Rubin <no.email@nospam.invalid> wrote: Given that Forth has no preprocessor, the only sensible comparisons will be very approximate and probably consist of real-world applications. >TinyCC has around 80 KLOC of source code (in C) though that includes an >assembler, linker, cpp, etc. I think you mentioned someplace that VFX >was around 6 KLOC, which is impressive. To that you have to add the assembler, which is about 4k lines. The disassembler is not part of the code generation, but you could not develop a code generator without a disassembler, so add another 3k lines. >I'm guessing VFX is written in >horizontal style, so each line has as much content as several typical C >lines, but still, that's pretty small for a serious compiler. Not really, but a lot of defining words. >I thought > > http://www.complang.tuwien.ac.at/anton/euroforth/ef00/pelc00a.pdf > >was pretty interesting, though for reasons understood, it's not very >detailed. I wonder if you've got any reading suggestions for general >info (not Forth-specific) about how to write this class of code >generator (i.e. something fast and simple, that still makes some >reasonable global optimization efforts). I read the Dragon book long >ago, but it's pretty old by now. The project was started about 15 years ago. We read all the compiler books of the time, plus the published Forth papers and code. These days, there's nothing about compiling for Forth that cannot be found in the compiler literature. 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]
| From | "Rod Pemberton" <do_not_have@notemailntt.cmm> |
|---|---|
| Date | 2012-05-18 07:20 -0400 |
| Message-ID | <jp5b8k$f5c$1@speranza.aioe.org> |
| In reply to | #12242 |
<vandys@vsta.org> wrote in message news:a1l87gFvfoU1@mid.individual.net...
> 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?
By feeding different C code to GCC, you can get GCC to produce smaller code
for the body. GCC is superb with optimizations involving constants, but it
is horrid on x86 with variables of a byte in size. It's so-so on
control-flow. The more complicated the flow control, the worse it gets. A
while(1) with an if-break usually optimizes better than a while() with some
condition. Sometimes, it optimizes much better. A for() with conditions is
usually the worst. You can unroll the for() completely and get much better
optimization. Also, sometimes declaring a local scope variable in GCC
- which gets a parameter copied to it - will sometimes allow you to
produce much better code too. GCC generally doesn't emit byte sized
instructions, i.e., emitting eax instead of al, etc. With proper coding,
you can get it to do so. This - byte sized instructions, i.e., 8-bit
registers, e.g., for char - eliminates lots of logical and's of
32-bit/16-bit registers with 0xFF.
Let's repost your original C code:
> void
> memcopy(char *src, char *dest, int count)
> {
> while (count--) {
> *dest++ = *src++;
> }
> }
...
> 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:
>
Well, you've made a mistake there. Apparently, no one else here noticed.
%edi, %esi, and %ebx are not initialized. So, the routine posted is
incomplete. The 3 additional instructions to initialize %ebx, %edi and %esi
are not "procedure call noise", but parameter initialization. "procedure
call noise" is the prolog(ue) and epilog(ue) with %ebp and %esp. However,
I'll continue the same way for my post below...
So, that's 9 instructions, or 12 including parameter initialization.
For reference, since I don't know version of GCC you used, GCC 3.4.1 -O2
produces for your C code above, without "procedure call noise", the
following:
jmp L7
L9:
movb (%ebx), %al
incl %ebx
movb %al, (%ecx)
incl %ecx
L7:
decl %edx
cmpl $-1, %edx
jne L9
At 8 (or 11 with parms), that's one less instruction. There seems to be an
extra check for an initial zero for 'count' generated by the version of GCC
you're using. It also appears the GCC code generator was switched from
'incl' to 'addl' even for non 64-bit code. I'm not sure why your version of
GCC (4.x.x series?) chose to use a signed move byte to long instruction.
It's "slow." (That's not move string in GAS syntax.)
Now, let's take this C code:
void memcpy(char *src, char *dst, int count)
{
int cx=0;
while(1)
{
*(dst+cx)=*(src+cx);
cx++;
if(cx==count)
break;
}
}
Yeah, you'd *never* code that, "right"? (wrong)
For GCC 3.4.1 -O2 it generates, without "procedure call noise":
L11:
movb (%esi,%edx), %al
movb %al, (%ebx,%edx)
incl %edx
cmpl %ecx, %edx
jne L11
That's 5 (or 8 with parms) resulting in 3 fewer instructions for the main
body. I'm not sure about the timings. Unfortunately, the "procedure call
noise" adds two more instructions in this case. I.e., the net is one
less. You shouldn't ignore "procedure call noise".
Unfortunately, in this case, the gain wasn't much. But, I've seen other
cases where the gain was substantial. I may just be a matter of rewriting
it again, a different way.
So, if I had a Forth compiler, I'd try for something like that sequence
above, i.e., 8 instead of 12.
With -O2 this C sequence generates the same assembly sequence. Without it,
IIRC, generally the subscript operator [] adds an additional instruction per
use.
void memcpy(char *src, char *dst, int count)
{
int cx=0;
while(1)
{
dst[cx]=src[cx];
cx++;
if(cx==count)
break;
}
}
HTH,
Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-05-18 10:22 -0500 |
| Message-ID | <oLGdnbOmra7T9CvSnZ2dnUVZ_o6dnZ2d@supernews.com> |
| In reply to | #12270 |
Rod Pemberton <do_not_have@notemailntt.cmm> wrote:
> <vandys@vsta.org> wrote in message news:a1l87gFvfoU1@mid.individual.net...
>> 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?
>
>
> By feeding different C code to GCC, you can get GCC to produce smaller code
> for the body. GCC is superb with optimizations involving constants, but it
> is horrid on x86 with variables of a byte in size. It's so-so on
> control-flow. The more complicated the flow control, the worse it gets. A
> while(1) with an if-break usually optimizes better than a while() with some
> condition. Sometimes, it optimizes much better. A for() with conditions is
> usually the worst. You can unroll the for() completely and get much better
> optimization. Also, sometimes declaring a local scope variable in GCC
> - which gets a parameter copied to it - will sometimes allow you to
> produce much better code too. GCC generally doesn't emit byte sized
> instructions, i.e., emitting eax instead of al, etc. With proper coding,
> you can get it to do so. This - byte sized instructions, i.e., 8-bit
> registers, e.g., for char - eliminates lots of logical and's of
> 32-bit/16-bit registers with 0xFF.
>
>
> Let's repost your original C code:
>
>> void
>> memcopy(char *src, char *dest, int count)
>> {
>> while (count--) {
>> *dest++ = *src++;
>> }
>> }
>
> ...
>
>> 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:
>>
>
> Well, you've made a mistake there. Apparently, no one else here
> noticed.
Everybody noticed. It's the inner loop, which is what matters.
> %edi, %esi, and %ebx are not initialized. So, the routine posted is
> incomplete.
Well, yes.
> For reference, since I don't know version of GCC you used, GCC 3.4.1
3.4.1 ? Ya gotta be kidding! That was seven years ago.
> -O2
> produces for your C code above, without "procedure call noise", the
> following:
>
> jmp L7
> L9:
> movb (%ebx), %al
> incl %ebx
> movb %al, (%ecx)
> incl %ecx
> L7:
> decl %edx
> cmpl $-1, %edx
> jne L9
I get this with 4.6.3:
testl %ecx, %ecx
je .L1
xorl %eax, %eax
.L3:
movzbl (%ebx,%eax), %edx
movb %dl, (%esi,%eax)
addl $1, %eax
cmpl %ecx, %eax
jne .L3
.L1:
I ask you, how would you like it if someone used an ancient version of
your software that you'd done a lot of work on and complained about
its performance? :-)
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailntt.cmm> |
|---|---|
| Date | 2012-05-18 22:09 -0400 |
| Message-ID | <jp6vau$hhs$1@speranza.aioe.org> |
| In reply to | #12284 |
"Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
news:oLGdnbOmra7T9CvSnZ2dnUVZ_o6dnZ2d@supernews.com...
> Rod Pemberton <do_not_have@notemailntt.cmm> wrote:
> > <vandys@vsta.org> wrote in message
news:a1l87gFvfoU1@mid.individual.net...
...
> > Let's repost your original C code:
> >
> >> void
> >> memcopy(char *src, char *dest, int count)
> >> {
> >> while (count--) {
> >> *dest++ = *src++;
> >> }
> >> }
> >
> > ...
> >
> >> 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:
> >>
> >
>
> 3.4.1 ? Ya gotta be kidding! That was seven years ago.
I use GCC via DJGPP. I haven't upgraded in a while. I also have 4.1.0.
Sometimes I have Linux around, sometimes I don't. Right now, I don't.
> > -O2
> > produces for your C code above, without "procedure call noise", the
> > following:
> >
> > jmp L7
> > L9:
> > movb (%ebx), %al
> > incl %ebx
> > movb %al, (%ecx)
> > incl %ecx
> > L7:
> > decl %edx
> > cmpl $-1, %edx
> > jne L9
>
> I get this with 4.6.3:
>
> testl %ecx, %ecx
> je .L1
> xorl %eax, %eax
> .L3:
> movzbl (%ebx,%eax), %edx
> movb %dl, (%esi,%eax)
> addl $1, %eax
> cmpl %ecx, %eax
> jne .L3
> .L1:
>
> I ask you, how would you like it if someone used an ancient version of
> your software that you'd done a lot of work on and complained about
> its performance? :-)
>
GCC is not known for efficient code. I doubt that has changed. E.g., why
the movzbl to %edx when only %dl is used? Why the 'addl' instead of
'incl' in 32-bit code? They need to study a compiler known for better code
generation, e.g., Watcom/OpenWatcom.
Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-05-19 04:20 -0500 |
| Message-ID | <MYGdnZT7e6l4-CrSnZ2dnUVZ_gSdnZ2d@supernews.com> |
| In reply to | #12290 |
Rod Pemberton <do_not_have@notemailntt.cmm> wrote:
> "Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
> news:oLGdnbOmra7T9CvSnZ2dnUVZ_o6dnZ2d@supernews.com...
>> Rod Pemberton <do_not_have@notemailntt.cmm> wrote:
>> > <vandys@vsta.org> wrote in message
> news:a1l87gFvfoU1@mid.individual.net...
> ...
>
>> > Let's repost your original C code:
>> >
>> >> void
>> >> memcopy(char *src, char *dest, int count)
>> >> {
>> >> while (count--) {
>> >> *dest++ = *src++;
>> >> }
>> >> }
>> >
>> > ...
>> >
>> >> 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:
>> >>
>> >
>>
>> 3.4.1 ? Ya gotta be kidding! That was seven years ago.
>
> I use GCC via DJGPP. I haven't upgraded in a while. I also have 4.1.0.
> Sometimes I have Linux around, sometimes I don't. Right now, I don't.
>
>> > -O2
>> > produces for your C code above, without "procedure call noise", the
>> > following:
>> >
>> > jmp L7
>> > L9:
>> > movb (%ebx), %al
>> > incl %ebx
>> > movb %al, (%ecx)
>> > incl %ecx
>> > L7:
>> > decl %edx
>> > cmpl $-1, %edx
>> > jne L9
>>
>> I get this with 4.6.3:
>>
>> testl %ecx, %ecx
>> je .L1
>> xorl %eax, %eax
>> .L3:
>> movzbl (%ebx,%eax), %edx
>> movb %dl, (%esi,%eax)
>> addl $1, %eax
>> cmpl %ecx, %eax
>> jne .L3
>> .L1:
>>
>> I ask you, how would you like it if someone used an ancient version of
>> your software that you'd done a lot of work on and complained about
>> its performance? :-)
>
> GCC is not known for efficient code.
Known by whom? People who use seven-year-old compilers?
> I doubt that has changed. E.g., why the movzbl to %edx when only
> %dl is used? Why the 'addl' instead of 'incl' in 32-bit code?
Instruction choice depends on the processor in use. If you compile
this for a 486 you get
je .L1
xorl %eax, %eax
.L3:
movb (%ebx,%eax), %dl
movb %dl, (%esi,%eax)
incl %eax
cmpl %ecx, %eax
jne .L3
.L1:
It's not just a matter of instruction length: some instructions pair
in the pipelines better than others. GCC has a model of the processor
that is used to drive the choice of instructions.
> They need to study a compiler known for better code generation,
> e.g., Watcom/OpenWatcom.
I note that you evaded my question. How would you like it? ("They"
includes me, BTW.) Of course, GCC isn't perfect, and work goes on
improving performance. There are examples of suboptimal code, but
this is not one of them.
And finally, if you really want good performance for his loop, you
unroll it. GCC will of course do that, but it's too long to include
here.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2012-05-19 13:19 +0000 |
| Message-ID | <m49uby.fzt@spenarnc.xs4all.nl> |
| In reply to | #12293 |
In article <MYGdnZT7e6l4-CrSnZ2dnUVZ_gSdnZ2d@supernews.com>,
Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
>Rod Pemberton <do_not_have@notemailntt.cmm> wrote:
>> "Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
>> news:oLGdnbOmra7T9CvSnZ2dnUVZ_o6dnZ2d@supernews.com...
>>> Rod Pemberton <do_not_have@notemailntt.cmm> wrote:
>>> > <vandys@vsta.org> wrote in message
>> news:a1l87gFvfoU1@mid.individual.net...
>> ...
>>
>>> > Let's repost your original C code:
>>> >
>>> >> void
>>> >> memcopy(char *src, char *dest, int count)
>>> >> {
>>> >> while (count--) {
>>> >> *dest++ = *src++;
>>> >> }
>>> >> }
>>> >
>>> > ...
>>> >
>>> >> 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:
>>> >>
>>> >
>>>
>>> 3.4.1 ? Ya gotta be kidding! That was seven years ago.
>>
>> I use GCC via DJGPP. I haven't upgraded in a while. I also have 4.1.0.
>> Sometimes I have Linux around, sometimes I don't. Right now, I don't.
>>
>>> > -O2
>>> > produces for your C code above, without "procedure call noise", the
>>> > following:
>>> >
>>> > jmp L7
>>> > L9:
>>> > movb (%ebx), %al
>>> > incl %ebx
>>> > movb %al, (%ecx)
>>> > incl %ecx
>>> > L7:
>>> > decl %edx
>>> > cmpl $-1, %edx
>>> > jne L9
>>>
>>> I get this with 4.6.3:
>>>
>>> testl %ecx, %ecx
>>> je .L1
>>> xorl %eax, %eax
>>> .L3:
>>> movzbl (%ebx,%eax), %edx
>>> movb %dl, (%esi,%eax)
>>> addl $1, %eax
>>> cmpl %ecx, %eax
>>> jne .L3
>>> .L1:
>>>
>>> I ask you, how would you like it if someone used an ancient version of
>>> your software that you'd done a lot of work on and complained about
>>> its performance? :-)
>>
>> GCC is not known for efficient code.
>
>Known by whom? People who use seven-year-old compilers?
>
>> I doubt that has changed. E.g., why the movzbl to %edx when only
>> %dl is used? Why the 'addl' instead of 'incl' in 32-bit code?
>
>Instruction choice depends on the processor in use. If you compile
>this for a 486 you get
>
> je .L1
> xorl %eax, %eax
>.L3:
> movb (%ebx,%eax), %dl
> movb %dl, (%esi,%eax)
> incl %eax
> cmpl %ecx, %eax
> jne .L3
>.L1:
>
>It's not just a matter of instruction length: some instructions pair
>in the pipelines better than others. GCC has a model of the processor
>that is used to drive the choice of instructions.
>
>> They need to study a compiler known for better code generation,
>> e.g., Watcom/OpenWatcom.
>
>I note that you evaded my question. How would you like it? ("They"
>includes me, BTW.) Of course, GCC isn't perfect, and work goes on
>improving performance. There are examples of suboptimal code, but
>this is not one of them.
And of course it is open source. You don't like it, you improve it.
Just propose a patch!
>
>And finally, if you really want good performance for his loop, you
>unroll it. GCC will of course do that, but it's too long to include
>here.
>
>Andrew.
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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-05-17 18:33 -0500 |
| Message-ID | <wLGdnc3bSflGFyjSnZ2dnUVZ_uOdnZ2d@supernews.com> |
| In reply to | #12241 |
Peter Knaggs <pjk@bcs.org.uk> wrote: > 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. Yes. Elsewhere lies madness. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2012-05-18 01:49 -0700 |
| Message-ID | <61a1e31b-24b3-4831-8940-2cb367e8dc3a@oe8g2000pbb.googlegroups.com> |
| In reply to | #12252 |
On May 17, 4:33 pm, Andrew Haley <andre...@littlepinkcloud.invalid> wrote: > Peter Knaggs <p...@bcs.org.uk> wrote: > > 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. > > Yes. Elsewhere lies madness. > > Andrew. Straight Forth will assume that characters are one byte in size. I won't have anything like CHARS etc.. I will have something similar to CELLS and all of that, so that Straight Forth can support both 16-bit and 32-bit processors though.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-05-18 07:59 -0700 |
| Message-ID | <7x8vgp1qns.fsf@ruckus.brouhaha.com> |
| In reply to | #12252 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> This makes the, very common, assumption that a character is one >> address unit wide. > Yes. Elsewhere lies madness. Other languages are now finding this untenable. One of the issues making Python bite the bullet and do a bunch of incompatible changes from Python 2 to Python 3, was the huge amount of bugs and conversion hassles because Python 2 strings used byte-wide chars. So Python 3 uses unicode by default. Haskell and Java have used unicode for quite a bit longer. C libraries have things like wchar_t and so forth. 1-byte chars may be ok as a sort of lowest common denominator but programs dealing with non-Latin alphabets are hre to stay.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-05-18 10:32 -0500 |
| Message-ID | <bqmdnQrXZLDu9ivSnZ2dnUVZ_vadnZ2d@supernews.com> |
| In reply to | #12283 |
Paul Rubin <no.email@nospam.invalid> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>> This makes the, very common, assumption that a character is one >>> address unit wide. >> Yes. Elsewhere lies madness. > > Other languages are now finding this untenable. One of the issues > making Python bite the bullet and do a bunch of incompatible changes > from Python 2 to Python 3, was the huge amount of bugs and conversion > hassles because Python 2 strings used byte-wide chars. Well, hold on. In ANS Forth, C@ and C! access a character, whatever size that character happens to be. This isn't a wide character, and is effectively a byte. The word CHARS has nothing to do with wide characters, which are handled with the Xchar wordset. http://www.forth200x.org/xchar.html talks about pchars, which are effectively bytes, and xchars, which are wide characters built from pchars. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-05-20 17:24 +0200 |
| Message-ID | <jpb2c7$45f$1@online.de> |
| In reply to | #12286 |
Andrew Haley wrote: > Well, hold on. In ANS Forth, C@ and C! access a character, whatever > size that character happens to be. This isn't a wide character, and > is effectively a byte. The word CHARS has nothing to do with wide > characters, which are handled with the Xchar wordset. > http://www.forth200x.org/xchar.html talks about pchars, which are > effectively bytes, and xchars, which are wide characters built from > pchars. It should also be noted that in many cases, C! and C@ in Forth code really mean bytes (i.e. any data that fits into 0..255), not characters. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-05-20 15:43 -0700 |
| Message-ID | <7xfwauzd5p.fsf@ruckus.brouhaha.com> |
| In reply to | #12286 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>> This makes the, very common, assumption that a character is one >>>> address unit wide. >>> Yes. Elsewhere lies madness. ... > Well, hold on. In ANS Forth, C@ and C! access a character, whatever > size that character happens to be. Do those contradict each other? The first quote says that a char is one address unit (i.e. 1 byte). The second says it's whatever width. I'm saying that the current trend is for "character" to mean unicode, i.e. multiple bytes.
[toc] | [prev] | [next] | [standalone]
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2012-05-20 16:03 -0700 |
| Message-ID | <6dff0c39-8f41-4df2-a060-f42d2b4914ff@to5g2000pbc.googlegroups.com> |
| In reply to | #12316 |
On May 20, 6:43 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
> Do those contradict each other? The first quote says that a char is
> one address unit (i.e. 1 byte). The second says it's whatever width.
> I'm saying that the current trend is for "character" to mean unicode,
> i.e. multiple bytes.
But in that context, the C "char" would be a byte, not a unicode
character, so if [1chars=1] {NB} is true, then the sequence seems
valid.
{NB.
1 CHARS 1 = CONSTANT [1chars=1] IMMEDIATE
}
...
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-05-20 16:34 -0700 |
| Message-ID | <7xzk92zat0.fsf@ruckus.brouhaha.com> |
| In reply to | #12318 |
BruceMcF <agila61@netscape.net> writes: >> I'm saying that the current trend is for "character" to mean unicode, > But in that context, the C "char" would be a byte, not a unicode > character, Yes, C has used char=byte since the 1970's and as such, it is far behind the current trend.
[toc] | [prev] | [next] | [standalone]
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2012-05-20 17:02 -0700 |
| Message-ID | <549a43b9-d567-45dd-9889-0956128193d3@nl1g2000pbc.googlegroups.com> |
| In reply to | #12319 |
On May 20, 7:34 pm, Paul Rubin <no.em...@nospam.invalid> wrote: > BruceMcF <agil...@netscape.net> writes: > >> I'm saying that the current trend is for "character" to mean unicode, > > But in that context, the C "char" would be a byte, not a unicode > > character, > Yes, C has used char=byte since the 1970's and as such, it is far behind > the current trend. That is quibbling over labels. Calling a byte "char" doesn't mean that you store your character code points as bytes, it means that when the low level support for UTF8 uses the four letter sequence "char" to label the bytes in the format.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-05-21 04:46 -0500 |
| Message-ID | <S6-dnQP6BcRvkyfSnZ2dnUVZ_j-dnZ2d@supernews.com> |
| In reply to | #12319 |
Paul Rubin <no.email@nospam.invalid> wrote: > BruceMcF <agila61@netscape.net> writes: >>> I'm saying that the current trend is for "character" to mean unicode, >> But in that context, the C "char" would be a byte, not a unicode >> character, > > Yes, C has used char=byte since the 1970's and as such, it is far behind > the current trend. Java uses bytes (which are what Forth calls pchars) and chars (which are what Forth calls xchars). It's no different; you're just arguing about what things are called. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-05-21 08:33 -0700 |
| Message-ID | <7xzk91im5a.fsf@ruckus.brouhaha.com> |
| In reply to | #12339 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > Java uses bytes (which are what Forth calls pchars) and chars (which > are what Forth calls xchars). It's no different; you're just arguing > about what things are called. Hmm, ok. There are some operations that really do operate on characters rather than bytes, but in Forth I guess not that many.
[toc] | [prev] | [next] | [standalone]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web