Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #48085 > unrolled thread
| Started by | Marek Brunda <marekb@phoenics.org> |
|---|---|
| First post | 2016-06-13 13:41 -0700 |
| Last post | 2016-06-26 22:41 -1000 |
| Articles | 20 on this page of 116 — 28 participants |
Back to article view | Back to comp.lang.forth
Is it sill FORTH ? Marek Brunda <marekb@phoenics.org> - 2016-06-13 13:41 -0700
Re: Is it sill FORTH ? crc <charles.childers@gmail.com> - 2016-06-13 13:57 -0700
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-13 15:18 -0700
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-13 15:34 -0700
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-13 15:37 -0700
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-06-13 15:45 -0700
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-13 15:54 -0700
Re: Is it sill FORTH ? Coos Haak <chforth@hccnet.nl> - 2016-06-14 01:41 +0200
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-13 16:48 -0700
Re: Is it sill FORTH ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-14 03:24 -0500
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-14 02:53 -0700
Re: Is it sill FORTH ? Coos Haak <chforth@hccnet.nl> - 2016-06-14 01:53 +0200
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-13 17:25 -0700
Re: Is it sill FORTH ? Marek Brunda <marekb@phoenics.org> - 2016-06-13 22:23 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-14 03:13 -0400
VALUE Lars Brinkhoff <lars.spam@nocrew.org> - 2016-06-14 09:17 +0200
Re: Is it sill FORTH ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-14 03:51 -0500
Re: Is it sill FORTH ? Marek Brunda <marekb@phoenics.org> - 2016-06-14 02:45 -0700
Re: Is it sill FORTH ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-15 04:21 -0500
Re: Is it sill FORTH ? Brad Eckert <hwfwguy@gmail.com> - 2016-08-05 21:02 -0700
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-08-05 21:48 -1000
Re: Is it sill FORTH ? missycurl@gmail.com - 2016-08-06 05:37 -0700
Re: Is it sill FORTH ? humptydumpty <ouatubi@gmail.com> - 2016-08-06 06:37 -0700
Re: Is it sill FORTH ? Cecil Bayona <cbayona@cbayona.com> - 2016-08-06 08:53 -0500
Re: Is it sill FORTH ? humptydumpty <ouatubi@gmail.com> - 2016-08-06 07:18 -0700
Re: Is it sill FORTH ? humptydumpty <ouatubi@gmail.com> - 2016-08-06 07:40 -0700
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-08-06 15:07 -1000
Re: Is it sill FORTH ? hughaguilar96@gmail.com - 2016-08-06 19:14 -0700
Re: Is it sill FORTH ? Chris Curl <ccurl609@gmail.com> - 2016-08-07 10:38 -0700
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-08-07 20:57 -1000
Re: Is it sill FORTH ? Roelf Toxopeus <rt4all@nothishetnet.nl> - 2016-08-08 22:20 +0200
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-08-08 12:14 -1000
Re: Is it sill FORTH ? hughaguilar96@gmail.com - 2016-08-09 00:29 -0700
Re: Is it sill FORTH ? hughaguilar96@gmail.com - 2016-08-06 19:30 -0700
Re: Is it sill FORTH ? Chris Curl <ccurl609@gmail.com> - 2016-08-07 07:42 -0700
Re: Is it sill FORTH ? hughaguilar96@gmail.com - 2016-08-07 13:34 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-08-08 16:13 -0400
Re: Is it sill FORTH ? Cecil Bayona <cbayona@cbayona.com> - 2016-08-08 15:36 -0500
Re: Is it sill FORTH ? jim.brakefield@ieee.org - 2016-08-06 06:28 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-08-08 16:42 -0400
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-08-08 12:31 -1000
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-08-08 16:38 -0700
Re: Is it sill FORTH ? mhx@iae.nl - 2016-08-08 22:49 -0700
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-08-08 23:43 -0700
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-08-08 22:16 -1000
Re: Is it sill FORTH ? JUERGEN <epldfpga@aol.com> - 2016-08-09 03:54 -0700
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-14 03:42 -0700
Re: Is it sill FORTH ? Marek Brunda <marekb@phoenics.org> - 2016-06-14 04:58 -0700
Re: Is it sill FORTH ? Mark Wills <markwills1970@gmail.com> - 2016-06-14 05:04 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-13 19:22 -0400
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-14 05:22 -0700
Re: Is it sill FORTH ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-14 12:41 +0000
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-14 06:30 -0700
Re: Is it sill FORTH ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-14 14:21 +0000
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-14 13:21 -0400
Re: Is it sill FORTH ? Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-06-14 17:45 -0400
Re: Is it sill FORTH ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-14 10:55 -0500
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-13 16:38 -0700
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-06-13 16:41 -0700
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-14 03:54 -0700
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-06-14 08:14 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-14 13:24 -0400
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-14 11:03 -0700
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-06-14 12:42 -0700
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-14 13:28 -0700
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-06-14 13:42 -0700
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-14 14:47 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-14 19:37 -0400
Re: Is it sill FORTH ? Marek Brunda <marekb@phoenics.org> - 2016-06-14 17:01 -0700
Re: Is it sill FORTH ? Marek Brunda <marekb@phoenics.org> - 2016-06-14 17:06 -0700
Re: Is it sill FORTH ? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-06-15 07:57 +0200
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-06-15 16:12 +0200
Re: Is it sill FORTH ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-15 03:20 -0500
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-14 20:20 -0400
Re: Is it sill FORTH ? Marek Brunda <marekb@phoenics.org> - 2016-06-14 17:33 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-14 21:21 -0400
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-14 19:57 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-14 23:03 -0400
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-06-14 20:31 -0700
Re: Is it sill FORTH ? pahihu <pahihu@gmail.com> - 2016-06-15 01:36 -0700
Re: Is it sill FORTH ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-18 12:54 +0000
Re: Is it sill FORTH ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-18 13:28 +0000
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-18 07:17 -0700
Re: Is it sill FORTH ? lawrencedo99@gmail.com - 2016-06-18 18:31 -0700
Re: Is it sill FORTH ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-25 14:55 +0000
Re: Is it sill FORTH ? lawrencedo99@gmail.com - 2016-06-25 19:58 -0700
Re: Is it sill FORTH ? hughaguilar96@gmail.com - 2016-06-18 21:14 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-14 19:32 -0400
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-06-14 17:13 -0700
Re: Is it sill FORTH ? Marek Brunda <marekb@phoenics.org> - 2016-06-14 17:21 -0700
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-06-14 18:36 -0700
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-06-15 16:06 +0200
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-15 06:36 -0700
Re: Is it sill FORTH ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-15 09:20 -0500
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-15 10:55 -0700
Re: Is it sill FORTH ? Paul Rubin <no.email@nospam.invalid> - 2016-06-15 11:07 -0700
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-06-15 16:20 +0200
Re: Is it sill FORTH ? mhx@iae.nl - 2016-06-15 11:19 -0700
Re: Is it sill FORTH ? hughaguilar96@gmail.com - 2016-06-14 22:10 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-15 01:33 -0400
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-14 19:31 -0400
Re: Is it sill FORTH ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-06-14 11:15 +0000
Re: Is it sill FORTH ? Mark Wills <markwills1970@gmail.com> - 2016-06-14 05:02 -0700
Re: Is it sill FORTH ? Julian Fondren <julian.fondren@gmail.com> - 2016-06-15 01:44 -0700
Re: Is it sill FORTH ? Julian Fondren <ayrnieu@gmail.com> - 2016-06-15 08:31 -0700
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-15 17:10 -0700
Re: Is it sill FORTH ? Bernd Paysan <bernd.paysan@gmx.de> - 2016-08-05 01:09 +0000
Re: Is it sill FORTH ? hughaguilar96@gmail.com - 2016-06-14 00:55 -0700
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-06-14 16:15 +0200
Re: Is it sill FORTH ? hughaguilar96@gmail.com - 2016-06-15 15:43 -0700
Re: Is it sill FORTH ? krishna.myneni@ccreweb.org - 2016-06-15 17:03 -0700
Re: Is it sill FORTH ? rickman <gnuarm@gmail.com> - 2016-06-15 22:36 -0400
Re: Is it sill FORTH ? Mat <dambere@web.de> - 2016-06-26 04:14 -0700
Re: Is it sill FORTH ? Coos Haak <chforth@hccnet.nl> - 2016-06-26 14:50 +0200
Re: Is it sill FORTH ? lawrencedo99@gmail.com - 2016-06-26 18:58 -0700
Re: Is it sill FORTH ? "Elizabeth D. Rather" <erather@forth.com> - 2016-06-26 22:41 -1000
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-06-14 08:14 -0700 |
| Message-ID | <87vb1bol8z.fsf@nightsong.com> |
| In reply to | #48128 |
krishna.myneni@ccreweb.org writes: > Why not? >BODY just returns an address in memory. What I choose to do > with that address is my business, not the compiler's. Yes, but what happens when you execute the word after clobbering it is the compiler's business, not yours.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-06-14 13:24 -0400 |
| Message-ID | <njpekd$gpo$1@dont-email.me> |
| In reply to | #48128 |
On 6/14/2016 6:54 AM, krishna.myneni@ccreweb.org wrote: > On Monday, June 13, 2016 at 6:41:47 PM UTC-5, Paul Rubin wrote: >> krishna.myneni@ccreweb.org writes: >>> What does native code compilation have to do with this issue? >> >> Clobbering the >body of a word shouldn't be expected to have >> well-defined results. ... > > Why not? >BODY just returns an address in memory. What I choose to do > with that address is my business, not the compiler's. A hardware status register is an address in memory. Do you expect that to be writable too? If the address is in ROM, should the system burn a new ROM for you? I find it especially funny that you expect there to be a totally different Forth for embedded systems that works the way it makes sense, rather than the oddball way you propose. Why can't you use VALUE rather than CONSTANT? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2016-06-14 11:03 -0700 |
| Message-ID | <e4c6d624-0bd0-4d21-b6d5-ab43f87f88ad@googlegroups.com> |
| In reply to | #48155 |
I believe you are misstating the problem. Suppose you do have a hardware status register at address 0008. Then, it's perfectly reasonable to define an address constant as follows: 0008 CONSTANT HW_STATUS The issue is not about writing to the status register -- it is about remapping the register. If the system is configurable during run time so that the register can be mapped to a different address, say 001E, then changing the value of HW_STATUS makes sense. Sure, you can do it with VALUE instead of CONSTANT. Krishna
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-06-14 12:42 -0700 |
| Message-ID | <87r3bzo8vo.fsf@nightsong.com> |
| In reply to | #48156 |
krishna.myneni@ccreweb.org writes: > it is about remapping the register. ... Sure, you can do it with > VALUE instead of CONSTANT. What's the problem then? Do it with VALUE (or VARIABLE). That's what they are for.
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2016-06-14 13:28 -0700 |
| Message-ID | <7723d6a9-ef5f-47e6-9407-61a76990de74@googlegroups.com> |
| In reply to | #48157 |
Read the earlier messages in the thread carefully. The general problem is with Forth compilers doing things that are unasked for by the programmer, and which cause unexpected side effects for code which is valid on those systems. In the case of CONSTANT there may be no real cause for concern, other than making clear that inlining may be performed by a system. Krishna
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-06-14 13:42 -0700 |
| Message-ID | <87mvmno63f.fsf@nightsong.com> |
| In reply to | #48158 |
krishna.myneni@ccreweb.org writes: > The general problem is with Forth compilers doing things that are > unasked for by the programmer The whole idea of a compiler is to save the programmer effort by doing stuff automatically instead of making the programmer ask explicitly. So of course the compiler does stuff the programmer doesn't ask for--that's its job. A language translator that does only what the programmer asks is called an assembler. The programmer's valid expectations of the compiler are the ones documented in the language standard. If the standard doesn't specify some particular behaviour, then the programmer shouldn't expect a generic implementation to do it. In this case it sounds like there's a disconnect between the ANS standard and undocumented expectations formed from using older systems like Forth-83. I can't speak for users of those old systems since I never used them myself. But it never would have occurred to me that what the OP posted could reasonably be expected to work.
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2016-06-14 14:47 -0700 |
| Message-ID | <0a11b381-06c0-4e3d-9cc3-410e8a6f0d9c@googlegroups.com> |
| In reply to | #48159 |
The original Starting Forth book by Leo Brodie gives an example similar to the one posted by the OP. While the book says it is not recommended to do this, it also serves as an illustration of the ability provided by a programmer to get at the internals of the system. Having used a system from those days, it feels like the current Forth implementations, including mine, sacrificed some of that ability for the sake of efficiency, and also maybe for use in more constrained domains. It may well be a reasonable trade, but it is a legitimate concern, particularly if we have a trend towards sacrificing more and more of those abilities to get under the hood for the sake of efficiency. Krishna
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-06-14 19:37 -0400 |
| Message-ID | <njq4fv$3hn$1@dont-email.me> |
| In reply to | #48161 |
On 6/14/2016 5:47 PM, krishna.myneni@ccreweb.org wrote: > The original Starting Forth book by Leo Brodie gives an example > similar to the one posted by the OP. While the book says it is not > recommended to do this, it also serves as an illustration of the > ability provided by a programmer to get at the internals of the > system. Having used a system from those days, it feels like the > current Forth implementations, including mine, sacrificed some of > that ability for the sake of efficiency, and also maybe for use in > more constrained domains. It may well be a reasonable trade, but it > is a legitimate concern, particularly if we have a trend towards > sacrificing more and more of those abilities to get under the hood > for the sake of efficiency. "the book says it is not recommended to do this" I think that says it all. There is no trade. This "feature" was never assured to work because it depends on things being done a certain way that is contrary to the expected use of the language. I had a car that I could coast down a hill and start without hitting the starter. At one time they were all like that. Now few can be started this way and I believe they say you can do damage trying. The nerve of compiler writers, making it hard to change the value of a constant! I can't believe this is even being seriously discussed! -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Marek Brunda <marekb@phoenics.org> |
|---|---|
| Date | 2016-06-14 17:01 -0700 |
| Message-ID | <a3f630e2-ab14-4ff6-b0b0-d38be629fde6@googlegroups.com> |
| In reply to | #48164 |
I can understand all yours answers but: 1. Strictly technically - constant in this example IS NOT constant - it's value can be changed. However compiler generates the code which doesn't reflect this change. 2. System behaves differently when interpretting and at runtime 3. With respect to 1. and 2. it's unexpected behaviour 4. Using of VALUE needs to implement VALUE and TO - in resource constraint system it's not negligible 5. Why the hell using CONSTANT in this case? Easy answer: the constant is SET ONE TIME ONLY but not when defined, but at runtime, when system initializes itself. Using of VARIABLE for constant, which is initialized when the system starts is not appropriate.
[toc] | [prev] | [next] | [standalone]
| From | Marek Brunda <marekb@phoenics.org> |
|---|---|
| Date | 2016-06-14 17:06 -0700 |
| Message-ID | <07bdeb68-0d33-4255-8d78-1dab5c39d267@googlegroups.com> |
| In reply to | #48165 |
In addition - nobody here could explain, why we have VARIABLEs and VALUEs...
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2016-06-15 07:57 +0200 |
| Message-ID | <86porj0zay.fsf@molnjunk.nocrew.org> |
| In reply to | #48166 |
Marek Brunda writes: > In addition - nobody here could explain, why we have VARIABLEs and VALUEs... A link to a Forth Dimensions article was posted. The article explained why VALUE was introduced.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-06-15 16:12 +0200 |
| Message-ID | <1NSdnQFTO6L6__zKnZ2dnUU78TXNnZ2d@supernews.com> |
| In reply to | #48182 |
On 6/15/16 7:57 AM, Lars Brinkhoff wrote: > Marek Brunda writes: >> In addition - nobody here could explain, why we have VARIABLEs and VALUEs... > > A link to a Forth Dimensions article was posted. The article explained > why VALUE was introduced. > I also attempted to explain the history as well as the logic on this issue. Do you have questions about that explanation? If so, I'll be happy to answer them. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-06-15 03:20 -0500 |
| Message-ID | <WeidnXGMcZUhkvzKnZ2dnUU7-fednZ2d@supernews.com> |
| In reply to | #48166 |
Marek Brunda <marekb@phoenics.org> wrote: > In addition - nobody here could explain, why we have VARIABLEs and > VALUEs... I posted the article yesterday. You responded to it. Did you forget already? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-06-14 20:20 -0400 |
| Message-ID | <njq703$ao1$1@dont-email.me> |
| In reply to | #48165 |
On 6/14/2016 8:01 PM, Marek Brunda wrote: > I can understand all yours answers but: > > 1. Strictly technically - constant in this example IS NOT constant - > it's value can be changed. However compiler generates the code which > doesn't reflect this change. What do you mean CONSTANT isn't constant? Clearly there is nothing in the standard that indicates CONSTANT should create a variable. > 2. System behaves differently when interpretting and at runtime Can you explain? If you use the name of a defined CONSTANT either way it returns the value of the constant. > 3. With respect to 1. and 2. it's unexpected behaviour ??? > 4. Using of VALUE needs to implement VALUE and TO - in resource > constraint system it's not negligible ??? > 5. Why the hell using CONSTANT in this case? Easy answer: the > constant is SET ONE TIME ONLY but not when defined, but at runtime, > when system initializes itself. Using of VARIABLE for constant, which > is initialized when the system starts is not appropriate. What??? If you don't like VARIABLE, use VALUE. In resource constrained systems a constant will typically be stored in non-volatile memory, not RAM, so you don't have the option of changing it. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Marek Brunda <marekb@phoenics.org> |
|---|---|
| Date | 2016-06-14 17:33 -0700 |
| Message-ID | <1009fd67-d849-4e26-bf4d-213b7885e8ac@googlegroups.com> |
| In reply to | #48168 |
> What??? If you don't like VARIABLE, use VALUE. In resource constrained > systems a constant will typically be stored in non-volatile memory, not > RAM, so you don't have the option of changing it. In my system the constants are stored in RAM. What is typical is in this case irrelevant for me.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-06-14 21:21 -0400 |
| Message-ID | <njqaii$f79$1@dont-email.me> |
| In reply to | #48170 |
On 6/14/2016 8:33 PM, Marek Brunda wrote: >> What??? If you don't like VARIABLE, use VALUE. In resource constrained >> systems a constant will typically be stored in non-volatile memory, not >> RAM, so you don't have the option of changing it. > > In my system the constants are stored in RAM. What is typical is in this case irrelevant for me. Ok, so what is your point? If you know you can use CONSTANT like VARIABLE but with more trouble, then you don't need to implement VARIABLE. That's great! -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2016-06-14 19:57 -0700 |
| Message-ID | <f3aa0221-447f-4ee1-905d-6529c4996e40@googlegroups.com> |
| In reply to | #48164 |
On Tuesday, June 14, 2016 at 6:37:37 PM UTC-5, rickman wrote: > On 6/14/2016 5:47 PM, krishna.myneni@ccreweb.org wrote: > > The original Starting Forth book by Leo Brodie gives an example > > similar to the one posted by the OP. While the book says it is not > > recommended to do this, it also serves as an illustration of the > > ability provided by a programmer to get at the internals of the > > system. Having used a system from those days, it feels like the > > current Forth implementations, including mine, sacrificed some of > > that ability for the sake of efficiency, and also maybe for use in > > more constrained domains. It may well be a reasonable trade, but it > > is a legitimate concern, particularly if we have a trend towards > > sacrificing more and more of those abilities to get under the hood > > for the sake of efficiency. > > "the book says it is not recommended to do this" > > I think that says it all. There is no trade. This "feature" was never > assured to work because it depends on things being done a certain way > that is contrary to the expected use of the language. > Apparently you haven't bothered to read the earlier messages, particularly the one in which Anton points out that the major Forth implementations he checked permit >BODY to work with a constant, and, therefore, changing the value at the body address is permissible. The only reason that prevents this "feature" from working is the inlining of the constant value, which is actually what is contrary to the expected use of the language, since Forth provides a deliberate method for inlining the value of a constant if the programmer desires to do so. > I can't believe this is even being seriously discussed! Must be a side-effect of working with constrained resources. Cheers, Krishna
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-06-14 23:03 -0400 |
| Message-ID | <njqgi5$t2$2@dont-email.me> |
| In reply to | #48175 |
On 6/14/2016 10:57 PM, krishna.myneni@ccreweb.org wrote: > On Tuesday, June 14, 2016 at 6:37:37 PM UTC-5, rickman wrote: >> On 6/14/2016 5:47 PM, krishna.myneni@ccreweb.org wrote: >>> The original Starting Forth book by Leo Brodie gives an example >>> similar to the one posted by the OP. While the book says it is not >>> recommended to do this, it also serves as an illustration of the >>> ability provided by a programmer to get at the internals of the >>> system. Having used a system from those days, it feels like the >>> current Forth implementations, including mine, sacrificed some of >>> that ability for the sake of efficiency, and also maybe for use in >>> more constrained domains. It may well be a reasonable trade, but it >>> is a legitimate concern, particularly if we have a trend towards >>> sacrificing more and more of those abilities to get under the hood >>> for the sake of efficiency. >> >> "the book says it is not recommended to do this" >> >> I think that says it all. There is no trade. This "feature" was never >> assured to work because it depends on things being done a certain way >> that is contrary to the expected use of the language. >> > > Apparently you haven't bothered to read the earlier messages, particularly the one in which Anton points out that the major Forth implementations he checked permit >BODY to work with a constant, and, therefore, changing the value at the body address is permissible. The only reason that prevents this "feature" from working is the inlining of the constant value, which is actually what is contrary to the expected use of the language, since Forth provides a deliberate method for inlining the value of a constant if the programmer desires to do so. > >> I can't believe this is even being seriously discussed! > > Must be a side-effect of working with constrained resources. You don't get that this *only* works if your implementation operates a certain way. There is no assurance of that, so the code can work on some systems, but won't work on others. Do you really not understand that? There is no reason to expect this to work in any given system. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-06-14 20:31 -0700 |
| Message-ID | <87a8innn5g.fsf@nightsong.com> |
| In reply to | #48175 |
krishna.myneni@ccreweb.org writes: > The only reason that prevents this "feature" from working is the > inlining of the constant value No, the "feature" also depends on how CONSTANT is implemented, independently of whether the other word inlines it.
[toc] | [prev] | [next] | [standalone]
| From | pahihu <pahihu@gmail.com> |
|---|---|
| Date | 2016-06-15 01:36 -0700 |
| Message-ID | <961a7747-37e2-4491-a491-1fee40fdb2ca@googlegroups.com> |
| In reply to | #48175 |
> particularly the one in which Anton points out that the major Forth implementations he checked > permit >BODY to work with a constant, and, therefore, changing the value at the body address > is permissible. iForth version 4.0.1790, generated 09:52:16, March 8, 2014. x86_64 binary, native floating-point, extended precision. Copyright 1996 - 2014 Marcel Hendrix. [1] iForth server for Darwin, rev 1.04, May 27 2016, 09:05:24. FORTH> 5 constant x ok FORTH> ' x >body @ . -8029670749633150136 ok FORTH> : foo x ; ok FORTH> 7 ' x >body ! ok FORTH> x . iServer: caught SIGILL
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web