Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #31931 > unrolled thread
| Started by | Mark Wills <markwills1970@gmail.com> |
|---|---|
| First post | 2014-06-27 03:35 -0700 |
| Last post | 2014-07-04 18:54 -0700 |
| Articles | 3 on this page of 63 — 15 participants |
Back to article view | Back to comp.lang.forth
OT: New TI MSP430 Ultra Low Power Chip Mark Wills <markwills1970@gmail.com> - 2014-06-27 03:35 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip Paul Rubin <no.email@nospam.invalid> - 2014-06-28 09:29 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip rickman <gnuarm@gmail.com> - 2014-06-28 21:19 -0400
Re: OT: New TI MSP430 Ultra Low Power Chip Paul Rubin <no.email@nospam.invalid> - 2014-06-28 20:57 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip bruce.mcfarling@gmail.com - 2014-06-28 22:26 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip Paul Rubin <no.email@nospam.invalid> - 2014-06-28 22:33 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip BruceMcF <bruce.mcfarling@gmail.com> - 2014-06-29 07:44 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip stephenXXX@mpeforth.com (Stephen Pelc) - 2014-06-29 14:53 +0000
Re: OT: New TI MSP430 Ultra Low Power Chip bruce.mcfarling@gmail.com - 2014-06-29 09:04 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-29 10:00 +0000
Re: OT: New TI MSP430 Ultra Low Power Chip Paul Rubin <no.email@nospam.invalid> - 2014-06-29 19:16 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip rickman <gnuarm@gmail.com> - 2014-06-30 16:58 -0400
Re: OT: New TI MSP430 Ultra Low Power Chip Paul Rubin <no.email@nospam.invalid> - 2014-06-30 14:43 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip rickman <gnuarm@gmail.com> - 2014-06-30 17:55 -0400
Re: OT: New TI MSP430 Ultra Low Power Chip Paul Rubin <no.email@nospam.invalid> - 2014-06-30 15:34 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip rickman <gnuarm@gmail.com> - 2014-06-30 19:09 -0400
Re: OT: New TI MSP430 Ultra Low Power Chip rickman <gnuarm@gmail.com> - 2014-06-30 19:13 -0400
Re: OT: New TI MSP430 Ultra Low Power Chip Paul Rubin <no.email@nospam.invalid> - 2014-06-30 17:52 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip rickman <gnuarm@gmail.com> - 2014-06-30 22:20 -0400
Re: OT: New TI MSP430 Ultra Low Power Chip Paul Rubin <no.email@nospam.invalid> - 2014-06-30 22:10 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip rickman <gnuarm@gmail.com> - 2014-07-01 04:42 -0400
Re: OT: New TI MSP430 Ultra Low Power Chip Paul Rubin <no.email@nospam.invalid> - 2014-07-01 07:55 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip Bernd Paysan <bernd.paysan@gmx.de> - 2014-07-01 17:19 +0200
Re: OT: New TI MSP430 Ultra Low Power Chip hughaguilar96@yahoo.com - 2014-06-29 19:49 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip Mark Wills <markwills1970@gmail.com> - 2014-06-30 01:38 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip bruce.mcfarling@gmail.com - 2014-06-30 07:22 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip hughaguilar96@yahoo.com - 2014-06-30 15:29 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip Mark Wills <markwills1970@gmail.com> - 2014-07-01 01:51 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-07-01 10:26 -0500
Re: OT: New TI MSP430 Ultra Low Power Chip hughaguilar96@yahoo.com - 2014-07-01 11:08 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip BruceMcF <agila61@netscape.net> - 2014-07-01 12:59 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip rickman <gnuarm@gmail.com> - 2014-07-01 15:02 -0400
Re: OT: New TI MSP430 Ultra Low Power Chip BruceMcF <agila61@netscape.net> - 2014-07-01 13:02 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip hughaguilar96@yahoo.com - 2014-07-01 17:25 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip bruce.mcfarling@gmail.com - 2014-07-01 20:44 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip rickman <gnuarm@gmail.com> - 2014-07-02 12:11 -0400
Re: OT: New TI MSP430 Ultra Low Power Chip bruce.mcfarling@gmail.com - 2014-07-02 10:19 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip rickman <gnuarm@gmail.com> - 2014-07-02 15:30 -0400
Re: OT: New TI MSP430 Ultra Low Power Chip BruceMcF <agila61@netscape.net> - 2014-07-02 19:25 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip rickman <gnuarm@gmail.com> - 2014-07-03 00:28 -0400
Re: OT: New TI MSP430 Ultra Low Power Chip BruceMcF <agila61@netscape.net> - 2014-07-03 00:25 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip Mark Wills <markwills1970@gmail.com> - 2014-07-03 02:17 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip bruce.mcfarling@gmail.com - 2014-07-03 09:31 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip Paul Rubin <no.email@nospam.invalid> - 2014-07-03 14:23 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip rickman <gnuarm@gmail.com> - 2014-07-03 17:53 -0400
Re: OT: New TI MSP430 Ultra Low Power Chip Paul Rubin <no.email@nospam.invalid> - 2014-07-03 15:25 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip rickman <gnuarm@gmail.com> - 2014-07-03 19:53 -0400
Re: OT: New TI MSP430 Ultra Low Power Chip Paul Rubin <no.email@nospam.invalid> - 2014-07-03 17:38 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip bruce.mcfarling@gmail.com - 2014-07-03 18:21 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip hughaguilar96@yahoo.com - 2014-07-04 19:14 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip bruce.mcfarling@gmail.com - 2014-07-04 22:52 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-07-05 02:21 -0400
Re: OT: New TI MSP430 Ultra Low Power Chip Mark Wills <markwills1970@gmail.com> - 2014-07-02 01:04 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-02 11:59 +0000
Re: OT: New TI MSP430 Ultra Low Power Chip m.a.m.hendrix@tue.nl - 2014-07-04 01:29 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip Mark Wills <markwills1970@gmail.com> - 2014-07-04 04:17 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip "Elizabeth D. Rather" <erather@forth.com> - 2014-07-04 09:01 -1000
Re: OT: New TI MSP430 Ultra Low Power Chip mhx@iae.nl - 2014-07-04 22:51 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip Paul Rubin <no.email@nospam.invalid> - 2014-07-04 23:05 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip mhx@iae.nl - 2014-07-05 00:54 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip hughaguilar96@yahoo.com - 2014-07-06 17:00 -0700
Re: OT: New TI MSP430 Ultra Low Power Chip albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-07 11:00 +0000
Re: OT: New TI MSP430 Ultra Low Power Chip hughaguilar96@yahoo.com - 2014-07-04 18:54 -0700
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-07-06 17:00 -0700 |
| Message-ID | <214455ae-bb4e-4453-ae33-84aaec3954f9@googlegroups.com> |
| In reply to | #32208 |
On Friday, July 4, 2014 12:01:09 PM UTC-7, Elizabeth D. Rather wrote: > On 7/3/14 10:29 PM, m.a.m.hendrix@tue.nl wrote: > > CREATE foo 3 CONSTANT bar bar , foo @ . ( prints 3) > > > Although nice, this will rapidly result in sources that fail on > > different systems for difficult to understand reasons. At least, > > it would force everybody to be aware of this possibility, > > spoiling the fun a bit. I wrote code like that all of the time under MFX. I think that most reasonable people would expect such code to work, and would be surprised when it failed --- my definition of "reasonable people" are those proficient in several assembly-languages (the typical Forth novice). When I program in ANS-Forth, I have to continuously be aware of all of the weird pointless restrictions that ANS-Forth imposes --- this is how I know not to write code like the above --- ANS-Forth is stultifying, as it is entirely focused on what can't be done rather than what can be done. I would not expect a novice Forther to predict that the above code would not work, or to know why it didn't work if he had already done written it. There is nothing in the ANS-Forth document that would tip off the user to this weird context-sensitivity. Most Forth programmers are FODs over 40, and none are under 30 (not counting Gavino). I think that FODs enjoy having weird pointless restrictions in ANS-Forth, because this tends to trip up the novices. The result is a confused novice showing up on comp.lang.forth asking: "Why doesn't my code work?" or "This code worked on X ANS-Forth compliant system, but now it fails on Y ANS-Forth compliant system --- what did I do wrong?" So the FOD gets to say: "You're stupid! You will never succeed as a Forth programmer on your own! But if you brown-nose us, then we will do your homework for you tell you how to get your program to work." It is possible that these pitfalls were built into ANS-Forth specifically for the purpose of tripping up novices and simultaneously making the FODs appear to be smart by forcing the novice to ask the FODs for help. I think that Elizabeth Rather never intended anybody outside of Forth Inc. to use ANS-Forth --- it was her hope that every novice Forth programmer would fail to learn ANS-Forth beyond the most rudimentary level --- the only way that anybody could become a Forth programmer would be with a lot of brown-nosing of the FOD/FOB crowd, of which she was the leader. > Obviously an implementer has to make different decisions when > constructing a system that will run in a separate code/data space > environment. It is quite possible to write user code that will be > portable on both kinds of systems providing you respect the cautions > about having access only to data space. His code did access only the data space (that is what the comma and the @ did, and they are the only memory-access words used). All of this talk about the user accessing code memory is a straw-man argument --- I never suggested that, and I think it is a bad idea. There is no reason why a user would want to access code memory --- this would imply that the user has a lot of carnal knowledge regarding what is in code memory --- this is an extremely bad idea. People do write code that compiles into code memory (CONSTANT in his example) all of the time --- I obviously expect users to do this, and whenever they want to --- it is mighty bizarre to tell users that they can only compile code in certain contexts, depending upon what other code (CREATE, HERE, comma or ALLOT) that they have done recently and whether that code is "complete" or not. People aren't going to learn Forth unless the rules are simple and easy to grasp --- ANS-Forth is grossly over-complicated and full of non-intuitive rules --- I don't blame young programmers for not wanting to learn ANS-Forth --- I wouldn't want to learn it either, if I was 18 again.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-07-07 11:00 +0000 |
| Message-ID | <53ba7dbc$0$4699$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #32240 |
In article <214455ae-bb4e-4453-ae33-84aaec3954f9@googlegroups.com>,
<hughaguilar96@yahoo.com> wrote:
> Discussing Mhx example:
> CREATE foo 3 CONSTANT bar bar , foo @ . ( prints 3)
I think the example is pretty nonsensical.
Let's do this in C
struct foo {
int bar =3;
int x;
} = {bar}
The programmer starts a new construct before the previous one has
been defined.
It can be made to work in C by a mixing two different mechanisms:
struct foo {
#define BAR 3
int x;
} = {BAR}
It is obviously wrong, the only reason Forth may look right is
that Forth is ... well ... a bit obfuscated.
>
>People do write code that compiles into code memory (CONSTANT in his
>example) all of the time --- I obviously expect users to do this, and
>whenever they want to --- it is mighty bizarre to tell users that they
>can only compile code in certain contexts, depending upon what other
>code (CREATE, HERE, comma or ALLOT) that they have done recently and
>whether that code is "complete" or not.
noforth uses separate code and data space.
Adding
3 CONSTANT BAR
to the dictionary, never touches the dataspace (RAM).
Constant are stored in code space (think flash). As are dictionary
headers until a reflash.
If you think you can make a Forth for a flash microprocessor (like
Renesas H8, or the Launchpad) without making the user aware of code
and dataspace you are mistaken. Same for non-trivial 16 bit Forths on
MSDOS.
Groetjes Albert
>
>People}) aren't going to learn Forth unless the rules are simple and easy
>to grasp --- ANS-Forth is grossly over-complicated and full of
>non-intuitive rules --- I don't blame young programmers for not wanting
>to learn ANS-Forth --- I wouldn't want to learn it either, if I was 18
>again.
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-07-04 18:54 -0700 |
| Message-ID | <574bdbfd-868f-4ddd-96ac-54aef004070d@googlegroups.com> |
| In reply to | #32192 |
On Friday, July 4, 2014 1:29:35 AM UTC-7, m.a.m....@tue.nl wrote: > CREATE foo 3 CONSTANT bar bar , foo @ . ( prints 3) > > Although nice, this will rapidly result in sources that fail on > different systems for difficult to understand reasons. At least, > it would force everybody to be aware of this possibility, > spoiling the fun a bit. This isn't a very realistic example. I was thinking more along the lines of a colon word that meta-compiles, and hence contains both code that commas and code that meta-compiles (POSTPONE stuff). Apparently not very many people write colon words that meta-compile. In this thread (https://groups.google.com/forum/#!topic/comp.lang.forth/3Y4w_MdYl0k) I wrote a very simple program that involved meta-compiling, and my program revealed a bug in Gforth. Anton did fix the bug. The fact that such a bug could exist however, indicates that nobody has ever written any meta-compiling code in Gforth. > Really useful systems having separate code and data need things > like CODE-, C-ALLOT, C-HERE etc.. I have no intention of providing anything like that for my users. Why would they want to muck around in code memory? The only thing I allow them to do in code memory is compile code. They don't know how code is getting compiled, and it is not going to be the same from one implementation to the next, so they shouldn't be messing around in code memory. In many cases, @ and ! aren't going to work anyway. The point of specifying that code and data memory is separate, is so the user can put HERE on the stack and expect it to continue to be valid unless he himself uses comma or ALLOT. In this case, his value will point to the front of the struct or array, and HERE will now point to just past his comma or ALLOT data. If he compiles code, this will have no affect on the validity of his HERE value. People with an assembly-language background do not expect code to get compiled into the middle of data, and I would guarantee that this won't happen.
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.forth
csiph-web