Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #31931 > unrolled thread

OT: New TI MSP430 Ultra Low Power Chip

Back to article view | Back to comp.lang.forth

Contents

  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 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#32143

On Thursday, July 3, 2014 12:28:04 AM UTC-4, rickman wrote:

> Low resale value?  You mean low cost?

I mean limited benefit to someone who goes to the trouble of stealing one, so that people inclined to do so do not learn that its useful to do so.

The starting point was to build something around the Raspberry Pi, and that is still a likely pilot project controller, but if it proves out, it would never be a workable system for broader roll-out, since the same features that make them appealing for a pilot project also make them far too likely to walk away.

> I think you are saying you want this cheap enough that you won't care so much if it is damaged or destroyed, right?

One of the target areas would be the Dem. Rep. of Congo, so also cheap enough and specialized enough to their role so that spreading them around a set of villages is not like trying to fill up a bucket with a hole in the bottom.

>> I was thinking of the UART as the simplest approach to in-field programming, since I know of several ways to talk to a UART and get a console over either Blu Tooth or USB. But if there are easier ways nowadays to have a back port that can add either Blu-Tooth or USB access with most of the smarts on the side of the plug that plugs into the widget, that'd be good too.

> So the serial port is not for interfacing to things being read or  
> controlled, it is for configuration?

Yes. As I recall from the last time I had an opportunity to do field word, the way things work when you get in the field are never how you thought they would go when you were back at the University, which is why being field programmable without dependence on a single specialized piece of equipment is something that always catches my eye. My first field work in the 90's I was able to get an Atari Portfolio to enter my survey data in the field, and being able to run a spreadsheet was a lifesaver.

And as I am stepping back into the University ratrace after nearly a decade in the quiet backwaters of Community College teaching, I'm dusting off old project ideas to see if what went into the too hard basket at the turn of the century have come into the viability range now.

> It's not very often anyone says they want little in the MCU.  The cost  
> of the MSP430 with 16 kB of FRAM is around $2 at 1000 each.  Can you 
> care about saving another $0.25 by using the 8 kB version?  If you 
> aren't shipping 100k units this small price delta just is not important.

Yeah, but knowing how much would be workable for a free-standing Forth system itself gives a baseline to build up from. And of course you don't want to have TOO much more capability than required, since people are clever, and the more powerful it is, the more likely they are to work out some way to make it into something worth stealing.

> Ok, so size, weight and power are not issues.  Is price the only 
> constraint?

Given the sizes of these microprocessors, size and weight aren't a real constraint ... you can get a sound card interface kit for a village to village radio fidonet over a UHF or HF frequency transceiver for around $25 (the interface kit, not the transceiver) that is 2.5" x 2.5" x 1" (64mm x 64 mm x 26mm), and that would need an additional metal casing around it to make it padlockable, so there'd reasonably be something like 80mm x 80mm x 20mm to play with.

The more hardware assembly is practicable in the host country, the better, of course.

> Any idea how large your app would be?
They ran fidonets with Commodore 64's back in the day, so I don't expect it would overflow the sizes of the largest of the FRAM MP340's, but I'd have to explore to find out how small it can get. Digital ham shacks were also run on C64's in the day, and I have a resource to connect into the Ham community. An advantage of a symmetric fidonet with the same system on both side is that you don't have to strain to keep up with the Jones's.

But the rough plan would be that the cellphone to fidonet link is also how the other readings get logged, with the packets that are directed to the nodes for collecting that data getting copied into a local data log folder as well as into the outgoing messages queue folder.

[toc] | [prev] | [next] | [standalone]

#32146

In terms of resources, I can tell you that my Forth system, written for the TMS9900 occupies just short of 16KB of code space. That includes a fairly full-featured screen-based editor (i.e. free movement of the cursor, copy&paste, insert/overwrite). Could probably shave 3 to 4K off that by omitting the editor.

I only mention it because whilst the TMS9900 and MSP430 are quite different, they appear to be similar in their instruction set decoding: All instructions are a minimum of 16-bit (2 bytes), some instructions 4 bytes, and the worst (e.g MOV @memory_address,@memory_address) are 6 bytes.

My system also uses ~700 bytes of RAM (the Forth system is in ROM) for itself. That includes the data and return stacks. The rest of the system RAM (~31K) is available for Forth programs.

A cool thing about the FRAM is that you can protect it in pages. So, you upload the Forth kernal image to it, then you can protect the FRAM pages that host the kernal from accidental overwrite etc. Much like the old days of splitting the memory map up between ROM and RAM.

I'm looking at a similar Forth system to yours, I suspect. An MSP430 hosting a 16-key hex keypad (useful for the end application), 2x40 LCD display, some LEDs, an RS232 interface (probably 2 off) and an SD card reader/writer for code/data storage.

[toc] | [prev] | [next] | [standalone]

#32155

On Thursday, July 3, 2014 5:17:06 AM UTC-4, Mark Wills wrote:
> In terms of resources, I can tell you that my Forth system, written for the TMS9900 occupies just short of 16KB of code space. That includes a fairly full-featured screen-based editor (i.e. free movement of the cursor, copy&paste, insert/overwrite). Could probably shave 3 to 4K off that by omitting the editor.
 
> I only mention it because whilst the TMS9900 and MSP430 are quite different, they appear to be similar in their instruction set decoding: All instructions are a minimum of 16-bit (2 bytes), some instructions 4 bytes, and the worst (e.g MOV @memory_address,@memory_address) are 6 bytes.
 
> My system also uses ~700 bytes of RAM (the Forth system is in ROM) for itself. That includes the data and return stacks. The rest of the system RAM (~31K) is available for Forth programs.

Thanks. That sounds like the approach could be viable for one of the FRAM parts, with something in the range of 32K FRAM, 1K SRAM. I'll keep an eye out for an opportunity to get familiar with these parts next summer.

[toc] | [prev] | [next] | [standalone]

#32178

BruceMcF <agila61@netscape.net> writes:
>> Low resale value?  You mean low cost?
> I mean limited benefit to someone who goes to the trouble of stealing
> one, so that people inclined to do so do not learn that its useful to
> do so.

The SD card is consumer electronics usable in cell phones, cameras, etc.
As such it is probably more saleable than something like a raspberry pi
board.  I think if your board has flash memory, you want to solder it down.

[toc] | [prev] | [next] | [standalone]

#32179

On 7/3/2014 5:23 PM, Paul Rubin wrote:
> BruceMcF <agila61@netscape.net> writes:
>>> Low resale value?  You mean low cost?
>> I mean limited benefit to someone who goes to the trouble of stealing
>> one, so that people inclined to do so do not learn that its useful to
>> do so.
>
> The SD card is consumer electronics usable in cell phones, cameras, etc.
> As such it is probably more saleable than something like a raspberry pi
> board.  I think if your board has flash memory, you want to solder it down.

I dunno.  An rPi costs some $35 without shipping.  1 GB flash would be 
very little indeed if you can still find them.  I tried to buy some 1 GB 
SD cards last year and everything I got was junk and wouldn't work in my 
GPS.  I suppose it is possible the GPS isn't any good, but they were all 
very wonky even in my computer with sizes ranging from 1 GB to 0.8 GB. 
Mostly they were about $2 with shipping.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#32182

rickman <gnuarm@gmail.com> writes:
> I dunno.  An rPi costs some $35 without shipping.  1 GB flash would be
> very little indeed if you can still find them. 

The concern is that with the MSP430 board and a socketed SD card, people
will steal the board to get the card, then throw away the board which is
otherwise useless.  The Rpi of course also has the SD card problem, so a
board with some built-in flash might be better.  The Rpi actually starts
at $25 (model A, omits some features of the $35 model) if that makes any
difference.

[toc] | [prev] | [next] | [standalone]

#32185

On 7/3/2014 6:25 PM, Paul Rubin wrote:
> rickman <gnuarm@gmail.com> writes:
>> I dunno.  An rPi costs some $35 without shipping.  1 GB flash would be
>> very little indeed if you can still find them.
>
> The concern is that with the MSP430 board and a socketed SD card, people
> will steal the board to get the card, then throw away the board which is
> otherwise useless.  The Rpi of course also has the SD card problem, so a
> board with some built-in flash might be better.  The Rpi actually starts
> at $25 (model A, omits some features of the $35 model) if that makes any
> difference.

The point is that there is very little value in a $1 microSD card 
assuming you even know the microSD card is in it.  I'd say the value is 
maybe... $1.  If someone is going to take the unit for a $1 microSD card 
I think they can figure out there is a $25 rPi inside that can be sold 
for $10 easily.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#32188

rickman <gnuarm@gmail.com> writes:
> If someone is going to take the unit for a $1 microSD card I think
> they can figure out there is a $25 rPi inside that can be sold for $10
> easily.

Given the environment where these boards are supposedly going, I'm not
persuaded anyone will buy the rpi.  Almost every mobile phone user is
potentially a buyer for the sd card, especially if it's micro size.

[toc] | [prev] | [next] | [standalone]

#32190

On Thursday, July 3, 2014 8:38:36 PM UTC-4, Paul Rubin wrote:
> Given the environment where these boards are supposedly going, I'm not 
> persuaded anyone will buy the rpi.

Anything that you could hook up a cheap Chinese HDMI LCD TV and a Cheap Chinese game controller to and load up a game for a game room is going to find a taker. Maybe not in the village itself, but in the closest town, and something you could turn into drinks when you go to town is a worry. My wife ran a game room for a while just a little while after the PS3 transition with used PS2's and PS2 games I was picking up cheap in Australia.

And if someone get an idea of what all they could do with it ~ and I'm sure its well enough covered in French that someone could figure it out ~ I wouldn't reckon it at a discount to the US price, I'd reckon it at a premium.

> Almost every mobile phone user is potentially a buyer for the sd card,
> especially if it's micro size.

The flip side of that broad utility is ready availability in town. So the idea is for it not to be in the controller box over night.

The problem with it walking away from its padlocked steel enclosure is not that it'll be slipped out on the sly, but either that someone will break in at night and have at it with a hacksaw, or some thug will strongarm the radio operator. A 2GB SD card is probably not worth the risk of breaking a hacksaw blade, and if a thug is going to strongarm the radio operator for a 2GB SD card, then it has to have been providing a useful enough service that an aunt or uncle berates him until he gives it back.

[toc] | [prev] | [next] | [standalone]

#32220

On Tuesday, July 1, 2014 8:44:16 PM UTC-7, bruce.m...@gmail.com wrote:
> "The purpose of this Standard is to promote the portability of Forth programs for use on a wide variety of computing systems, to facilitate the communication of programs, programming techniques, and ideas among Forth programmers, and to serve as a basis for the future evolution of the Forth language."

The problem with ANS-Forth is that in several places it says: an ANS-Forth compliant system may do X or may do Y.

The problem here is that X and Y are not compatible. If a person writes a program for a system that does X, and his program depends upon X being done, then his program will not work on a system that does Y. This "may this or may that" business is a complete failure by the ANS-Forth committee to understand the concept of portability.

No other language standard has such wishy-washy "may this or may that" statements.

I know exactly why ANS-Forth is wishy-washy like this. It is because SwiftForth was mandated to be ANS-Forth standard without any change whatsoever. Unfortunately, a lot of what SwiftForth does is just plain dumb (like using the data stack as the control-flow stack at compile time). Other Forth systems do things in a more intelligent (but not compatible with SwiftForth) way. Those Forth compiler-writers wanted to be standard, but they didn't want to become compatible with SwiftForth because this would mean throwing away an intelligent design and replacing it with a dumb design. Forth Inc. knew that it needed those other systems to be ANS-Forth compliant, so that ANS-Forth would appear to be a community effort --- so, grudgingly, Elizabeth Rather said: "Okay, you can be ANS-Forth compatible too, even though you refuse to be SwiftForth compatible." --- hence the "may this or may that" statement. All of these wishy-washy statements effectively translate to: "You may either use an intelligent design, or you may be SwiftForth, but either way you get to call yourself ANS-Forth compliant."

The end result for the user, if he wants to write portable code, is to figure out what is the most restrictive way that a compiler could be written --- then he writes his program for that compiler --- and he has a good chance that the other less-restrictive systems will compile and execute his program correctly. Invariably however, the most restrictive compiler in the ANS-Forth world is SwiftForth --- so SwiftForth has effectively become the ANS-Forth standard. 

> Three purposes, your suggestion contradicts each of the three.

This is total baloney --- I am surprised at you Bruce --- I would expect this from John Passaniti or Alex McDonald, but not from you.

[toc] | [prev] | [next] | [standalone]

#32223

On Friday, July 4, 2014 10:14:22 PM UTC-4, hughag...@yahoo.com wrote:
> On Tuesday, July 1, 2014 8:44:16 PM UTC-7, bruce.m...@gmail.com wrote:

> > "The purpose of this Standard is to promote the portability of Forth programs for use on a wide variety of computing systems, to facilitate the communication of programs, programming techniques, and ideas among Forth programmers, and to serve as a basis for the future evolution of the Forth language."

> The problem with ANS-Forth is that in several places it says: an ANS-Forth compliant system may do X or may do Y.

> The problem here is that X and Y are not compatible. If a person writes a program for a system that does X, and his program depends upon X being done, then his program will not work on a system that does Y. This "may this or may that" business is a complete failure by the ANS-Forth committee to understand the concept of portability.

I have no interest in doing your homework for in developing a solid evidence-based argument in support of these claims, and you do not appear to have interest in doing that work. And on the other hand, in my own (quite clearly limited) experience they are groundless claims, so I am unlikely to be persuaded by just the claim itself being made.

[toc] | [prev] | [next] | [standalone]

#32226

On Fri, 04 Jul 2014 22:14:22 -0400, <hughaguilar96@yahoo.com> wrote:

> [...] I am surprised at you Bruce --- I would expect this from John  
> Passaniti or Alex McDonald, but not from you.

Do you have the apparently two Bruce's here mixed up? ...


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#32114

On Tuesday, 1 July 2014 20:02:42 UTC+1, rickman  wrote:
> I think you have that exactly backwards.  A standard should 
> specify the minimum possible and still achieve the goals of the
> standard.

The problem with that approach is that it leaves so much open to
interpretation/argument that the standard itself becomes 
meaningless. And that's a real shame. When the text of a standard
(any standard, not specifically ANS94 - I see it every day and get
embroiled in arguments with ISO 13628-6 and the like) it becomes
effectively meaningless, because an implementer can effectively do
what he wants, and twist the interpretation of the text of the 
standard to support his view.

[toc] | [prev] | [next] | [standalone]

#32117

In article <da28710a-0cc0-419d-a379-b6a3525c193f@googlegroups.com>,
Mark Wills  <markwills1970@gmail.com> wrote:
>On Tuesday, 1 July 2014 20:02:42 UTC+1, rickman  wrote:
>> I think you have that exactly backwards.  A standard should
>> specify the minimum possible and still achieve the goals of the
>> standard.
>
>The problem with that approach is that it leaves so much open to
>interpretation/argument that the standard itself becomes
>meaningless. And that's a real shame. When the text of a standard
>(any standard, not specifically ANS94 - I see it every day and get
>embroiled in arguments with ISO 13628-6 and the like) it becomes
>effectively meaningless, because an implementer can effectively do
>what he wants, and twist the interpretation of the text of the
>standard to support his view.

Well. No. I was in the same debate about the c language in the 80's.

The standard is a common denominator of what can reasonably be achieved in
the same way in different implementations. If you want portability
- and Elizabeth Rather has explained a great many times that if you
don't want it, you can get around everything - you've to expend some
effort. Instead of looking at all the systems you want to port to,
you look at the standard. You comply with the standard, and if you
got problems you can contact your vendor. He will have to do something
about it if he claims to be ISO standard.

Now the old habit of using all kind of weird tricks that happen to
work will get in your way. If that is your hobby, fine. Don't complain
about the standard. For example: if you are so fond of multiple level
returns, you need a real return stack. Expect to get burned by
implementors who do tail recursion optimisations. You've got yourself
a -- probably needless -- environmental dependancy. That's your
decision and your consequences.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#32192

On Tuesday, July 1, 2014 9:02:42 PM UTC+2, rickman wrote:
> A standard should specify the
> minimum possible and still achieve the goals of the standard.  There is
> no purpose to specifying if code and data should be kept separate, that
> depends entirely on the platform being used to implement the application.

No, it is not so easy in this particular case. When code and data
are separated, the obvious way to implement CREATE DOES> needs an
indirection to bridge from code space to data space. There are some
minor issues too, like ","  not working when assembling CODE or
controlstructures. And finally, separated code and data allows
to do

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.

Really useful systems having separate code and data need things
like CODE-, C-ALLOT, C-HERE etc..

My point is that code/data separation is not a "mere" 
implementation issue.

-marcel

[toc] | [prev] | [next] | [standalone]

#32195

Good points, Marcel. Thanks.

[toc] | [prev] | [next] | [standalone]

#32208

On 7/3/14 10:29 PM, m.a.m.hendrix@tue.nl wrote:
> On Tuesday, July 1, 2014 9:02:42 PM UTC+2, rickman wrote:
>> A standard should specify the
>> minimum possible and still achieve the goals of the standard.  There is
>> no purpose to specifying if code and data should be kept separate, that
>> depends entirely on the platform being used to implement the application.
>
> No, it is not so easy in this particular case. When code and data
> are separated, the obvious way to implement CREATE DOES> needs an
> indirection to bridge from code space to data space. There are some
> minor issues too, like ","  not working when assembling CODE or
> controlstructures. And finally, separated code and data allows
> to do
>
> 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.
>
> Really useful systems having separate code and data need things
> like CODE-, C-ALLOT, C-HERE etc..
>
> My point is that code/data separation is not a "mere"
> implementation issue.

These are all issues that we attempted to address in the draft 
cross-compiler standard. But even Forth94 very carefully specifies that 
certain things, such as the fact that "," specifically works in data 
space and the rules regarding what you can and cannot assume about 
contiguous spaces. A "user" (as opposed to an implementer) *only* has 
access to data space.

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.

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]

#32222

On Friday, July 4, 2014 9:01:09 PM UTC+2, Elizabeth D. Rather wrote:
[..]
Does that mean then that an ANS Forth user is justified in expecting
the following to work?

CREATE foo   : bar 123 ;  bar ,   foo @ . ( prints 123)

-marcel

[toc] | [prev] | [next] | [standalone]

#32224

mhx@iae.nl writes:
> Does that mean then that an ANS Forth user is justified in expecting
> the following to work?
> CREATE foo   : bar 123 ;  bar ,   foo @ . ( prints 123)

I don't see that following from what Elizabeth said.  The user can't
operate in non-data space, but code and data space are not required to
be separate.  In traditional implementations, the spaces are the same,
so the user and the compiler are both operating in the data space and in
your example, they will interfere.

[toc] | [prev] | [next] | [standalone]

#32228

On Saturday, July 5, 2014 8:05:27 AM UTC+2, Paul Rubin wrote:
> mhx@iae.nl writes:
> > Does that mean then that an ANS Forth user is justified in expecting
> > the following to work?
> > CREATE foo   : bar 123 ;  bar ,   foo @ . ( prints 123)
> 
> I don't see that following from what Elizabeth said.  The user can't
> operate in non-data space, but code and data space are not required to
> be separate.  In traditional implementations, the spaces are the same,
> so the user and the compiler are both operating in the data space and in
> your example, they will interfere.

That is the correct answer, but a simple user will not have that knowledge.
However, I see that the Standard says ~ page 30 (ASCII version, search for
contiguous):

"Since an implementation is free to allocate data space for use by code,
the above operators need not produce contiguous regions of data space if
definitions are added to or removed from the dictionary between allocations."

-marcel

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.forth

csiph-web