What is Forth best at? - Programming Languages

On Wed, 21 Mar 2007 11:07:05 -0600, John Doty
<jpd@whispertel.LoseTheH.net> wrote:
[color=blue]
>Elizabeth D Rather wrote:[color=green]
>> But there are still some Forths that run on the small
>> microcontrollers, and no C compilers that do, AFAIK.[/color]
>
>Could be, but this would be a stronger statement if you'd give an example.[/color]

Ok, I have an ARM with 512kb Flash, 32k RAM and I compile code on it.
How many C compilers do that? If you can't see why that could be
useful, you're a robot (see your sig).

And similarly for a wide range of embedded CPUs.

Stephen


--
Stephen Pelc, [email]stephenXXX@mpeforth.com[/email]
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: [url]http://www.mpeforth.com[/url] - free VFX Forth downloads

Stephen Pelc wrote:[color=blue]
> On Wed, 21 Mar 2007 11:07:05 -0600, John Doty
> <jpd@whispertel.LoseTheH.net> wrote:
>[color=green]
>> Elizabeth D Rather wrote:[color=darkred]
>>> But there are still some Forths that run on the small
>>> microcontrollers, and no C compilers that do, AFAIK.[/color]
>> Could be, but this would be a stronger statement if you'd give an example.[/color]
>
> Ok, I have an ARM with 512kb Flash, 32k RAM and I compile code on it.[/color]

Sure can compile code *for* it in C.
[color=blue]
> How many C compilers do that? If you can't see why that could be
> useful, you're a robot (see your sig).[/color]

I can imagine *rare* requirements. But is that really all your Forth is
good for?
[color=blue]
>
> And similarly for a wide range of embedded CPUs.
>
> Stephen
>
>[/color]


--
John Doty, Noqsi Aerospace, Ltd.
--
Specialization is for robots.

On Mar 21, 8:57 pm, John Doty <j...@whispertel.LoseTheH.net> wrote:[color=blue]
> Stephen Pelc wrote:[color=green]
> > Ok, I have an ARM with 512kb Flash, 32k RAM and I compile code on it.[/color][/color]
[color=blue]
> Sure can compile code *for* it in C.[/color]

See, you admit that you can't compile code on it in C. Just
saying so would be less circuitous, but at least you were
able to admit it.
[color=blue][color=green]
> > How many C compilers do that? If you can't see why that could be
> > useful, you're a robot (see your sig).[/color][/color]
[color=blue]
> I can imagine *rare* requirements. But is that really all your Forth is
> good for?[/color]

Its one thing his Forth is good for. If I had to dial into a remote
data logger to modify what it is doing, I would far rather have an
actual ability to compile on it than the hypothetical ability to
compile for it. Or, in the extreme example, if a control computer
was outside earth orbit when it was determined that a programming
change was required.

However, I'm curious. You thought nobody would notice the flimsy
rhetorical ploy, the pretence that Stephen Pelc was saying this
was *the only thing* that his Forth was good for? Really?

On Mar 21, 9:35 pm, "Bruce McFarling" <agil...@netscape.net> wrote:[color=blue]
> On Mar 21, 8:57 pm, John Doty <j...@whispertel.LoseTheH.net> wrote:[/color]
[color=blue][color=green]
> > I can imagine *rare* requirements. But is that really all your Forth is
> > good for?[/color]
>
> I'm curious. You thought nobody would notice the flimsy
> rhetorical ploy, the pretence that Stephen Pelc was saying this
> was *the only thing* that his Forth was good for? Really?[/color]

I was making a more charitable interpretation.

If usually compiling on the target isn't needed, and further umbilical
Forths tend to be better, then why bother with the claim we can
compile on small targets? That was real useful in the old days. Why
not update the claims and put more effort into important things Forth
does well today?

I can see that for, say, mortar shells that have little
microprocessors in them, it's better and cheaper and more reliable to
plug in a little keypad with LCD display than to need a laptop. (But
an umbilical Forth build into they keypad might be better.) I can see
that underfunded insurgents might do better with an embedded Forth
built into their IEDs than needing a laptop that's likely to be
destroyed at the first mistake. But that isn't really a great target
market....

In space? Is your compiled code bulkier than the source code? If not,
what's the harm in sending object code instead of source?

If your processor is connected to the net then you can send it source
code from anywhere. Or you could send it object code from anywhere.

I really like the idea of standalone Forths in every little appliance.
I'd like to think they ought to be good for something. I just have
trouble figuring out what.

Here's one thought -- if you need a host, then you have to get the
*right* host. But if all you need is a terminal, particularly if the
target can upload a copy of its source to you, then you don't need
much compatibility at all. Look at the source, make the changes you
need, test them, upload them permanently. No worries whether it needs
ChipForth Version 1.37 or AMD-Forth 2.3 or MVP-Forth 6.2 . If you have
a terminal, the target itself can sometimes tell you everything you
need to know.

J Thomas wrote:[color=blue]
> On Mar 21, 9:35 pm, "Bruce McFarling" <agil...@netscape.net> wrote:[color=green]
>> On Mar 21, 8:57 pm, John Doty <j...@whispertel.LoseTheH.net> wrote:[/color]
>[color=green][color=darkred]
>>> I can imagine *rare* requirements. But is that really all your Forth is
>>> good for?[/color]
>> I'm curious. You thought nobody would notice the flimsy
>> rhetorical ploy, the pretence that Stephen Pelc was saying this
>> was *the only thing* that his Forth was good for? Really?[/color]
>
> I was making a more charitable interpretation.[/color]

No need to be charitable. Stephen certainly did *not* say that was the
*only* thing his Forth was good for. He said it had this capability and
that it was useful. He didn't mention other capabilities, which doesn't
mean they don't exist, just that they weren't germane to this
discussion. John's remark was a cheap shot.
[color=blue]
> If usually compiling on the target isn't needed, and further umbilical
> Forths tend to be better, then why bother with the claim we can
> compile on small targets? That was real useful in the old days. Why
> not update the claims and put more effort into important things Forth
> does well today?[/color]

It's often very useful. Say you have a product with a zillion copies in
the field in many places, and many employees need access to it to
perform maintenance operations, enter configuration data, and perform
other chores. It's much more practical for them to be able to interact
directly with the target from a terminal emulator than have a whole
cross-compiler environment on everyone's laptop. This is an optional
feature in SwiftX, which we didn't offer with chipFORTH, and it's very
popular. Folks use the full-functioned SwiftX to develop and test their
app, and include the simpler target-resident compiler/interpreter for
maintenance functions. Single-board computers such as New Micros, MPE,
and other vendors offer with a simple Forth on board have also been popular.

Of course a PC-based cross-compiler can be more powerful, generate
optimized code, perform more error checking, and do other cool things,
but sometimes the tradeoff favors the small, simple version.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
[url]http://www.forth.com[/url]

"Forth-based products and Services for real-time
applications since 1973."
==================================================

On Mar 22, 12:15 am, "J Thomas" <jethom...@gmail.com> wrote:[color=blue]
> If usually compiling on the target isn't needed, and further umbilical
> Forths tend to be better, then why bother with the claim we can
> compile on small targets?[/color]

It depends on the target. If the target is a remote data logger,
and the link is over packet radio, the ability to compile on the
target is a substantial advantage, and worth the extra size on
the target ... even if it is a whole $30 to get a TiniArm and
a bit more to get the SPI FlashRAM for the data.

And certainly, the umbilical Forth enjoys many of the benefits of
the JTAG mastering approach, while retaining far more of the
benefits of compiling on the system than the C compiler can offer.
But the fact that it is available to replace a free-standing
compiler means that where a free standing compiler is still
preferable, it can be a strong advantage.

There's much to be said for that kind of flexibility to specialize
in a variety of ways.

On Mar 22, 2:37 am, "Bruce McFarling" <agil...@netscape.net> wrote:[color=blue]
> On Mar 22, 12:15 am, "J Thomas" <jethom...@gmail.com> wrote:
>[color=green]
> > If usually compiling on the target isn't needed, and further umbilical
> > Forths tend to be better, then why bother with the claim we can
> > compile on small targets?[/color]
>
> It depends on the target. If the target is a remote data logger,
> and the link is over packet radio, the ability to compile on the
> target is a substantial advantage, and worth the extra size on
> the target ... even if it is a whole $30 to get a TiniArm and
> a bit more to get the SPI FlashRAM for the data.[/color]

What is the advantage? Is it that source code is more compact than
object code over packet radio? So you don't have to send as much
information? I suppose in either case the target would need to check
for transmission errors. Or perhaps just echo everything back to the
host and let the host do the checking.
[color=blue]
> And certainly, the umbilical Forth enjoys many of the benefits of
> the JTAG mastering approach, while retaining far more of the
> benefits of compiling on the system than the C compiler can offer.
> But the fact that it is available to replace a free-standing
> compiler means that where a free standing compiler is still
> preferable, it can be a strong advantage.
>
> There's much to be said for that kind of flexibility to specialize
> in a variety of ways.[/color]

I agree. I'm just wondering what the specific advantage would be.

Hi John,

On 21 Mar, 22:09, John Passaniti <n...@JapanIsShinto.com> wrote:[color=blue]
> Howerd wrote:[color=green]
> > I think its called having an opinion.[/color]
> Lots of people have opinions. There are people who think the world is
> roughly 6000 years old. There are people who think the moon landing was
> a massive conspiracy/hoax. There are people who think the Holocaust
> never happened. There are people who think there were weapons of mass
> destruction in Iraq.[/color]
I think the world is more than 6000 years old, but that the estimate
of 4.5e9 years is probably way out.
I believe the moon landing did actually happened. I am offended by the
unscientific cultural vandalism of the hoax claims.
I've met people who survived the Holocaust.
There most certainly were WOMD in Iraq, at least on 16th March 1988,
in and around Halabja : [url]http://www.kdp.pp.se/old/chemical.html[/url]
YMMV
[color=blue]
> Yes, lots of people have opinions. And some of those opinions are stupid.[/color]
Yes, some people are stupid.

[snip]
[color=blue]
> I take a jet and land in Brazil. I walk into a restaurant where they
> only speak Portuguese and waiter hands me a menu. It's also in
> Portuguese and I can't read it. I ask the waiter to bring me a
> cheeseburger and fries. He replies in broken English that it's a
> vegetarian restaurant.
>
> Clearly, the restaurant is awful. It was hard to understand anything
> because they use English, and they didn't even have what I wanted. But
> not only is this restaurant awful, I'd say all restaurants in Brazil are
> awful.
>
> Sound familiar?[/color]
No, it sounds patronising.
[color=blue]
>[color=green]
> > Yes - comp.lang.forth is a newsgroup where people chat about their
> > opinions.[/color]
>
> Yes, and it's also a newsgroup where we all *evaluate* those opinions.[/color]
You don't evaluate my opinions, you shout them down.
[color=blue]
> You don't seem to like that part. You apparently want to be respected
> for having an opinion, but not for the quality of that opinion.[/color]
I would like to be respected for expressing my opinions honestly, and
for being prepared to have them questioned, scrutinised and evaluated.
And I reserve the right to change them at any time.
[color=blue][color=green]
> > This is not a court of law where I have to prove beyond all reasonable
> > doubt that my opinion is absolute fact.[/color]
>
> False premise. Absolute fact is not the standard here. Logically
> defending your statements when you are questioned on them is.[/color]
OK, I got that wrong. I am prepared, and hopefully able, to defend my
statements logically.
[color=blue][color=green]
> > I've looked at some open source, and its not very good for what I
> > expected it to be used for. My bad.[/color]
>
> Now you're downgrading your opinion.[/color]
Yes, I'm modifying by views, based on our discussions.
[color=blue]
> This started with your statement
> that open source (quote) "relies on the principle that programming is
> complicated" (unquote).[/color]
Yes, I still think that.
[color=blue][color=green]
> > Ogg Vorbis is a valient effort to stop corporate control of software
> > distribution.
> > No way would I call that junk. The code is perfectly respectable C
> > code, and documents many key functions.
> > My complaint is the difficulty of getting to the code through the
> > "open source" format.[/color]
>
> Flawed argument. If Ogg Vorbis was distributed privately, the quality
> of the code wouldn't magically change. Your beef is with the quality of
> the documentation of Ogg Vorbis. How you morph that into some grandiose
> indictment of open source is not demonstrated by anything you have written.[/color]
My beef is not with the quality of either docs or source code of Ogg
Vorbis or any other open source project.
[color=blue][color=green][color=darkred]
> >> But hey, don't just stop there. Clearly, you can
> >> make sweeping generalizations about all open source software.[/color]
> > Yes. Maybe I'm wrong. Surely everyone reading this must know to
> > question any and all opinions.[/color]
>
> I certainly wish more people in comp.lang.forth would start openly
> questioning the opinions and prevailing assumptions that underscore most
> of the discussion here.[/color]
Yes, absolutely.
[color=blue][color=green][color=darkred]
> >> So because you're a logically consistent man, you would also fault
> >> Charles Moore for his release of the ColorForth source code, since the
> >> assembly-language listing is essentially uncommented, and the supporting
> >> documentation doesn't cover how the kernel works.[/color]
> > No, because Chuck did not release colorForth as open source, just a
> > snapshot of his work for those who were interested.[/color]
>
> The essential quality of open source is that the source code is
> available. Different open source projects make the source code
> available for different reasons. Charles Moore most certainly did
> release ColorForth as open source. To say otherwise suggests you're
> using a very private and very bizarre definition for "open source."[/color]
You are right about my inconsistancy here.

[snip][color=blue]
>[color=green][color=darkred]
> >> Programmers tend to want to hide their expertise? Where is the evidence
> >> for this?[/color]
> > I have anecdotal evidence.[/color]
>
> Wow, that's compelling.[/color]
Is that a question, requesting my anecdotal evidence?

[snip][color=blue]
>
> "wav format" can mean one of several things, but I'll assume you mean
> PCM audio, probably signed integer format. You don't say if it's
> stereo, so I'll assume mono. You also don't specify what the audio is,
> which is important when choosing a codec (is it speech, music, a
> mixture). One would also want to know other details like if this needs
> to operate in real-time or if it is processing offline. And if it is
> real-time, what kind of processor and memory bandwidth do you have.[/color]
Stereo, PCM 16 bit signed, mixed speech and music, real time, running
on a PC.
The comms bandwidth is ~48kbits/s, memory is "more than enough" i.e.
Windows PC
[color=blue]
> MDCT (or variations on it) are part of many audio compression standards
> and yes, it's obviously useful in that context. The question is if the
> specific attributes of MDCT (such as using overlapping buffers) makes
> sense to your application.[/color]

Banter and OT discussions aside, I would appreciate any help in
developing this codec.
(Its a project that might generate income one day),

Regards

Howerd 8^)

On Mar 22, 7:26 am, "J Thomas" <jethom...@gmail.com> wrote:[color=blue]
> What is the advantage? Is it that source code is more compact than
> object code over packet radio? So you don't have to send as much
> information? I suppose in either case the target would need to check
> for transmission errors. Or perhaps just echo everything back to the
> host and let the host do the checking.[/color]

I was thinking of the ability to exercise the functions and have
a shot of working out what is going wrong without going through
multiple write test patch, download test patch results, write
new test patch, download new test patch, write trial fix, write
test patch for trial fix, download results, cycles.

But, yeah, your right, if there is heavy interference, you are
far likelier to get a succesful voice copy from the staff at
the field trial station of the most recent packet if it is
nonsense words than if it is a string of random looking numbers
and characters.