Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #48647 > unrolled thread
| Started by | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| First post | 2016-07-01 17:18 +0000 |
| Last post | 2016-07-03 22:00 +0100 |
| Articles | 20 on this page of 93 — 23 participants |
Back to article view | Back to comp.lang.forth
RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-01 17:18 +0000
Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-07-01 11:45 -0700
Re: RfD: new double syntax rickman <gnuarm@gmail.com> - 2016-07-01 14:46 -0400
Re: RfD: new double syntax Julian Fondren <julian.fondren@gmail.com> - 2016-07-01 11:47 -0700
Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-02 14:54 +0000
Re: RfD: new double syntax mhx@iae.nl - 2016-07-01 11:48 -0700
Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-02 14:52 +0000
Re: RfD: new double syntax "Elizabeth D. Rather" <erather@forth.com> - 2016-07-01 09:10 -1000
Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-07-01 19:10 -0700
Re: RfD: new double syntax "WJ" <w_a_x_man@yahoo.com> - 2016-07-02 06:23 +0000
RfD: new double syntax krishna.myneni@ccreweb.org - 2016-07-01 20:54 -0700
RfD: new double syntax krishna.myneni@ccreweb.org - 2016-07-01 21:18 -0700
Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-07-01 22:26 -0700
Re: RfD: new double syntax "WJ" <w_a_x_man@yahoo.com> - 2016-07-02 22:32 +0000
Re: RfD: new double syntax rickman <gnuarm@gmail.com> - 2016-07-03 01:16 -0400
Re: RfD: new double syntax Ron Aaron <rambamist@gmail.com> - 2016-07-03 08:34 +0300
Re: RfD: new double syntax rickman <gnuarm@gmail.com> - 2016-07-03 03:00 -0400
Re: RfD: new double syntax Ron Aaron <rambamist@gmail.com> - 2016-07-03 10:20 +0300
Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-03 08:29 +0000
Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-07-02 23:10 -0700
Re: RfD: new double syntax Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-07-02 23:20 -0700
Re: RfD: new double syntax rickman <gnuarm@gmail.com> - 2016-07-03 03:02 -0400
Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-02 14:20 +0000
Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-02 14:11 +0000
Re: RfD: new double syntax josv@planet.nl - 2016-07-02 00:26 -0700
Re: RfD: new double syntax "Elizabeth D. Rather" <erather@forth.com> - 2016-07-01 22:22 -1000
Re: RfD: new double syntax "HAA" <someone@microsoft.com> - 2016-07-02 22:02 +1000
Re: RfD: new double syntax "Elizabeth D. Rather" <erather@forth.com> - 2016-07-02 11:19 -1000
Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-02 14:02 +0000
Re: RfD: new double syntax Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-02 04:03 -0500
Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-02 13:44 +0000
Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-07-02 07:38 -0700
Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-07-02 07:42 -0700
Re: RfD: new double syntax "WJ" <w_a_x_man@yahoo.com> - 2016-07-02 22:44 +0000
Re: RfD: new double syntax Cecil Bayona <cbayona@cbayona.com> - 2016-07-02 09:58 -0500
Re: RfD: new double syntax "Elizabeth D. Rather" <erather@forth.com> - 2016-07-02 11:32 -1000
Re: RfD: new double syntax "WJ" <w_a_x_man@yahoo.com> - 2016-07-03 00:27 +0000
Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-07-04 08:05 -0700
Re: RfD: new double syntax Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-04 03:50 -0500
Re: RfD: new double syntax Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-04 03:53 -0500
Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-02 17:32 +0000
Re: RfD: new double syntax Julian Fondren <julian.fondren@gmail.com> - 2016-07-02 10:52 -0700
Re: RfD: new double syntax krishna.myneni@ccreweb.org - 2016-07-02 13:03 -0700
Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-03 15:02 +0000
Re: RfD: new double syntax Julian Fondren <julian.fondren@gmail.com> - 2016-07-03 11:18 -0700
Re: RfD: new double syntax Coos Haak <chforth@hccnet.nl> - 2016-07-03 21:19 +0200
Re: RfD: new double syntax Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-07-03 11:36 +0100
Re: RfD: new double syntax Gerard Sontag <gerardsontag@gmail.com> - 2016-07-03 06:58 -0700
Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-03 14:21 +0000
Re: RfD: new double syntax Gerard Sontag <gerardsontag@gmail.com> - 2016-07-03 07:55 -0700
Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-07-03 08:08 -0700
Dealing with multiple recognizers (was: RfD: new double syntax) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-03 15:13 +0000
Re: Dealing with multiple recognizers (was: RfD: new double syntax) hughaguilar96@gmail.com - 2016-07-03 09:57 -0700
Re: RfD: new double syntax rickman <gnuarm@gmail.com> - 2016-07-05 01:12 -0400
Re: RfD: new double syntax Gerard Sontag <gerardsontag@gmail.com> - 2016-07-05 07:56 -0700
Re: RfD: new double syntax rickman <gnuarm@gmail.com> - 2016-07-05 11:18 -0400
Re: RfD: new double syntax JennyB <jennybrien@googlemail.com> - 2016-07-03 08:15 -0700
Re: RfD: new double syntax Cecil Bayona <cbayona@cbayona.com> - 2016-07-03 12:42 -0500
Re: RfD: new double syntax "Elizabeth D. Rather" <erather@forth.com> - 2016-07-03 09:32 -1000
Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-07-04 07:34 -0700
Re: RfD: new double syntax Julian Fondren <julian.fondren@gmail.com> - 2016-07-04 10:35 -0700
Re: RfD: new double syntax Julian Fondren <julian.fondren@gmail.com> - 2016-07-04 09:00 -0700
Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-07-04 09:51 -0700
Re: RfD: new double syntax Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-04 11:20 -0500
Re: RfD: new double syntax Howerd <howerdo@yahoo.co.uk> - 2016-07-06 04:08 -0700
Re: RfD: new double syntax Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-06 06:24 -0500
Re: RfD: new double syntax Alex McDonald <alex@rivadpm.com> - 2016-07-06 12:38 +0100
Re: RfD: new double syntax Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-06 06:46 -0500
Re: RfD: new double syntax Howerd <howerdo@yahoo.co.uk> - 2016-07-06 13:37 -0700
Re: RfD: new double syntax Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-07 03:28 -0500
Re: RfD: new double syntax Bernd Paysan <bernd.paysan@gmx.de> - 2016-08-04 23:59 +0000
Re: RfD: new double syntax Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-04 19:26 -0500
Re: RfD: new double syntax Paul Rubin <no.email@nospam.invalid> - 2016-08-04 17:34 -0700
Re: RfD: new double syntax franck.bensusan@gmail.com - 2016-08-05 02:57 -0700
Re: RfD: new double syntax Paul Rubin <no.email@nospam.invalid> - 2016-08-05 13:15 -0700
Re: RfD: new double syntax franck.bensusan@gmail.com - 2016-08-06 01:56 -0700
Re: RfD: new double syntax Paul Rubin <no.email@nospam.invalid> - 2016-08-07 17:22 -0700
Re: RfD: new double syntax franck.bensusan@gmail.com - 2016-08-08 04:56 -0700
Re: RfD: new double syntax josv@planet.nl - 2016-08-08 08:50 -0700
Re: RfD: new double syntax franck.bensusan@gmail.com - 2016-08-08 12:26 -0700
Re: RfD: new double syntax josv@planet.nl - 2016-08-08 15:41 -0700
Re: RfD: new double syntax mhx@iae.nl - 2016-08-08 23:06 -0700
Re: RfD: new double syntax josv@planet.nl - 2016-08-09 00:57 -0700
Re: RfD: new double syntax franck.bensusan@gmail.com - 2016-08-09 03:05 -0700
Re: RfD: new double syntax hughaguilar96@gmail.com - 2016-08-10 01:46 -0700
Re: RfD: new double syntax Paul Rubin <no.email@nospam.invalid> - 2016-08-10 19:07 -0700
Re: RfD: new double syntax franck.bensusan@gmail.com - 2016-08-11 05:24 -0700
Re: RfD: new double syntax josv@planet.nl - 2016-08-06 04:50 -0700
Re: RfD: new double syntax Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-05 12:01 -0500
Re: RfD: new double syntax Cecil Bayona <cbayona@cbayona.com> - 2016-07-04 08:51 -0500
Re: RfD: new double syntax Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-04 04:03 -0500
Re: RfD: new double syntax anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-03 14:56 +0000
Re: RfD: new double syntax Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-07-03 22:00 +0100
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-07-04 10:35 -0700 |
| Message-ID | <80c2af3b-ee94-4bee-9f40-7c909f7e04e6@googlegroups.com> |
| In reply to | #48761 |
On Monday, July 4, 2016 at 11:51:13 AM UTC-5, hughag...@gmail.com wrote: > AFAIK, there is no example of Julian Fondren ever posting any Forth code on comp.lang.forth --- nor is there any Forth code written by Julian Fondren to be found anywhere --- Julian Fondren is not a Forth programmer. Here you go: http://gavino.minimaltype.com/postbanner.txt is CGI behind world-famous "a dynamic website like ...", http://gavino.minimaltype.com/ Copyright 2016 (C) me. All rights reserved. Potential hostnames (original ideas -- do not steal): banner.ninja banner.host banner.io bann.ir ba.nn.er.icio.us I understand that all of the hurtful and true things that I'm saying about you make it *seem* like I am attacking you, but I am *really* attacking Sesille. Please do not get too agitated about it. -- Julian
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-07-04 09:00 -0700 |
| Message-ID | <eeae8947-3de4-451f-b7ce-d70a34d13392@googlegroups.com> |
| In reply to | #48761 |
On Monday, July 4, 2016 at 8:51:50 AM UTC-5, Cecil - k5nwa wrote: > On 7/4/2016 4:03 AM, Andrew Haley wrote: > > Cecil Bayona <cbayona@cbayona.com> wrote: > >> > >> There is a programming concept called concurrency, > > > > Gosh, really? > > There is a wide variety of programmers on this list including many that > although they claim to be "Expert Forth Programmers", have never created > any reasonable application. Myself, I don't claim to be an expert Forth > programmer, although I have written various programs in Forth and other > languages in the past and will continue to do so in the future. And yes > really, it seems to be a concept that escapes many "Forth Programmers", > along with a list of many other concepts, that are not part of "the > spirit of Forth", that does sound religious doesn't it. "That you mock me means that *you* are the one worthy of mocking!", the paragraph. Framed and dated, 4 July 2016. Belongs in a museum. This is usenet, not a list. > So is "User Variables" in the Forth Standard? Concurrency isn't part of the standard, so the standard also fails to describe features that are only of use to concurrency. But Forth is old enough to have been a multi-user system in the mainframe sense; there is a tradition that includes concurrency and user variables are part of it. If you'd flipped through clf's postings for Ms. Rather's input on ANS Forth, instead of for Hugh's input on it, you'd already know that the response to your embarrassing continued attempt at mockery (the scare quotes are cute, super-cute) would be in the vein of "the standard isn't a straightjacket." It does not prohibit concurrency. This is not unusual. Please pause here to survey ALL STANDARDIZED LANGUAGES. > > Maybe it's "locals" that is being referred to, but they are messy, > create them, copy the original values into them, maybe change them, but > what about the existing code in the compiler, they have no clue that one > is using a new private copy, very messy. Perhaps maybe "quotation" will > come to the rescue here so a routine can read it's parent local > variables, but sadly no, what is being pushed has no guarantee of > accessing the parents local variables, so we are still messy. > I can't make sense enough of this vomit to answer it completely, but you seem to think that locals (no need for scare quotes here either; they're standard and completely mundane) require care in the presence of concurrency. They do not. > It's a sad day, in Forth Land, no wonder so many persons here are cranky. Write something in Forth and stop putting any stock in Hugh's rants, and you'll feel better in no time :) -- Julian
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-04 09:51 -0700 |
| Message-ID | <080b4141-b54d-4180-a06c-46e92fdb6344@googlegroups.com> |
| In reply to | #48782 |
On Monday, July 4, 2016 at 9:00:25 AM UTC-7, Julian Fondren wrote: > On Monday, July 4, 2016 at 8:51:50 AM UTC-5, Cecil - k5nwa wrote: > > On 7/4/2016 4:03 AM, Andrew Haley wrote: > > > Cecil Bayona <cbayona@cbayona.com> wrote: > > >> > > >> There is a programming concept called concurrency, > > > > > > Gosh, really? > > > > There is a wide variety of programmers on this list including many that > > although they claim to be "Expert Forth Programmers", have never created > > any reasonable application. Myself, I don't claim to be an expert Forth > > programmer, although I have written various programs in Forth and other > > languages in the past and will continue to do so in the future. And yes > > really, it seems to be a concept that escapes many "Forth Programmers", > > along with a list of many other concepts, that are not part of "the > > spirit of Forth", that does sound religious doesn't it. > > "That you mock me means that *you* are the one worthy of mocking!", > the paragraph. Framed and dated, 4 July 2016. Belongs in a museum. AFAIK, there is no example of Julian Fondren ever posting any Forth code on comp.lang.forth --- nor is there any Forth code written by Julian Fondren to be found anywhere --- Julian Fondren is not a Forth programmer. The same can be said of Elizabeth Rather --- all of the Forth code that she has posted on comp.lang.forth was copied directly out of the "Starting Forth" book. > > So is "User Variables" in the Forth Standard? > > Concurrency isn't part of the standard, so the standard also fails to > describe features that are only of use to concurrency. But Forth is > old enough to have been a multi-user system in the mainframe sense; > there is a tradition that includes concurrency and user variables are > part of it. > > If you'd flipped through clf's postings for Ms. Rather's input on ANS > Forth, instead of for Hugh's input on it, you'd already know that the > response to your embarrassing continued attempt at mockery (the scare > quotes are cute, super-cute) would be in the vein of "the standard > isn't a straightjacket." It does not prohibit concurrency. This is > not unusual. Please pause here to survey ALL STANDARDIZED LANGUAGES. It has been well known for decades, and every C programmer agrees, that one of the major failings of ANSI-C is that it doesn't support concurrency --- there are no user-variables in C as there are in Forth --- this was a big argument in favor of Forth over C back in the old days when this argument was still being made seriously, before ANS-Forth torpedoed the Forth community.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-07-04 11:20 -0500 |
| Message-ID | <wp-dnb1M3Ot7EefKnZ2dnUU7-KHNnZ2d@supernews.com> |
| In reply to | #48761 |
Cecil Bayona <cbayona@cbayona.com> wrote: > On 7/4/2016 4:03 AM, Andrew Haley wrote: >> Cecil Bayona <cbayona@cbayona.com> wrote: >>> On 7/3/2016 8:58 AM, Gerard Sontag wrote: >>>> Hello from an unexperience reader, >>>> Why not create a new VARIABLE (name TBD) which will contain the preferred char indicating double. >>>> The point character would be the default value letting old programs running. >>>> For those who want to use another char it will be set at the beginning. >>>> Candidates (for me) are underscore, caret and backslash >>> >>> There is a programming concept called concurrency, >> >> Gosh, really? > > There is a wide variety of programmers on this list including many > that although they claim to be "Expert Forth Programmers", have > never created any reasonable application. Myself, I don't claim to > be an expert Forth programmer, although I have written various > programs in Forth and other languages in the past and will continue > to do so in the future. And yes really, it seems to be a concept > that escapes many "Forth Programmers", along with a list of many > other concepts, that are not part of "the spirit of Forth", that > does sound religious doesn't it. It sounds positively loopy. >>> it allows a set of code to be simultaneously be executed by separate >>> threads, a very useful thing. The gist of it does not allow for >>> fixed variables to determine the state of code, as two copies of the >>> code running at the same time might need different set of states. >> >> It's a USER variable. USER variables have been in Forth since the >> early 1970s. They are very far from messy, and are a fundamental part >> of Forth design. They are fast, easy to use, and avoid the problem of >> passing state on the stack. > > So is "User Variables" in the Forth Standard? No. There is little mention of concurrency in the standard. > I ask because there isn't a single mention of it in the "Standard", > I'm aware what they were, but are they approved anymore? I'm not sure that they've ever been approved: they are, however, in widespread use. > If they were they would be in the "Standard", maybe my computer has > a search problem and can't find the subject in the "Standards" > document. Would not defining user variables involve carnal knowledge > of the compiler internals, Oh yes. > a no,no since it's not in the "spirit of Forth"? No. > And in an embedded applications, are we to have multitude of pages > of local variables where there is little to no RAM available? That's up to you when you write your application. Of course, an embedded application on a small system doesn't need to have the full system. However, I don't hink that I've seem many embedded application which didn't have multiple tasks, even on systems with very litte memory. > Maybe it's "locals" that is being referred to, Eh? No. USER variables. Each task has a bunch of them, obviously. https://www.forth.com/starting-forth/9-forth-execution/#User_Variables-2 Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Howerd <howerdo@yahoo.co.uk> |
|---|---|
| Date | 2016-07-06 04:08 -0700 |
| Message-ID | <a6f5120a-1b1d-4884-a0e7-d73237fef3a0@googlegroups.com> |
| In reply to | #48786 |
Hi Andrew, > > So is "User Variables" in the Forth Standard? > No. There is little mention of concurrency in the standard. This concerns me. I have used multitasking in almost every Forth program that I have written since about 1979, starting with microForth for the CDP1802. The Forth, Inc. multitasker has more or less the same API from those days, and VFX and Win32Forth are almost identical. When I talk about the amazing productivity that I get with Forth, I am implicitly assuming TASK , ACTIVATE , PAUSE and MS. Are these really not part of ANS Forth? Is there any reason why they could not be added? Maybe I have missed a discussion about this on clf? Best regards, Howerd On Monday, 4 July 2016 17:20:59 UTC+1, Andrew Haley wrote: > Cecil Bayona <cba....@cbayona.com> wrote: > > On 7/4/2016 4:03 AM, Andrew Haley wrote: > >> Cecil Bayona <cba....@cbayona.com> wrote: > >>> On 7/3/2016 8:58 AM, Gerard Sontag wrote: > >>>> Hello from an unexperience reader, > >>>> Why not create a new VARIABLE (name TBD) which will contain the preferred char indicating double. > >>>> The point character would be the default value letting old programs running. > >>>> For those who want to use another char it will be set at the beginning. > >>>> Candidates (for me) are underscore, caret and backslash > >>> > >>> There is a programming concept called concurrency, > >> > >> Gosh, really? > > > > There is a wide variety of programmers on this list including many > > that although they claim to be "Expert Forth Programmers", have > > never created any reasonable application. Myself, I don't claim to > > be an expert Forth programmer, although I have written various > > programs in Forth and other languages in the past and will continue > > to do so in the future. And yes really, it seems to be a concept > > that escapes many "Forth Programmers", along with a list of many > > other concepts, that are not part of "the spirit of Forth", that > > does sound religious doesn't it. > > It sounds positively loopy. > > >>> it allows a set of code to be simultaneously be executed by separate > >>> threads, a very useful thing. The gist of it does not allow for > >>> fixed variables to determine the state of code, as two copies of the > >>> code running at the same time might need different set of states. > >> > >> It's a USER variable. USER variables have been in Forth since the > >> early 1970s. They are very far from messy, and are a fundamental part > >> of Forth design. They are fast, easy to use, and avoid the problem of > >> passing state on the stack. > > > > So is "User Variables" in the Forth Standard? > > No. There is little mention of concurrency in the standard. > > > I ask because there isn't a single mention of it in the "Standard", > > I'm aware what they were, but are they approved anymore? > > I'm not sure that they've ever been approved: they are, however, in > widespread use. > > > If they were they would be in the "Standard", maybe my computer has > > a search problem and can't find the subject in the "Standards" > > document. Would not defining user variables involve carnal knowledge > > of the compiler internals, > > Oh yes. > > > a no,no since it's not in the "spirit of Forth"? > > No. > > > And in an embedded applications, are we to have multitude of pages > > of local variables where there is little to no RAM available? > > That's up to you when you write your application. Of course, an > embedded application on a small system doesn't need to have the full > system. However, I don't hink that I've seem many embedded > application which didn't have multiple tasks, even on systems with > very litte memory. > > > Maybe it's "locals" that is being referred to, > > Eh? No. USER variables. Each task has a bunch of them, obviously. > > https://www.forth.com/starting-forth/9-forth-execution/#User_Variables-2 > > Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-07-06 06:24 -0500 |
| Message-ID | <242dnSgH_PDmd-HKnZ2dnUU7-fvNnZ2d@supernews.com> |
| In reply to | #48830 |
Hi, Howerd <howerdo@yahoo.co.uk> wrote: > When I talk about the amazing productivity that I get with Forth, I > am implicitly assuming TASK , ACTIVATE , PAUSE and MS. Are these > really not part of ANS Forth? Is there any reason why they could not > be added? I don't think so, but defining the semantics of multiple threads isn't a task for the faint-hearted. These days you often have multiple hardware threads, so you'd also have to define things like GET and RELEASE, and maybe also things like compare-and-swap. You'd also have to think about how words like BLOCK interact with hardware threads. (Aside: I have a design for BLOCK that works correctly even in the presence of hardware threads, but I'm guessing that with modern virtual memory no-one cares any more.) It would be nice. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <alex@rivadpm.com> |
|---|---|
| Date | 2016-07-06 12:38 +0100 |
| Message-ID | <nliqjf$lk6$1@dont-email.me> |
| In reply to | #48831 |
On 06/07/16 12:24, Andrew Haley wrote: > Hi, > > Howerd <howerdo@yahoo.co.uk> wrote: > >> When I talk about the amazing productivity that I get with Forth, I >> am implicitly assuming TASK , ACTIVATE , PAUSE and MS. Are these >> really not part of ANS Forth? Is there any reason why they could not >> be added? > > I don't think so, but defining the semantics of multiple threads isn't > a task for the faint-hearted. These days you often have multiple > hardware threads, so you'd also have to define things like GET and > RELEASE, and maybe also things like compare-and-swap. You'd also have > to think about how words like BLOCK interact with hardware threads. > (Aside: I have a design for BLOCK that works correctly even in the > presence of hardware threads, but I'm guessing that with modern > virtual memory no-one cares any more.) > > It would be nice. > > Andrew. > POSIX threads is pretty heavyweight but a good place to start, since there is a lot of experience with pthreads libraries; http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/pthread.h.html -- -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-07-06 06:46 -0500 |
| Message-ID | <3KednZS9PfIdcuHKnZ2dnUU7-L_NnZ2d@supernews.com> |
| In reply to | #48832 |
Alex McDonald <alex@rivadpm.com> wrote: > > POSIX threads is pretty heavyweight but a good place to start, since > there is a lot of experience with pthreads libraries; > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/pthread.h.html I guess it's a point of departure, but as Dijkstra once said, "...if you intend to use [it] 'as a basis for departure', I can only recommend that you depart from it as far as possible." As well as being large, pthreads is also incomplete: it's only very recently that the C language specification has been upgraded to cope with concurrent access to data in memory. I would have thought that the traditional Forth multi-tasking wordsets were a much better place to start. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Howerd <howerdo@yahoo.co.uk> |
|---|---|
| Date | 2016-07-06 13:37 -0700 |
| Message-ID | <137c0d40-1d37-4e78-94e2-86f70ea975b1@googlegroups.com> |
| In reply to | #48831 |
Hi Andrew, Maybe we can simply ignore multiple hardware cores as far as ANS Forth is concerned - for the jobs that require major computing power you would probably want to optimise carefully, and for everything else one core would probably suffice. I had forgotten to mention GET and RELEASE - they are very useful for sharing hardware resources, but I'm not sure that they should be used to wrap multiple cores. In my simplistic view multiple cores sit below Forth, and hardware resources sit above, if you see what I mean. In other words, the Forth, Inc./VFX/Win32Forth multi-tasking word set is sufficient for all of my multi-tasking needs, on a single core. > I have a design for BLOCK that works correctly even in the > presence of hardware threads Is this your transactional memory implementation? The ability to guarantee completion of sections of code running on any physically separate processors could be very useful - I've been investigating the Ethereum Virtual Machine recently - I'm not sure that they have got this right yet. Perhaps we can define the names and API ( atomic and previous ? ) and fill in the details later. This would seem to be a more suitable wrapper for multiple cores. As I write this I get the feeling that I am sticking my head above the parapet, so here is a disclaimer : my income comes from the companies listed in my CV (http://www.inventio.co.uk/HowerdOakfordCV.rtf) , and my opinions are not influenced by any of the people and companies mentioned above except through reasoned argument and discussion. I have never been on the ANS committee, but I would like ANS Forth to reflect the functionality that I actually use when I program in Forth. Also, I'm not particularly interested in Ocaml or Lisp. Just sayin'. Best regards, Howerd On Wednesday, 6 July 2016 12:24:49 UTC+1, Andrew Haley wrote: > Hi, > > Howerd <howxxxx@yahoo.co.uk> wrote: > > > When I talk about the amazing productivity that I get with Forth, I > > am implicitly assuming TASK , ACTIVATE , PAUSE and MS. Are these > > really not part of ANS Forth? Is there any reason why they could not > > be added? > > I don't think so, but defining the semantics of multiple threads isn't > a task for the faint-hearted. These days you often have multiple > hardware threads, so you'd also have to define things like GET and > RELEASE, and maybe also things like compare-and-swap. You'd also have > to think about how words like BLOCK interact with hardware threads. > (Aside: I have a design for BLOCK that works correctly even in the > presence of hardware threads, but I'm guessing that with modern > virtual memory no-one cares any more.) > > It would be nice. > > Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-07-07 03:28 -0500 |
| Message-ID | <yNydnaBgndYoj-PKnZ2dnUU7-TednZ2d@supernews.com> |
| In reply to | #48842 |
Howerd <howerdo@yahoo.co.uk> wrote: > Hi Andrew, > > Maybe we can simply ignore multiple hardware cores as far as ANS > Forth is concerned - for the jobs that require major computing power > you would probably want to optimise carefully, and for everything > else one core would probably suffice. I don't think we can do that. Multi-cores are so important that it wouldn't have made sense to ignore them 20 years ago, let alone today. >> I have a design for BLOCK that works correctly even in the >> presence of hardware threads > Is this your transactional memory implementation? No, it's much more lightewight than that. > The ability to guarantee completion of sections of code running on > any physically separate processors could be very useful - I've been > investigating the Ethereum Virtual Machine recently - I'm not sure > that they have got this right yet. Perhaps we can define the names > and API ( atomic and previous ? ) and fill in the details later. > This would seem to be a more suitable wrapper for multiple cores. Transactions are super-clean and simple to use, and the result is (to my eye) the first way of programming shared memory multiprocessors which looks reasonably Forthly. But TM hasn't caught on as I would have expected. On the gripping hand, there is transactional hardware on the horizon. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-08-04 23:59 +0000 |
| Message-ID | <no0ks6$ms7$1@dont-email.me> |
| In reply to | #48892 |
Am Thu, 07 Jul 2016 03:28:37 -0500 schrieb Andrew Haley: > Transactions are super-clean and simple to use, and the result is (to my > eye) the first way of programming shared memory multiprocessors which > looks reasonably Forthly. But TM hasn't caught on as I would have > expected. On the gripping hand, there is transactional hardware on the > horizon. Well, Intel managed to screw them up when they first tried to implement them... and screwed up again with the second generation; now in Skylake (third time), they disabled it again! This sort of stuff is always a set- back. And with Intel's IBM-style policy of enabling and disabling things depending on the expected audience, you will see a lot of fragmentation. Maybe AMD will give us TM in the Zen processors, without requiring us to buy the server part, but we don't know. AMD put STM on the table in 2009 with some limited, but easy to implement primitives. -- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-08-04 19:26 -0500 |
| Message-ID | <ap6dnUD07KOqQD7KnZ2dnUU78TvNnZ2d@supernews.com> |
| In reply to | #49792 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Am Thu, 07 Jul 2016 03:28:37 -0500 schrieb Andrew Haley: >> Transactions are super-clean and simple to use, and the result is (to my >> eye) the first way of programming shared memory multiprocessors which >> looks reasonably Forthly. But TM hasn't caught on as I would have >> expected. On the gripping hand, there is transactional hardware on the >> horizon. > > Well, Intel managed to screw them up when they first tried to > implement them... and screwed up again with the second generation; > now in Skylake (third time), they disabled it again! This sort of > stuff is always a set- back. And with Intel's IBM-style policy of > enabling and disabling things depending on the expected audience, > you will see a lot of fragmentation. Maybe AMD will give us TM in > the Zen processors, without requiring us to buy the server part, but > we don't know. AMD put STM on the table in 2009 with some limited, > but easy to implement primitives. Indeed. And the first reasonably efficient way to turn small hardware transactions into larger software transactions has only just been invented. [1] So, it's early days, but IMO transactional memory is the first glimpse of sanity in the ever-more-complex world of shared- memory concurrent computing. Andrew. [1] people.csail.mit.edu/amatveev/RH_NOrec_ASPLOS2015.pdf
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-08-04 17:34 -0700 |
| Message-ID | <87eg643vfe.fsf@jester.gateway.pace.com> |
| In reply to | #48892 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > But TM hasn't caught on as I would have expected. The situation seems to be that it's clean and it works, but the slowdown gets bad once there are lots of cores and lots of contention. I've been hearing of some improved approaches, but who knows. [Some of] the Erlang guys have felt for a long while that shared memory is ultimately doomed, as core counts increase and cache interlocks get more and more complicated. So they want to use message passing for everything. OTOH the current BEAM (Erlang) VM uses message passing for small objects, but (limited) shared memory for certain large ones.
[toc] | [prev] | [next] | [standalone]
| From | franck.bensusan@gmail.com |
|---|---|
| Date | 2016-08-05 02:57 -0700 |
| Message-ID | <c36a5699-52ab-4b74-a837-96bd05b237ae@googlegroups.com> |
| In reply to | #49796 |
Le vendredi 5 août 2016 02:34:46 UTC+2, Paul Rubin a écrit : > The situation seems to be that it's clean and it works, but the slowdown > gets bad once there are lots of cores and lots of contention. I've been > hearing of some improved approaches, but who knows. > > [Some of] the Erlang guys have felt for a long while that shared memory > is ultimately doomed, as core counts increase and cache interlocks get > more and more complicated. So they want to use message passing for > everything. OTOH the current BEAM (Erlang) VM uses message passing for > small objects, but (limited) shared memory for certain large ones. Hi, imo, what is doomed is not shared memory but shared mutable memory. In Oforth, an object can be shared between tasks only if it is immutable. So there is no need for locks, mutex, ... But I find Erlang principles quite conservative as they copy each object they pass to another task. Even if I understand the benefits, I can't resign myself to this... For me, being able to share immutable objects between tasks without the need of copy them seems a good trade-off. Franck
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-08-05 13:15 -0700 |
| Message-ID | <87a8gr3rbn.fsf@jester.gateway.pace.com> |
| In reply to | #49801 |
franck.bensusan@gmail.com writes: > But I find Erlang principles quite conservative as they copy each object > they pass to another task. Even if I understand the benefits, I can't > resign myself to this... I think I saw some benchmarks showing the copying cost was not that much. There are some optimizations like sharing of large binaries (what other languages would call strings), and ETS tables are somehow shared behind the scenes in ways that are invisible to the client processes. The benefit is that each process has its own GC, so the individual heaps are small and some processes can run while others GC, minimizing latency. Erlang is supposed to be a soft real-time system so they are willing to take some amortized overhead in order to minimize latency.
[toc] | [prev] | [next] | [standalone]
| From | franck.bensusan@gmail.com |
|---|---|
| Date | 2016-08-06 01:56 -0700 |
| Message-ID | <28090ffe-12b9-4365-b0b8-c8b800f20f93@googlegroups.com> |
| In reply to | #49803 |
Le vendredi 5 août 2016 22:15:42 UTC+2, Paul Rubin a écrit : > franck.bensusan@gmail.com writes: > > But I find Erlang principles quite conservative as they copy each object > > they pass to another task. Even if I understand the benefits, I can't > > resign myself to this... > > I think I saw some benchmarks showing the copying cost was not that > much. There are some optimizations like sharing of large binaries (what > other languages would call strings), and ETS tables are somehow shared > behind the scenes in ways that are invisible to the client processes. > The benefit is that each process has its own GC, so the individual heaps > are small and some processes can run while others GC, minimizing > latency. Erlang is supposed to be a soft real-time system so they are > willing to take some amortized overhead in order to minimize latency. My point is not so much about performances but about memory needed for copying those objects. This model consumes extra resources where this is not absolutely necessary. Maybe it's me, but I have a problem with this... As for latency, an incremental GC (like in Oforth now ) allows to keep all tasks running while the GC is performed. The only latency is during the initial snapshot, but it is quite fast as only root objects are "snapshoted" (not attributes of those objects). All in all, immutability for task isolation and an incremental GC to minimize latency is, for me, a model that can compare well with an Erlang-like model.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-08-07 17:22 -0700 |
| Message-ID | <87lh082jpk.fsf@jester.gateway.pace.com> |
| In reply to | #49810 |
franck.bensusan@gmail.com writes: >> Erlang is supposed to be a soft real-time system > My point is not so much about performances but about memory > needed for copying those objects. It's not bad in practice. Most processes don't keep much state around. They pass small bits of data to other processes for RPC-like services, or (example: i/o ports) data gets passed to another process and is no longer needed by the first process. Occasional large chunks of shared data are typically stored in ETS tables. Erlang was never for small microcontrollers, but has been used in systems with maybe a few tens of MB of memory, which is modest by today's standards. That's running 1000s of processes, by the way. Lately I'm looking at http://www.seastar-project.org/ which is a message passing-based system for concurrent C++ programs. I haven't tried it but it looks interesting.
[toc] | [prev] | [next] | [standalone]
| From | franck.bensusan@gmail.com |
|---|---|
| Date | 2016-08-08 04:56 -0700 |
| Message-ID | <a8ecee86-6d0e-44ba-8993-85b09d6dfb32@googlegroups.com> |
| In reply to | #49861 |
Le lundi 8 août 2016 02:22:17 UTC+2, Paul Rubin a écrit : > franck.bensusan@gmail.com writes: > >> Erlang is supposed to be a soft real-time system > > My point is not so much about performances but about memory > > needed for copying those objects. > > It's not bad in practice. Most processes don't keep much state around. > They pass small bits of data to other processes for RPC-like services, > or (example: i/o ports) data gets passed to another process and is no > longer needed by the first process. Occasional large chunks of shared > data are typically stored in ETS tables. Even if it is not bad, I don't see any reason to choose this model compared to immutability + incremental GC. I don't see the "great feature" that this model brings which balance those resources usage (or the big drawback of the other model). > Erlang was never for small > microcontrollers, but has been used in systems with maybe a few tens of > MB of memory, which is modest by today's standards. That's running > 1000s of processes, by the way. Oforth has a small task/channel model that also allows to run big amount of tasks in parallel with limited memory. For instance : import: parallel #sqrt 10000 seq mapParallel sum .s [1] (Float) 666716.459197108 Here, 10000 tasks are running in parallel, each calculating #sqrt for one integer and returning the result. Running those 10000 tasks consume about 25Mo. In this case, this could be less by creating explicitely the tasks with a smaller data stack size (each task default data stack allows to push 200 objects). Ok, that is not the best way to calculate sum of sqrt for 1 to 10000 :) > Lately I'm looking at http://www.seastar-project.org/ which is a message > passing-based system for concurrent C++ programs. I haven't tried it > but it looks interesting. This looks interesting, I will look at it (but I don't like to directly expose the cores at the API level). Franck http://www.oforth.com
[toc] | [prev] | [next] | [standalone]
| From | josv@planet.nl |
|---|---|
| Date | 2016-08-08 08:50 -0700 |
| Message-ID | <9380db73-6755-461a-8111-301519f21795@googlegroups.com> |
| In reply to | #49874 |
> (but I don't like to directly expose the cores at the API level). How many cores does your system have? Jos August 8th, 2016 13:56:43 UTC+2 franck...com wrote: > Le lundi 8 août 2016 02:22:17 UTC+2, Paul Rubin a écrit : > > frank...com writes: > > >> Erlang is supposed to be a soft real-time system > > > My point is not so much about performances but about memory > > > needed for copying those objects. > > > > It's not bad in practice. Most processes don't keep much state around. > > They pass small bits of data to other processes for RPC-like services, > > or (example: i/o ports) data gets passed to another process and is no > > longer needed by the first process. Occasional large chunks of shared > > data are typically stored in ETS tables. > > Even if it is not bad, I don't see any reason to choose this model > compared to immutability + incremental GC. I don't see the "great > feature" that this model brings which balance those resources usage > (or the big drawback of the other model). > > > Erlang was never for small > > microcontrollers, but has been used in systems with maybe a few tens of > > MB of memory, which is modest by today's standards. That's running > > 1000s of processes, by the way. > > Oforth has a small task/channel model that also allows to run big amount > of tasks in parallel with limited memory. For instance : > > import: parallel > > #sqrt 10000 seq mapParallel sum .s > [1] (Float) 666716.459197108 > > Here, 10000 tasks are running in parallel, each calculating #sqrt > for one integer and returning the result. > > Running those 10000 tasks consume about 25Mo. In this case, this could > be less by creating explicitely the tasks with a smaller data stack size > (each task default data stack allows to push 200 objects). > > Ok, that is not the best way to calculate sum of sqrt for 1 to 10000 :) > > > Lately I'm looking at http://www.seastar-project.org/ which is a message > > passing-based system for concurrent C++ programs. I haven't tried it > > but it looks interesting. > > This looks interesting, I will look at it (but I don't like to directly expose > the cores at the API level). > > Franck > http://www.oforth.com
[toc] | [prev] | [next] | [standalone]
| From | franck.bensusan@gmail.com |
|---|---|
| Date | 2016-08-08 12:26 -0700 |
| Message-ID | <266b9654-2405-406e-9cf1-18a9f8480d17@googlegroups.com> |
| In reply to | #49875 |
Le lundi 8 août 2016 17:50:28 UTC+2, jo...@planet.nl a écrit : > > (but I don't like to directly expose the cores at the API level). > > How many cores does your system have? > > Jos > You mean my laptop ? I'm not sure to understand how this is related to my previous post but it is a Core i7 with 4 physical cores and 8 threads (hyperthreading). (when I ask the OS how many processors the system have, it answers 8). Franck
[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