Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #42733 > unrolled thread
| Started by | Marcos Cruz <use_the_contact_page@programandala.net> |
|---|---|
| First post | 2015-10-21 20:09 +0000 |
| Last post | 2015-11-04 09:52 +0000 |
| Articles | 20 on this page of 91 — 15 participants |
Back to article view | Back to comp.lang.forth
alternatives to `find` Marcos Cruz <use_the_contact_page@programandala.net> - 2015-10-21 20:09 +0000
Re: alternatives to `find` anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-22 05:54 +0000
Re: alternatives to `find` Marcos Cruz <use_the_contact_page@programandala.net> - 2015-10-22 15:37 +0000
Re: alternatives to `find` Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-10-22 22:03 -0700
Re: alternatives to `find` Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-10-22 22:14 -0700
Re: alternatives to `find` hughaguilar96@gmail.com - 2015-10-23 01:28 -0700
Re: alternatives to `find` Marcos Cruz <use_the_contact_page@programandala.net> - 2015-10-23 12:12 +0000
Re: alternatives to `find` anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-26 11:39 +0000
Re: alternatives to `find` Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-10-26 05:14 -0700
Re: alternatives to `find` Marcos Cruz <use_the_contact_page@programandala.net> - 2015-10-23 12:30 +0000
Re: alternatives to `find` Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-10-23 22:52 -0700
Re: alternatives to `find` Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-10-23 23:14 -0700
Re: alternatives to `find` Marcos Cruz <use_the_contact_page@programandala.net> - 2015-10-24 11:15 +0000
Re: alternatives to `find` Coos Haak <chforth@hccnet.nl> - 2015-10-24 14:34 +0200
Re: alternatives to `find` anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-24 14:45 +0000
Re: alternatives to `find` Coos Haak <chforth@hccnet.nl> - 2015-10-24 17:23 +0200
Preserving standard and common use names (Re: alternatives to `find`) Marcos Cruz <use_the_contact_page@programandala.net> - 2015-10-24 11:53 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-10-24 22:48 -0700
Re: Preserving standard and common use names (Re: alternatives to `find`) "Elizabeth D. Rather" <erather@forth.com> - 2015-10-24 21:05 -1000
Re: Preserving standard and common use names (Re: alternatives to `find`) Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-10-25 01:34 -0700
Re: Preserving standard and common use names (Re: alternatives to `find`) "Elizabeth D. Rather" <erather@forth.com> - 2015-10-24 22:45 -1000
Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-25 09:16 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) "Elizabeth D. Rather" <erather@forth.com> - 2015-10-25 08:46 -1000
Re: Preserving standard and common use names (Re: alternatives to `find`) hughaguilar96@gmail.com - 2015-10-25 21:31 -0700
Re: Preserving standard and common use names (Re: alternatives to `find`) Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-25 18:50 +0100
Re: Preserving standard and common use names (Re: alternatives to `find`) Mark Wills <markwills1970@gmail.com> - 2015-10-26 01:57 -0700
Re: Preserving standard and common use names (Re: alternatives to `find`) Paul Rubin <no.email@nospam.invalid> - 2015-10-26 02:07 -0700
Re: Preserving standard and common use names (Re: alternatives to `find`) Ron Aaron <rambamist@gmail.com> - 2015-10-26 11:14 +0200
Re: Preserving standard and common use names (Re: alternatives to `find`) Mark Wills <markwills1970@gmail.com> - 2015-10-26 04:18 -0700
Re: Preserving standard and common use names (Re: alternatives to `find`) "Elizabeth D. Rather" <erather@forth.com> - 2015-10-26 09:22 -1000
Re: Preserving standard and common use names (Re: alternatives to `find`) hughaguilar96@gmail.com - 2015-10-26 21:34 -0700
Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-26 10:58 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) Mark Wills <markwills1970@gmail.com> - 2015-10-26 05:59 -0700
Re: Preserving standard and common use names (Re: alternatives to `find`) Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-26 14:58 +0100
Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-27 17:09 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) stephen@mpeforth.com (Stephen Pelc) - 2015-10-28 12:50 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-28 15:56 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) Paul Rubin <no.email@nospam.invalid> - 2015-10-28 10:31 -0700
Re: Preserving standard and common use names (Re: alternatives to `find`) Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-28 19:26 +0100
Re: Preserving standard and common use names (Re: alternatives to `find`) Paul Rubin <no.email@nospam.invalid> - 2015-10-28 12:37 -0700
Re: Preserving standard and common use names (Re: alternatives to `find`) stephen@mpeforth.com (Stephen Pelc) - 2015-10-28 23:03 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) Paul Rubin <no.email@nospam.invalid> - 2015-10-28 16:21 -0700
Re: Preserving standard and common use names (Re: alternatives to `find`) Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-28 20:37 +0100
Re: Preserving standard and common use names (Re: alternatives to `find`) stephen@mpeforth.com (Stephen Pelc) - 2015-10-28 23:13 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-29 03:01 +0100
Re: Preserving standard and common use names (Re: alternatives to `find`) stephen@mpeforth.com (Stephen Pelc) - 2015-10-29 10:04 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-29 15:29 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) Mark Wills <markwills1970@gmail.com> - 2015-10-30 04:17 -0700
Re: Preserving standard and common use names (Re: alternatives to `find`) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-10-30 11:36 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-31 15:25 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-10-31 20:34 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-10-30 20:51 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) Mark Wills <markwills1970@gmail.com> - 2015-11-02 01:39 -0800
Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-02 11:12 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-02 12:09 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) Mark Wills <markwills1970@gmail.com> - 2015-11-02 05:09 -0800
Re: Preserving standard and common use names (Re: alternatives to `find`) Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-02 06:23 -0800
Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-02 14:39 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-20 16:20 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) Mark Wills <markwills1970@gmail.com> - 2015-11-21 00:26 -0800
Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-31 15:03 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) stephen@mpeforth.com (Stephen Pelc) - 2015-10-31 16:35 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-01 14:07 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-01 21:05 +0100
Re: Preserving standard and common use names (Re: alternatives to `find`) stephen@mpeforth.com (Stephen Pelc) - 2015-10-31 16:31 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-31 20:33 +0100
Re: Preserving standard and common use names (Re: alternatives to `find`) Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-29 22:27 +0100
Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-29 13:19 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-29 10:00 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) stephen@mpeforth.com (Stephen Pelc) - 2015-10-29 13:29 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-29 14:04 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) stephen@mpeforth.com (Stephen Pelc) - 2015-10-29 16:29 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-29 16:42 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-29 16:13 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) mhx@iae.nl - 2015-10-29 12:19 -0700
Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-31 14:12 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) stephen@mpeforth.com (Stephen Pelc) - 2015-10-31 16:49 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) Paul Rubin <no.email@nospam.invalid> - 2015-10-31 10:33 -0700
Re: Preserving standard and common use names (Re: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-01 14:14 +0000
Re: Preserving standard and common use names (Re: alternatives to `find`) hughaguilar96@gmail.com - 2015-10-25 21:52 -0700
Re: alternatives to `find` Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-10-30 12:30 +0000
Re: alternatives to `find` anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-26 11:47 +0000
Re: alternatives to `find` Chris Curl <ccurl609@gmail.com> - 2015-11-02 06:17 -0800
Re: alternatives to `find` Mark Wills <markwills1970@gmail.com> - 2015-11-02 06:35 -0800
Re: alternatives to `find` Coos Haak <chforth@hccnet.nl> - 2015-11-02 15:45 +0100
Re: alternatives to `find` Chris Curl <ccurl609@gmail.com> - 2015-11-02 07:17 -0800
Re: alternatives to `find` Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-02 19:39 +0000
Re: alternatives to `find` Mark Wills <markwills1970@gmail.com> - 2015-11-02 12:19 -0800
Re: alternatives to `find` anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-03 11:31 +0000
Re: alternatives to `find` Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-03 21:11 +0000
MOVE and CMOVE speed (was: alternatives to `find`) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-04 09:52 +0000
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-10-31 15:03 +0000 |
| Subject | Re: Preserving standard and common use names (Re: alternatives to `find`) |
| Message-ID | <2015Oct31.160359@mips.complang.tuwien.ac.at> |
| In reply to | #42991 |
Mark Wills <markwills1970@gmail.com> writes:
>It's a different situation entirely for MPE though. For MPE, the
>only choice he would have in that circumstance, would be to
>support two systems in parallel; ANS94 and xxxx (too late for 2000x).
>His client with 1.2 million lines of code will not be happy if his
>code breaks over night because VFX is brought into line with a new
>standard; therefore MPE would have a create a new product, derived
>perhaps from VFX, but not called VFX supporting the new portable
>standard. Thus he now has two products support until his clients
>can port across to the new standard.
No, in this case (the 1 chars = 1 proposal) no such thing is
necessary. VFX already implements the proposal and all Forth systems
of MPE and Forth, Inc., and nearly all others always have implemented
the proposal. The 1.2M line program works on VFX, and would probably
break if VFX changed to 1 chars > 1. So Stephen Pelc actually wants
to, in his terms, keep his client's program disenfranchised by not
standardizing a feature that is extremely common practice among both
systems and programs.
The reason he gives is that there are a few systems around that have
explored this corner of the standard; however insignificant these
systems are, they are apparently more significant in his opinion than
all the programs around that have a dependency on 1 chars = 1,
including his client's 1.2M line program.
>But I'm encouraged to see you aknowledge that the current standard
>does not meet the goal of portability.
The problem is that program portability is not a goal desired by
everyone in the community, not even everyone on the Forth-200x
committee.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-10-31 16:35 +0000 |
| Subject | Re: Preserving standard and common use names (Re: alternatives to `find`) |
| Message-ID | <5634ed13.46667028@news.eternal-september.org> |
| In reply to | #43038 |
On Sat, 31 Oct 2015 15:03:59 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >So Stephen Pelc actually wants >to, in his terms, keep his client's program disenfranchised by not >standardizing a feature that is extremely common practice among both >systems and programs. Another dash from the general to the specific by a misunderstanding of what I have said. Enlarging on misunderstanding leads to more incorrect statements. 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-11-01 14:07 +0000 |
| Subject | Re: Preserving standard and common use names (Re: alternatives to `find`) |
| Message-ID | <2015Nov1.150744@mips.complang.tuwien.ac.at> |
| In reply to | #43042 |
stephen@mpeforth.com (Stephen Pelc) writes:
>On Sat, 31 Oct 2015 15:03:59 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>So Stephen Pelc actually wants
>>to, in his terms, keep his client's program disenfranchised by not
>>standardizing a feature that is extremely common practice among both
>>systems and programs.
>
>Another dash from the general to the specific by a misunderstanding
>of what I have said. Enlarging on misunderstanding leads to more
>incorrect statements.
Is this a tactic you learn in English debate clubs: Make a claim, and
when that claim is contradicted, claim that you were misunderstood,
but never ever state what the alternative understanding would be (I
suspect because there is no alternative understanding of the claim
that is defendable, either)? Andrew Haley also used this tactic, and
therefore discussions with him were usually not constructive.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-11-01 21:05 +0100 |
| Subject | Re: Preserving standard and common use names (Re: alternatives to `find`) |
| Message-ID | <n15r5i$5rh$1@dont-email.me> |
| In reply to | #43072 |
Anton Ertl wrote: > Is this a tactic you learn in English debate clubs: Make a claim, and > when that claim is contradicted, claim that you were misunderstood, Don't know about debate clubs, but the currend US presidential campaign has a number of candidates who use that tactic. The other half of the debate is done by stupid misinterpretation of the words used, e.g.: Bernie Sanders: "There's a lot of shouting on both sides in the gun control debate" Hillary Clinton: "YOU FREAKING SEXIST! YOU CALLED ME A SHOUTING BITCH!" Bernie Sanders: "I didn't say that, I just said there's a lot of shou..." Hillary Clinton in her halloween witch-bitch costume (http://www.overadulthood.com/clinton-makes-obama-her-bitch/): "WE WOMEN SOMETIMES SPEEK IN A HIGH-PITCHED VOICE, WHICH PEOPLE MISREPRESENT AS SHOUTING, YOU SEXIST BRAT!" People already make jokes about that "debate culture": https://plus.google.com/105071855342998118851/posts/7AhdLe5wysr I suppose the reason is that this debate culture rewards winning at all cost, but not finding the truth. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-10-31 16:31 +0000 |
| Subject | Re: Preserving standard and common use names (Re: alternatives to `find`) |
| Message-ID | <5634eae0.46104192@news.eternal-september.org> |
| In reply to | #42991 |
On Fri, 30 Oct 2015 04:17:43 -0700 (PDT), Mark Wills <markwills1970@gmail.com> wrote: >On Thursday, 29 October 2015 16:13:15 UTC, Anton Ertl wrote: >> Well, actually, I do. I want a standard in which one can easily write >> programs which can be ported from one system to the next without >> changing a single line of code. If there are systems that have to >> change to reach this goal, then they should change. >In that case, I urge the committee to step up to the plate, make the >difficult, unpallatable, unpopular decisions, and give us a standard >"in which one can easily write programs which can be ported from one >system to the next without changing a single line of code." Be careful what you wish for. If you want to be able to port substantial applications, then the standard will probably get a lot bigger. For example, you will have to accept a standard string library. Such libraries are probably not standardisable using the current mechanisms. Geral Wodni has started work on a framework for libraries. > >His client with 1.2 million lines of code will not be happy if his >code breaks over night because VFX is brought into line with a new >standard; therefore MPE would have a create a new product, derived >perhaps from VFX, but not called VFX supporting the new portable >standard. Thus he now has two products support until his clients >can port across to the new standard. Worse than that, MPE may decide that the client is more important than the standard, and so may choose to ignore the standard. >This is corner that the current standard(s) has/is painting people >into. From a commercial perspective, I care a lot more about enhanced and useful functionality than I care about the fine details of ambiguous conditions. I do not need to know how many angels can dance on FIND's return values. 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-10-31 20:33 +0100 |
| Subject | Re: Preserving standard and common use names (Re: alternatives to `find`) |
| Message-ID | <n134uc$cbb$1@dont-email.me> |
| In reply to | #43041 |
Stephen Pelc wrote: > If you want to be able to port substantial applications, then > the standard will probably get a lot bigger. For example, you > will have to accept a standard string library. Such libraries > are probably not standardisable using the current mechanisms. > Geral Wodni has started work on a framework for libraries. The string library I use is fully Forth-94 and -2012 standard. The only non-standard thing I have in this regard is the regexp compiler, which uses some return stack tricks, including forward calls within one definition to implement backtracking. And postpone mode, to make it more readable... but I think you could do postpone mode in ANS Forth, too; though with recognizers, it's easier. A substantial application will usually come with the string library of choice of its author. That's not something we can standardize, because different people like different string libraries. But we can standardize enough basics, so that portable string libraries become possible. That's the actual point of making libraries and making sure that portable code is possible. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-10-29 22:27 +0100 |
| Subject | Re: Preserving standard and common use names (Re: alternatives to `find`) |
| Message-ID | <n0u2rv$io8$1@dont-email.me> |
| In reply to | #42953 |
Stephen Pelc wrote: >>I would expect considerably implementation problems if you don't know >>whether a value is an integer or a float until you actually process it and >>select the correct register where it should live (Sn for floats, Rn for >>ints) when you have a combined stack. How did you deal with that? > > Assume that the user knows the difference between + and F+. Is that > a suitably Bernd-ish response? Ok, a Bernd-ish response question: Should the user also know the difference between F@ and @, and FDUP and DUP, because in the single-cell, combined- stack case, there is none? With a simple Forth system, the deal is easy, you just VMOV from RTOS to STOS, add the second operand (from memory), and VMOV STOS back to RTOS. Don't care about the two VMOVs, because the floating point can be slow; it's a simple, non-optimizing system, everything is slow. But you don't do that, you use a register allocater for the stack cells. Register allocaters don't like it when the same virtual register is sometimes here, sometimes there. It's much easier if you have a register that always was a floating point, and always will be a floating point until the end of its life as register (in memory, it can become an integer). Therefore I would presume that dealing with separate integer and floating point register files by having separat stacks is considerably easier. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-10-29 13:19 +0000 |
| Subject | Re: Preserving standard and common use names (Re: alternatives to `find`) |
| Message-ID | <2015Oct29.141909@mips.complang.tuwien.ac.at> |
| In reply to | #42942 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Stephen Pelc wrote:
>> From a software writer's point of
>> view, a separate FP stack wins every time for ease of use.
>
>Yes. Next is a combined stack with one cell per floating point, still ok.
>Combined stack with double- or quad-cell FP, much worse. But the worst
>thing is to write a program that works on both combined and separate stacks.
>That's really hard.
Note that "combined stack with unspecified FP item size" is just as bad.
>> In such cases we should just admit it and
>> change the standard. If I knew then what I know about 32 bit CPUs and
>> and 32 bit FP, I would not have accepted the combined/separate FP
>> stack argument without a *lot* more consideration.
>
>I would expect considerably implementation problems if you don't know
>whether a value is an integer or a float until you actually process it and
>select the correct register where it should live (Sn for floats, Rn for
>ints) when you have a combined stack. How did you deal with that?
I would deal with that by keeping track of where the stack item
resides now; if it's in an integer register and I need it in an FP
register for the FP operation, then I insert a VMOV between from the
integer to the FP registers before the FP operation. E.g., if the
user writes @ F+ over !, the @ might put its result in an integer
register, so F+ would have to move it to an FP register (and maybe the
other operand, too), then do the FADDS; the ! might expect its
operands in integer registers, so insert another VMOV to move the F+
result back to the integer registers. Of course, it's possible to let
the @ load into the FP registers, and let the ! store from the FP
registers, at the cost of additional complexity in the compiler.
>Apart from experimental Forth CPUs or Forth-like CPUs there are no CPUs
>where floating point and integer unit share the register file.
All the Forth-like CPUs I know of only have software FP. The overhead
of moving data from a separate stack to the data stack for doing the
software implementation of FP is vanishingly small compared to the
time spent in the FP operations themselves. And if the programmer
writes Forth-94 compliant code, the Forth system has just thrown that
overhead over the fence to the programmer, but it's still there,
because now the programmer has to perform additional words for sorting
the integer and FP values apart.
>We probably should state that CHARS and CHAR+ are obsolescent, because
>they usually are NOOP and 1+, but if not, like with the combined FP stack,
>it's an obsolescent environmental restriction that 1 CHARS <> 1.
As long as we keep CHARS and CHAR+, and differentiate between address
units and chars in the specifications of the various words, it is
possible to declare a system to have an environmental restriction of 1
CHARS > 1. Once we remove them, that becomes more cumbersome, because
the system would also have to specify which counts refer to characters
and which ones to address units.
However, the feedback I have had in recent weeks (in the standards
meeting and outside) is that people (including some that are against
the 1 CHARS = 1 proposal) seem to prefer to get rid of CHARS and CHAR+
and of "address units" if we accept the 1 CHARS = 1 proposal. That
would mean another proposal (or two) that makes CHARS and CHAR+
obsolescent, and makes wording changes to remove "address unit".
Concerning "obsolescent environmental restrictions", there has been no
such things in the past, and I don't think there is a point to them.
A system can declare environmental restrictions on anything; no
specific environmental restrictions were mentioned in Forth-94, and
only very few are specifically mentioned in Forth-2012. So there is
no point in declaring an environmental restruction to be obsolescent.
Once we have removed it from the standard document, systems can still
declare such an environmental restriction.
>Or, if we do it as with the unified floating point stack, we
>could mark it as environmental restriction. Only if this goes away, it will
>be completely out of the standard.
Even if that environmental restriction is no longer mentioned in the
standard, a system can still declare it. It would become hard if we
removed the combined stack effect diagrams from the standard, because
then a system with that environmental restriction would also have to
document the stack effects for many words.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-10-29 10:00 +0000 |
| Subject | Re: Preserving standard and common use names (Re: alternatives to `find`) |
| Message-ID | <2015Oct29.110043@mips.complang.tuwien.ac.at> |
| In reply to | #42937 |
stephen@mpeforth.com (Stephen Pelc) writes:
>From a software writer's point of
>view, a separate FP stack wins every time for ease of use.
...
>However, you totally ignore my main point, which is that sometimes
>standards just get it wrong. In such cases we should just admit it and
>change the standard.
Yes, Forth-94 got it wrong for the floating-point stack issue, and we
admitted it and changed it in Forth-2012. And as a consequence,
programmers can now more easily write standard programs (without
environmental dependencies), and these programs run faster than
Forth-94 programs for the same task. Just to remind you:
| Forth-2012 Forth-94
|500x500 mm - normal algorithm 0.570s 0.727s
|500x500 mm - transposed B matrix 0.550s 0.686s
|500x500 mm - Robert's algorithm 0.547s 0.684s
> If I knew then what I know about 32 bit CPUs and
>and 32 bit FP, I would not have accepted the combined/separate FP
>stack argument without a *lot* more consideration.
Your claim was that the Cortex-M4F uses the integer registers as FP
registers, and that's why you see a combined stack as better, but
looking at the Cortex-M4 Technical Reference Manual
<http://infocenter.arm.com/help/topic/com.arm.doc.ddi0439b/DDI0439B_cortex_m4_r0p0_trm.pdf>,
it has a separate set of 32 single-precision FP registers and uses the
32-bit subset of the usual ARM VFP floating-point instruction set, and
I just tried to assemble a floating-point instruction using integer
registers, and the assembler told me:
Error: VFP single precision register expected -- `fadds r0,r0,r1'
So the Cortex-M4, too, is among the CPUs that have separate FP
registers.
So if you have a shared stack and cache the TOS in an integer register
(which is the VFX calling convention for IA-32), and you want to do an
FP operation involving that stack item, you need an extra VMOV
instruction for moving that stack item into an FP register, costing
performance; conversely, if the TOS at the end of a definition comes
out of an FP instruction, you need to move it from the FP register to
the TOS integer register.
By contrast, with a separate FP stack, you can keep the FTOS in an FP
register, and don't need to use VMOV instructions to move between
integer and FP registers. Yes, you need a separate FP stack pointer
(unless you take the PAF way for the parts of the program that comply
with PAF restrictions), but that's the same as on other CPUs, where
you also have separate FP registers and where a separate FP stack
needs a separate stack pointer, such as IA-32 and AMD64. And where the
Forth-2012 way is faster than the Forth-94 way, as shown above.
>People have already made a similar point to me about the byte
>addressed CPU assumption and 1 CHARS = 1. More thought needed.
There Forth-94 also got it wrong, but at looked like the way to go in
the early 1990s (in contrast to the Forth-94 FP stack non-decision,
which was always a bad idea). In the meantime we have seen that 1
CHARS >1 is not needed. Sure some people may need more thought, but
will they actually take more thought? Two of the three people who
abstained had not been present when the proposal was presented and
discussed the day before, and probably had not read the proposal
earlier. So of course they felt they were not sufficiently qualified
to decide on the proposal, and abstained (probably without knowing
that too many abstentions are also not a consensus).
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-10-29 13:29 +0000 |
| Subject | Re: Preserving standard and common use names (Re: alternatives to `find`) |
| Message-ID | <56321e89.338551872@news.eternal-september.org> |
| In reply to | #42958 |
On Thu, 29 Oct 2015 10:00:43 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >stephen@mpeforth.com (Stephen Pelc) writes: >> If I knew then what I know about 32 bit CPUs and >>and 32 bit FP, I would not have accepted the combined/separate FP >>stack argument without a *lot* more consideration. > >Your claim was that the Cortex-M4F uses the integer registers as FP >registers, I said no such thing. 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-10-29 14:04 +0000 |
| Subject | Re: Preserving standard and common use names (Re: alternatives to `find`) |
| Message-ID | <2015Oct29.150422@mips.complang.tuwien.ac.at> |
| In reply to | #42960 |
stephen@mpeforth.com (Stephen Pelc) writes:
>On Thu, 29 Oct 2015 10:00:43 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>stephen@mpeforth.com (Stephen Pelc) writes:
>>> If I knew then what I know about 32 bit CPUs and
>>>and 32 bit FP, I would not have accepted the combined/separate FP
>>>stack argument without a *lot* more consideration.
>>
>>Your claim was that the Cortex-M4F uses the integer registers as FP
>>registers,
>
>I said no such thing.
Well, I heard it twice out of your mouth, at the 2014 meeting and at
the 2015 meeting. Next time I will take a tape with me so I can prove
it to you. If you had not made that claim (that I did not check at
the time given that ARM documentation is hard to get at and messy in
my experience; I am really surprised that I found that Cortex-M4
manual; maybe they are learning that keeping your interfaces secret is
a competetive disadvantage), I would have contradicted your claims
about the benefits of a combined stack instead of letting it pass.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-10-29 16:29 +0000 |
| Subject | Re: Preserving standard and common use names (Re: alternatives to `find`) |
| Message-ID | <563248ae.349340636@news.eternal-september.org> |
| In reply to | #42962 |
On Thu, 29 Oct 2015 14:04:22 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >>I said no such thing. > >Well, I heard it twice out of your mouth, at the 2014 meeting and at >the 2015 meeting. Well, I must learn to speak better English ... >If you had not made that claim (that I did not check at >the time given that ARM documentation is hard to get at and messy in >my experience; Well, that's a claim that you repeat at regular intervals. I find that claim to be false. 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-10-29 16:42 +0000 |
| Subject | Re: Preserving standard and common use names (Re: alternatives to `find`) |
| Message-ID | <2015Oct29.174211@mips.complang.tuwien.ac.at> |
| In reply to | #42966 |
stephen@mpeforth.com (Stephen Pelc) writes:
>On Thu, 29 Oct 2015 14:04:22 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>>If you had not made that claim (that I did not check at
>>the time given that ARM documentation is hard to get at and messy in
>>my experience;
>
>Well, that's a claim that you repeat at regular intervals. I find that
>claim to be false.
It's interesting that you can falsify my experience. Are you with the
GCHQ or with the Thought Police?
Anyway, even though I did get at an ARM manual from an ARM site this
time (through a link found through Google, after trying out a number
of other hits that did not bring enlightenment), I still did not find
it very satisfying. The manual talks about the registers and about
the instructions, but does not tell me about the operands of the
instructions, so I could not verify that the instructions work only on
the FP registers from the manual. But at least it told me that the
Cortex-M4F uses the same FP instructions as other ARMs, so I verified
it with the assembler on an ARM machine we have.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-10-29 16:13 +0000 |
| Subject | Re: Preserving standard and common use names (Re: alternatives to `find`) |
| Message-ID | <2015Oct29.171325@mips.complang.tuwien.ac.at> |
| In reply to | #42958 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
[Separate FP stack standardized in Forth-2012]
>And as a consequence,
>programmers can now more easily write standard programs (without
>environmental dependencies), and these programs run faster than
>Forth-94 programs for the same task. Just to remind you:
>
>| Forth-2012 Forth-94
>|500x500 mm - normal algorithm 0.570s 0.727s
>|500x500 mm - transposed B matrix 0.550s 0.686s
>|500x500 mm - Robert's algorithm 0.547s 0.684s
On the same machine with VFX-4.71 and Ndp387.fth:
Forth-2012 Forth-94
500x500 mm - normal algorithm 0.220s 0.230s
500x500 mm - transposed B matrix 0.210s 0.220s
500x500 mm - Robert's algorithm 0.210s 0.220s
So the separate stack is faster than the Forth-94 way to program FP on
VFX, too.
Command lines:
vfxlin-4.71 "include /nfs/nfstmp/anton/VfxLinEval-4.71/Lib/Ndp387.fth include /nfs/nfstmp/anton/VfxLinEval-4.71/Lib/fsl/library/Vfx4Util.fth include mm.fth ddot-tests bye"
vfxlin-4.71 "include /nfs/nfstmp/anton/VfxLinEval-4.71/Lib/Ndp387.fth include /nfs/nfstmp/anton/VfxLinEval-4.71/Lib/fsl/library/Vfx4Util.fth create use-forth94 include mm.fth ddot-tests bye"
I can provide mm.fth if anybody is interested.
Here's the two implementations of DDOT and the code VFX generates for
the DO LOOP in them:
[defined] use-forth94 [if]
: DDOT ( addr1 inc1 addr2 inc2 count -- r )
SWAP DFLOATS >R ROT DFLOATS R>
LOCALS| inc2 inc1 count addr2 addr1 |
0E0 count 0
?DO addr1 DUP inc1 + TO addr1 DF@
addr2 DUP inc2 + TO addr2 DF@ F* F+
LOOP ;
[else]
: DDOT ( addr1 inc1 addr2 inc2 count -- ) ( F: -- n )
SWAP DFLOATS >R ROT DFLOATS R> LOCALS| inc2 inc1 |
0e 0 ?DO SWAP DUP DF@ inc1 +
SWAP DUP DF@ inc2 +
F* F+
LOOP 2DROP ;
[then]
Forth-2012 Forth-94
MOV EDX, [EBP] MOV EDX, [EDI+18]
FLD DOUBLE 0 [EDX] MOV ECX, [EDI+0C]
ADD EDX, [EDI+0C] ADD ECX, EDX
FLD DOUBLE 0 [EBX] MOV [EDI+18], ECX
ADD EBX, [EDI+08] FLD DOUBLE 0 [EDX]
FMULP ST(1), ST MOV EDX, [EDI+14]
FADDP ST(1), ST MOV ECX, [EDI+08]
ADD [ESP], 01 ADD ECX, EDX
ADD [ESP+04], 01 MOV [EDI+14], ECX
MOV [EBP], EDX FLD DOUBLE 0 [EDX]
JNO 080C93F0 FMULP ST(1), ST
FADDP ST(1), ST
ADD [ESP], 01
ADD [ESP+04], 01
JNO 080C9430
Surprising that the performance difference is so small. Maybe the
machine is waiting for the L3 cache much of the time.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2015-10-29 12:19 -0700 |
| Subject | Re: Preserving standard and common use names (Re: alternatives to `find`) |
| Message-ID | <f4f64741-1cd4-4dff-943e-65ef80e66573@googlegroups.com> |
| In reply to | #42967 |
On Thursday, October 29, 2015 at 5:36:58 PM UTC+1, Anton Ertl wrote: > anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > [Separate FP stack standardized in Forth-2012] > >And as a consequence, > >programmers can now more easily write standard programs (without > >environmental dependencies), and these programs run faster than > >Forth-94 programs for the same task. Just to remind you: > > > >| Forth-2012 Forth-94 > >|500x500 mm - normal algorithm 0.570s 0.727s > >|500x500 mm - transposed B matrix 0.550s 0.686s > >|500x500 mm - Robert's algorithm 0.547s 0.684s > > On the same machine with VFX-4.71 and Ndp387.fth: > > Forth-2012 Forth-94 > 500x500 mm - normal algorithm 0.220s 0.230s > 500x500 mm - transposed B matrix 0.210s 0.220s > 500x500 mm - Robert's algorithm 0.210s 0.220s > > So the separate stack is faster than the Forth-94 way to program FP on > VFX, too. It is a minor point. If Forth FP is that slow on these compilers, the FP stack internals are not going to save them. 500x500 mm - normal algorithm 0.152 secs. 500x500 mm - temporary variable in loop 0.281 secs. 500x500 mm - unrolled inner loop, factor of 4 0.167 secs. 500x500 mm - unrolled inner loop, factor of 8 0.149 secs. 500x500 mm - unrolled inner loop, factor of 16 0.140 secs. 500x500 mm - pointers used to access matrices 0.240 secs. 500x500 mm - pointers used, unrolled by 8 0.131 secs. 500x500 mm - transposed B matrix 0.262 secs. 500x500 mm - interchanged inner loops 0.245 secs. 500x500 mm - blocking, step size of 20 0.276 secs. 500x500 mm - Robert's algorithm 0.041 secs. 500x500 mm - T. Maeno's algorithm, subarray 20x20 0.273 secs. 500x500 mm - Generic Maeno, subarray 20x20 0.292 secs. 500x500 mm - D. Warner's algorithm, subarray 20x20 0.189 secs. 500x500 mm - SSE2 0.040 secs. ========================================================= ===== Total using no extensions and using no hackery 2.878 secs. ok BTW, it is funny how 'Warner' and 'Maeno' behaves over time due to Intel's internal tweakings / memory architecture evolution. It used to be several times slower than the other algorithms. -marcel
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-10-31 14:12 +0000 |
| Subject | Re: Preserving standard and common use names (Re: alternatives to `find`) |
| Message-ID | <2015Oct31.151219@mips.complang.tuwien.ac.at> |
| In reply to | #42976 |
mhx@iae.nl writes:
>On Thursday, October 29, 2015 at 5:36:58 PM UTC+1, Anton Ertl wrote:
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> [Separate FP stack standardized in Forth-2012]
>> >And as a consequence,
>> >programmers can now more easily write standard programs (without
>> >environmental dependencies), and these programs run faster than
>> >Forth-94 programs for the same task. Just to remind you:
>> >
>> >| Forth-2012 Forth-94
>> >|500x500 mm - normal algorithm 0.570s 0.727s
>> >|500x500 mm - transposed B matrix 0.550s 0.686s
>> >|500x500 mm - Robert's algorithm 0.547s 0.684s
>>
>> On the same machine with VFX-4.71 and Ndp387.fth:
>>
>> Forth-2012 Forth-94
>> 500x500 mm - normal algorithm 0.220s 0.230s
>> 500x500 mm - transposed B matrix 0.210s 0.220s
>> 500x500 mm - Robert's algorithm 0.210s 0.220s
>>
>> So the separate stack is faster than the Forth-94 way to program FP on
>> VFX, too.
>
>It is a minor point. If Forth FP is that slow on these compilers,
>the FP stack internals are not going to save them.
Sure, the ideal compiler will keep all the stack elements (FP and
integer ones) and locals in registers in these matrix multiplication
programs, and will generate exactly the same code for the Forth-94
variant, for the Forth-2012 variant, and for the variant with the
environmental dependency on a shared FP stack and one-cell FP values;
if there are not enough registers to keep the stack pointer(s) in
registers, they will be spilled before the matrix multiplication and
restored afterwards, at negligible cost. In that case, we should go
for the separate FP stack, because it's easiest to program.
However, real compilers are not ideal. And on the real compilers
gforth-fast and VFX, programming for a separate FP stack is not just
easier, but also faster. What about iForth?
>500x500 mm - normal algorithm 0.152 secs.
>500x500 mm - transposed B matrix 0.262 secs.
>500x500 mm - Robert's algorithm 0.041 secs.
Great results for normal and Robert's. But these results does not
contribute anything to the question of whether, as Stephen Pelc
suggested, we should go back to the Forth-94 model of programmers not
knowing whether FP items are on the data stack (and how many cells
they occupy there), or on a separate FP stack.
I also have a special MPE version of that benchmark lying around that
may run faster when fixed (currently it does not run on vfxlin at
all), but is also useless for evaluating the question above, because
it does not call DDOT.
BTW, as an alternative to turning a Forth-2012 variant into Forth-94
by keeping the FP values on the stack and moving the integers out of
the way into locals (as was used in the DDOT variant I used for the
experiments above), another option is to keep the integers on the
stack and move the FP values out of the way, e.g., into global
variables. For DDOT, the three variants would look like:
\ Forth-2012, separate FP stack
: DDOT ( addr1 inc1 addr2 inc2 count -- ) ( F: -- n )
SWAP DFLOATS >R ROT DFLOATS R> LOCALS| inc2 inc1 |
0e 0 ?DO SWAP DUP DF@ inc1 +
SWAP DUP DF@ inc2 +
F* F+
LOOP 2DROP ;
\ Forth-94 variant 1
: DDOT ( addr1 inc1 addr2 inc2 count -- r )
SWAP DFLOATS >R ROT DFLOATS R>
LOCALS| inc2 inc1 count addr2 addr1 |
0E0 count 0
?DO addr1 DUP inc1 + TO addr1 DF@
addr2 DUP inc2 + TO addr2 DF@ F* F+
LOOP ;
\ Forth-94 variant 2
fvariable s
fvariable t
: DDOT ( addr1 inc1 addr2 inc2 count -- ) ( F: -- n )
SWAP DFLOATS >R ROT DFLOATS R> LOCALS| inc2 inc1 |
0e s f!
0 ?DO ( addr1 addr2 )
SWAP DUP DF@ t f! inc1 +
SWAP DUP DF@ t f@ f* r f@ f+ r f! inc2 +
LOOP 2DROP r f@ ;
Variant 2 is significantly slower on VFX than variant 1.
Forth-2012 Forth-94
variant1 variant2
500x500 mm - normal algorithm 0.220s 0.230s 0.580s
500x500 mm - transposed B matrix 0.210s 0.220s 0.490s
500x500 mm - Robert's algorithm 0.210s 0.220s 0.490s
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-10-31 16:49 +0000 |
| Subject | Re: Preserving standard and common use names (Re: alternatives to `find`) |
| Message-ID | <5634ee48.46976503@news.eternal-september.org> |
| In reply to | #43036 |
On Sat, 31 Oct 2015 14:12:19 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >Great results for normal and Robert's. But these results does not >contribute anything to the question of whether, as Stephen Pelc >suggested, we should go back to the Forth-94 model of programmers not >knowing whether FP items are on the data stack (and how many cells >they occupy there), or on a separate FP stack. Yet again, I did not say that. What I did say was that for a class of 32 bit embbeded CPU with 32 bit hardware floating point, it may be appropriate to implement a Forth that uses the data stack for FP. A candidate is a Cortex-M4F. When MPE and clients have finished playing around with the various new FP packages, we'll make a choice. 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-10-31 10:33 -0700 |
| Subject | Re: Preserving standard and common use names (Re: alternatives to `find`) |
| Message-ID | <87twp7rlhm.fsf@jester.gateway.sonic.net> |
| In reply to | #43043 |
stephen@mpeforth.com (Stephen Pelc) writes: > ... for a class of 32 bit embbeded CPU with 32 bit hardware floating > point, it may be appropriate to implement a Forth that uses the data > stack for FP. A candidate is a Cortex-M4F. Bernd brought this up too: the VFX compiler optimizes out stack traffic by keeping stack items in registers, I thought. If it's a combined stack, doesn't the compiler need to do a lot more analysis (not sure if it's even feasible) to figure out which items are integer and which are FP?
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-11-01 14:14 +0000 |
| Subject | Re: Preserving standard and common use names (Re: alternatives to `find`) |
| Message-ID | <2015Nov1.151458@mips.complang.tuwien.ac.at> |
| In reply to | #43043 |
stephen@mpeforth.com (Stephen Pelc) writes:
>On Sat, 31 Oct 2015 14:12:19 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>Great results for normal and Robert's. But these results does not
>>contribute anything to the question of whether, as Stephen Pelc
>>suggested, we should go back to the Forth-94 model of programmers not
>>knowing whether FP items are on the data stack (and how many cells
>>they occupy there), or on a separate FP stack.
>
>Yet again, I did not say that.
Ah, that tactic again.
>What I did say was that for a class
>of 32 bit embbeded CPU with 32 bit hardware floating point, it may
>be appropriate to implement a Forth that uses the data stack for
>FP.
And you wrote
|If I knew then what I know about 32 bit CPUs and and 32 bit FP, I
|would not have accepted the combined/separate FP stack argument
|without a *lot* more consideration.
Now the question on the table for that decision was whether we should
standarize a separate FP stack (proposed in the proposal), or keep the
Forth-94 model of not knowing whether the stack is separate or
combined. You already delayed the decision by two years, and asked
for a clarification in the Rationale (which you got); if you did not
take enough considerations in these two years, and, judging from this
discussion, apparently not since then, the end result would have been
that the Forth-94 lack of standardization in this area would have
continued.
So, even if you did not suggest this verbatim, these are the only
alternatives: if you are happy with the Forth-2012 approach, its
unclear to me why we are having this discussion; so you are apparently
unhappy with it, and the consequence would be to reject the Forth-2012
change and go back to the Forth-94 model of programmers not knowing
whether FP items are on the data stack (and how many cells they occupy
there), or on a separate FP stack; i.e., what I wrote above.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-10-25 21:52 -0700 |
| Subject | Re: Preserving standard and common use names (Re: alternatives to `find`) |
| Message-ID | <1ea89daa-f7e1-4320-82a7-b7bc0cf5e20b@googlegroups.com> |
| In reply to | #42784 |
On Sunday, October 25, 2015 at 12:05:20 AM UTC-7, Elizabeth D. Rather wrote: > On 10/24/15 7:48 PM, Raimond Dragomir wrote: > > My opinion is that the standard is full of inconsistencies, and it stands in my way. So I ignore it most of the time. > > ... > If you don't want to write programs for other people to use, or use > programs other people have written, or expect anyone other than yourself > to use your system, a standard has very little value. Enjoy. > > Cheers, > Elizabeth Elizabeth Rather assumes that she and her ANS-Forth are indispensable to Forth --- that every Forther will always follow her and that none will ever follow Raimond Dragomir or anybody else --- this is why I say that ANS-Forth is a cult. I've actually seen Raimond Dragomir's Forth, and it is much higher quality than ANS-Forth. Is it the last word on Forth? No --- there will always be improvements and disagreements --- but it is a big step up from ANS-Forth. Raimond's Forth should appeal to Forthers who are interested in quality, but who are not interested in being Standard with a capital 'S' just so they can dismiss everybody else as being non-standard. Note that my Forth is for 64-bit desktop-computers, whereas Raimond's LFTforth is for 16-bit or 32-bit micro-controllers. So, he and I are not really competing against each other --- I have long said that it is a bad idea to have one Forth standard that is supposed to be both for desktop-computers and also for micro-controllers --- desktop-computers and micro-controllers are very different! My desktop-computer Forth could be used as the host for a cross-compiler for Raimond's LFTforth --- this would make sense for 16-bit targets that don't have much memory --- Raimond is currently focusing on the 32-bit ARM Cortex however, and it typically has enough memory to support a traditional on-board Forth, so there is not much need for my cross-compiler at this time.
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web