Which FORTH?

[jski]

I haven't used FORTH on an embedded project since circa 1985.

I'm wondering if FORTH, Inc.'s SwiftForth is the current BMW/Mercedes
of FORTH development environments for embedded apps? As a matter of
fact, FORTH, Inc. appears to be the only FORTH dev env provider that's
financially viable???

---John

[Stephen Pelc]

In terms of target performance performance and features, the top of
the range comes from MPE.
http://www.mpeforth.com/xc7.htm

But then, we supply Forth systems.

Stephen


--
Stephen Pelc, steph...@mpeforth.com
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: http://www.mpeforth.com - free VFX Forth downloads

[Elizabeth D. Rather]

FORTH, Inc.'s cross compiler product line is called SwiftX. There are
evaluation versions available for most popular microcontrollers. See
http://www.forth.com/embedded/index.html.

MPE Ltd. in the UK also provides a line of cross-compilers that you can
check out to compare.

And, I'm happy to report that FORTH, Inc. is very financially viable.

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."
==================================================

[jski]

On Sep 15, 8:41 pm, "Elizabeth D. Rather" <erat...@forth.com> wrote:
> On 9/15/11 12:03 PM, jski wrote:
>
> > I haven't used FORTH on an embedded project since circa 1985.
>
> > I'm wondering if FORTH, Inc.'s SwiftForth is the current BMW/Mercedes
> > of FORTH development environments for embedded apps?  As a matter of
> > fact, FORTH, Inc. appears to be the only FORTH dev env provider that's
> > financially viable???
>
> FORTH, Inc.'s cross compiler product line is called SwiftX.  There are

> evaluation versions available for most popular microcontrollers.  Seehttp://www.forth.com/embedded/index.html.

>
> MPE Ltd. in the UK also provides a line of cross-compilers that you can
> check out to compare.
>
> And, I'm happy to report that FORTH, Inc. is very financially viable.
>
> 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 90045http://www.forth.com

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

First, thanks Elizabeth and Stephen.

I'm back in a position to scratch an itch and pursue an embedded
project in FORTH.

Way back, when I worked at Martin-Marietta (when there was a Martin-
Marietta) I worked in an embedded group which was divided into a large
C group and a small but dedicated FORTH group. I quickly noticed that
the FORTHers were simply better engineers. They had a better more
fundamental understanding of the system-under-development - whatever
system that might have been. Simply put: they (the FORTHers) were a
cut above.

I'm going to try to rekindle to embers.

---John

[Anton Ertl]

steph...@mpeforth.com (Stephen Pelc) writes:
>On Thu, 15 Sep 2011 15:03:58 -0700 (PDT), jski
><john.chl...@gmail.com> wrote:
>
>>I haven't used FORTH on an embedded project since circa 1985.
>>
>>I'm wondering if FORTH, Inc.'s SwiftForth is the current BMW/Mercedes
>>of FORTH development environments for embedded apps? As a matter of
>>fact, FORTH, Inc. appears to be the only FORTH dev env provider that's
>>financially viable???
>
>In terms of target performance performance and features, the top of
>the range comes from MPE.

So maybe it is the Aston Martin or Jaguar of Forth systems:-).

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2011: http://www.euroforth.org/ef11/

[Brad]

It depends how much of a minimalist you are. MPE offers an ecosystem,
such as documentation tools and middleware, in addition to a
sophisticated analytical compiler.

FORTH Inc has a simpler kind of native code generation that's not as
good but is more understandable. SwiftX is highly polished and stable.
I ported it to a new processor last year without ever having used
SwiftX before.

-Brad

[jski]

Since for all intents and purposes I'm a newbie, which is better for
newbies?

---John

[Brad]

> ---John- Hide quoted text -
>
> - Show quoted text -

Probably SwiftX. You just click the Build button, and modify the out-
of-the-box sample app to suit your needs. They have free evaluation
downloads.

-Brad

[jski]

Is FORTH, Inc. constantly improving their product?

Does FORTH, Inc. offer an "ecosystem, such as documentation tools and
middleware, in addition to a sophisticated analytical compiler" ?

[Elizabeth D. Rather]

On 9/16/11 8:37 AM, jski wrote:
> On Sep 16, 1:39 pm, Brad<hwfw...@gmail.com> wrote:
>> On Sep 16, 10:27 am, jski<jan.chludzin...@gmail.com> wrote:

...

>>> Since for all intents and purposes I'm a newbie, which is better for
>>> newbies?
>>
>>> ---John- Hide quoted text -
>>
>>> - Show quoted text -
>>
>> Probably SwiftX. You just click the Build button, and modify the out-
>> of-the-box sample app to suit your needs. They have free evaluation
>> downloads.
>>
>> -Brad
>
> Is FORTH, Inc. constantly improving their product?

Absolutely! 5 minor updates so far this year.

> Does FORTH, Inc. offer an "ecosystem, such as documentation tools and
> middleware, in addition to a sophisticated analytical compiler" ?

Not as extensive as MPE's, but the system is very clean,
well-documented, and very easy to understand and modify. Both product
lines are considerably more sophisticated than the Forths you were
familiar with before!

Really, you should download evaluation versions of both and see which
suits you better. And let us know your impressions!

[Mentifex]

On Sep 15, 3:03 pm, jski <john.chludzin...@gmail.com> wrote:

> I haven't used FORTH on an embedded project since circa 1985.

> [...]

You have a lot of Forths to choose from:

http://www.forth.com

http://retroforth.org

http://minforth.net.ms

http://www.quartus.net

http://www.mpeforth.com

http://ronware.org/reva

http://www.colorforth.com

http://www.inventio.co.uk

http://greenarraychips.com

http://code.google.com/p/reda4

http://thebeez.home.xs4all.nl/4tH

http://www.gnu.org/software/gforth

http://pygmy.utoh.org/pygmyforth.html

http://christophe.lavarenne.free.fr/ff

http://home.iae.nl/users/mhx/i4faq.html

http://home.iae.nl/users/mhx/eforth.html

http://sourceforge.net/projects/calforth

http://home.vrweb.de/~stephan.becher/forth

http://home.hccnet.nl/a.w.m.van.der.horst/aiforth.html

[Hugh Aguilar]

On Sep 16, 12:37 pm, jski <jchludzin...@gmail.com> wrote:
> Is FORTH, Inc. constantly improving their product?

Forth Inc. may improve their product, but they don't provide the
upgrades to their customers for free --- you have to pay again.

I paid almost $500 for SwiftForth v2, but it has bugs. Elizabeth
Rather has told me that I have to pay another $300 to get the upgraded
v3 that supposedly has some of the bugs fixed. I'm not going to pay
--- that would just be throwing good money after bad.

I strongly recommend against SwiftForth. I doubt that you will ever
find a customer of Forth Inc. that recommends Forth Inc. to anybody.

I recommend that you write your own cross-compiler --- real Forthers
roll their own! I have written a cross-compiler --- once you figure
out the basic concept, it falls into place fairly easily. You can use
Gforth to do this; Gforth is slow (worse than SwiftForth), but it is
well maintained, and the slow speed isn't an issue with a cross-
compiler because it is doing its thing at compile-time --- the speed
of the generated code on the micro-controller depends upon your own
skill as a cross-compiler writer. Which micro-controller are you
targeting?

> Does FORTH, Inc. offer an "ecosystem, such as documentation tools and
> middleware, in addition to a sophisticated analytical compiler" ?

SwiftForth is not an analytical compiler. It just pastes in functions
whole. For example, consider these primitive functions:

see over
40383F 4 # EBP SUB 83ED04
403842 EBX 0 [EBP] MOV 895D00
403845 4 [EBP] EBX MOV 8B5D04
403848 RET C3

see !
40335F 0 [EBP] EAX MOV 8B4500
403362 EAX 0 [EBX] MOV 8903
403364 4 [EBP] EBX MOV 8B5D04
403367 8 # EBP ADD 83C508
40336A RET C3

These were written with ICODE, which means that they get inlined
rather than have a CALL compiled for them. Here they are being used:

: init-list ( node -- node ) 0 over ! ;

see init-list
46E89F 4 # EBP SUB 83ED04
46E8A2 EBX 0 [EBP] MOV 895D00
46E8A5 0 # EBX MOV BB00000000
46E8AA 4 # EBP SUB 83ED04
46E8AD EBX 0 [EBP] MOV 895D00
46E8B0 4 [EBP] EBX MOV 8B5D04
46E8B3 0 [EBP] EAX MOV 8B4500
46E8B6 EAX 0 [EBX] MOV 8903
46E8B8 4 [EBP] EBX MOV 8B5D04
46E8BB 8 # EBP ADD 83C508
46E8BE RET C3

As you can see, OVER and ! are just pasted in. There is no
optimization being done; the resulting code is both bloated and slow.
In my novice package (http://www.forth.org/novice.html) I have hand-
written a lot of common words in assembly language:

icode init-list ( node -- node )
eax eax xor
eax 0 [ebx] mov
ret

An analytical compiler would have generated code like this on its own.
In SwiftForth however, the user is required to write this kind of
stuff by hand in assembly language in order to obtain anything like
respectable speed. The result is that your program will be SwiftForth
specific and difficult to port to other ANS-Forth systems at a later
date (when you finally realize what a big mistake it was to buy
SwiftForth in the first place). SwiftForth is not really suitable for
use in a commercial environment where you have a deadline to meet,
because fixing SwiftForth's myriad problems takes up too much of your
time. If you do use SwiftFoth however, my novice package does provide
a lot of support (the novice package is ANS-Forth compliant, but it
has a compiler directive that can be turned on to enable SwiftForth-
specific versions of the functions).

There is no documentation tool available with SwiftForth. There are
some such tools available in the public domain that you might be able
to use in conjunction with SwiftForth, but I am not familiar with any
of them so I can't comment. I am not aware of any kind of middleware
available for interfacing any Forth with the outside world, but there
may be something somewhere --- Forth is mostly used for programming
micro-controllers, so interfacing with desktop software (databases or
whatever) isn't really an issue.

[Andreas]

Hugh Aguilar:

> I recommend that you write your own cross-compiler --- real Forthers
> roll their own!

Professionals use professional tools. They are paid for results, not for
doodling around with toolsmithing.

[crc]

On Sep 16, 5:15 pm, Mentifex <menti...@myuw.net> wrote:
> On Sep 15, 3:03 pm, jski <john.chludzin...@gmail.com> wrote:
>
> > I haven't used FORTH on an embedded project since circa 1985.
> > [...]
>
> You have a lot of Forths to choose from:
>
> http://www.forth.com
>
> http://retroforth.org

Retro isn't really intended for embedded use. It's possible to make it
work, depending on the hardware constraints, but unless you have a
fast processor and plenty of ram, it's not going to be comfortable to
work.

My only experience with Retro in an embedded context is a bit of work
with an implementation running on an ARM based microcontroller board
(mbed.org), and with a 16-bit image there's only a few thousand memory
cells of ram free. Additionally, since it's not native, there's also
the overhead from the underlying VM, which makes it too slow for
anything requiring realtime (or near realtime) operation.

> http://minforth.net.ms
>
> http://www.quartus.net
>
> http://www.mpeforth.com
>
> http://ronware.org/reva
>
> http://www.colorforth.com
>
> http://www.inventio.co.uk
>
> http://greenarraychips.com
>
> http://code.google.com/p/reda4
>
> http://thebeez.home.xs4all.nl/4tH
>
> http://www.gnu.org/software/gforth
>
> http://pygmy.utoh.org/pygmyforth.html
>
> http://christophe.lavarenne.free.fr/ff
>
> http://home.iae.nl/users/mhx/i4faq.html
>
> http://home.iae.nl/users/mhx/eforth.html
>
> http://sourceforge.net/projects/calforth
>
> http://home.vrweb.de/~stephan.becher/forth
>
> http://home.hccnet.nl/a.w.m.van.der.horst/aiforth.html

-- crc

[A. K.]

On 16.09.2011 23:15, Mentifex wrote:
> On Sep 15, 3:03 pm, jski<john.chludzin...@gmail.com> wrote:
>> I haven't used FORTH on an embedded project since circa 1985.
>> [...]
>
> You have a lot of Forths to choose from:
>
> http://www.forth.com
>
> http://retroforth.org
>
> http://minforth.net.ms

This old "version" of MinForth is not for embedded projects.
It once just served as simple PC environment for testing Forth code
fragments. It's strength is runtime safety, but the VM is creeping slow.
Multitasking has been cut away too.


<snip>

[Hugh Aguilar]

I was a professional when I wrote MFX; I wasn't getting paid very much
($10/hour), but I was getting paid. The MiniForth was a new processor
--- there were no "professional tools" for developing code for it. The
processor didn't physically exist at the time that I wrote MFX; it was
quite late in the project before we had actual hardware to run code
on. When I wrote MFX, the design of the MiniForth was in flux ---
every day there would be changes made, such as new instructions
provided or existing instructions changed in how they worked, and so
forth --- if there were difficulties in writing some aspect of the
software, the processor's instruction set got changed to alleviate
those difficulties.

Of course, this kind of experience is worthless on a resume. Employers
just want to hear that a candidate has X years of experience working
with whatever "professional tool" that they use at their shop (usually
GCC for the ARM). Unless they are actually planning on using the
MiniForth (nobody ever has used it outside of Testra), then "MiniForth
experience" is meaningless. Also, the fact that I only got paid $10/
hour made the whole experience meaningless, as potential employers
assume that I must have been an entry-level programmer to work for
such a low wage, and they don't hire entry-level programmers. The
irony here is that I was "entry-level" in the sense that I had never
programmed the MiniForth prior to my job working with it (nobody
had!).

Testra did talk to Forth Inc. about them writing the development
system for the MiniForth, but Testra hired me to do it instead. I
think that one of the reasons why Elizabeth Rather attacks me now
http://groups.google.com/group/comp.lang.forth/browse_thread/thread/c37b473ec4da66f1
is because she thinks that I stole her customer. There are very few
people on this planet who are willing to pay money for a Forth cross-
compiler. Most likely, Testra was the only "live customer" who had
approached Elizabeth Rather in many many years, and she was highly
enthusiastic about the prospect of soaking them for a *lot* of money
(a lot more than I asked for and got). She believed that she deserved
to make a lot of money because she knew Chuck Moore way back in the
1970s, and is the "leading expert" on Forth, etc., etc.. When I got
the job, she was angry --- she thought: "Who the hell is Hugh
Aguilar?" --- now she says that my software "sucks" and that I'm no
better than a faggot (Passaniti) who claims to have once written a
Forth-like interpreter in Perl. The whole thing seems ridiculous to
me. I was making so little money at Testra that I couldn't pay my rent
and had to live in my van and sleep in grocery store parking lots and
shower at the health club --- and Elizabeth Rather hates me for
this??? And, ironically, John Hart (owner of Testra) is also mad at me
saying that I was "disloyal" for quitting Testra (I'm an employee, not
an indentured servant; what the hell is he talking about?).

The whole Forth community is corrupt. There is almost no money to be
made programming Forth. Then the Forthers dishonor themselves by
squabbling over the tiny bit of money that is available. Not me though
--- I make my money working as a cab driver --- any Forth programming
that I do nowadays is put in the public domain.

[A. K.]

On 17.09.2011 23:45, Hugh Aguilar wrote:

> The whole Forth community is corrupt.

This is utter nonsense.

[Hugh Aguilar]

It is possible to develop a Forth system for a mainstream micro-
controller (such as the PIC24), but nobody is going to pay for this to
be done. For example, for the PIC24, MicroChip provides a free C
compiler. Pretty much all of the micro-controller manufacturers
provide a free C compiler for their micro-controller (usually based on
GCC). Within this context, there just isn't any money available for
Forth systems. Writing a Forth development system for a mainstream
processor is just done for fun --- it is a hobby --- there is *no*
money to be made.

The only people who are willing to pay money for a Forth development
system, are people who are creating a custom Forth-centric micro-
processor. Chuck Moore is one such person. According to Jeff Fox,
Forth Inc. managed to get $40,000 out of him for Forth development
software. The code was of such poor quality however that it was thrown
away as worthless. $40,000 is a lot of money, but Forth Inc. isn't
going to pull off this trick with them twice --- they've burned that
bridge. But who else is there? There really aren't a lot of people
creating custom micro-processors --- it is a very esoteric skill ---
and among those who are doing this, only a fraction of them are Forth-
centric but most are based on a mainstream instruction-set (such as
the 68000 or the 8032).

In all likelihood, Testra was the *only* potential customer that Forth
Inc. has seen in the last 20 years. When I was at Testra, I was told
that Forth Inc. had asked for an exorbitant amount of money to provide
the cross-compiler for the MiniForth; I don't know the exact figure,
but I expect that it was in the $40,000 range. I think that Elizabeth
Rather was planning on doing the same thing again --- providing some
bug-ridden software and then telling the customer that he has to pay
yet more to get a upgraded version, and continuing to do this until
the customer either runs out of money or grows a brain and realizes
that he is never going to get a working development system. She had to
be seriously disappointed when I stole her potential customer from
her. I think this is why she now strives to convince everybody that
I'm incompetent and a complete novice at Forth.

It is all foolishness though. There is no exorbitant amount of money
available for Forth development software, or even a medium-sized
amount of money. That is all just a fantasy --- there is little or no
money available --- it is not worth getting riled up about.

[Mark Wills]

I think it is true that Forth, *for Forths sake* is a limited market
these days. However, it's just a language. MPE, to my knowledge (I
know nothing about Forth Inc, sorry), do not win business just because
they are a "Forth based" business. They don't win business because
their clients are specifically looking for a project to be implemented
in Forth. They are a consultancy, and they (presumably) compete with
their competitors on price, and time-shedule. The language they
execute thier projects in is really immaterial - it's just a language.

Turning specifically to Forth, one could argue that a good Forth
programmer could potentially complete a project faster than a good C
programmer? Contentious I know, and I'm not really interested in
hearing the endless arguing on that Front; more than likely, in MPEs
case, they have a massive library of reusable code, not to mention a
quarter of a century or more of experience in writing industrial
grade, competitive software.

What I'm saying is, when one says "There's no money to be made from
Forth", yes I agree. But the emphasis shouldn't be placed on Forth.
Forth is just a tool in the toolbox, or a weapon in the armoury. A
weapon is probably a better metaphor, since Forth in the wrong hands
can do a lot of damage ;-)

So, if you are running a small, competive consultancy, I'm sure you
could make a lot of money using Forth. But Forth isn't really the
selling point. The company is. :-)

Mark

[Rod Pemberton]

"Hugh Aguilar" <hughag...@yahoo.com> wrote in message
news:059ccfb3-d529-44f8...@h11g2000vbc.googlegroups.com...

>
> Unless they are actually planning on using the
> MiniForth (nobody ever has used it outside of Testra),
> then "MiniForth experience" is meaningless.
>

Not necessarily ... Two reasons.

First, you know what you coded. They have the rights to the exact code you
coded, but you can still use that knowledge and skill to produce something
similar, if you haven't already. Just don't infringe outright ...

Second, you know the software exists. You probably still have some
"connections" or "relationships" with people there, even if they are bad.
Does MiniForth have some commercial value? Ask for it. You could proffer
to buy it, without placing a monetary value on it ... Just let them know
you're interested in it, if they ever decide let it go. If they want to
know why, just say it's for sentimental reasons until you get an actual
opportunity to posses it. If they get into financial trouble or decide to
close down that aspect of the business, you might get a chance to buy it
cheap or have it gifted to you. Many times, during downsizing or
restructuring, companies just back the software up, shut down the machines,
and the software backup sits in a vault or corner of an office somewhere.
It never gets sold, valued, or used again. One company I worked for had an
entire vault of stuff: computers, software, records, etc, and another had
numerous storage lockers of stuff: electronic prototypes, trade show demo's,
etc. I've received a variety of stuff from businesses I worked for free,
legally. Stuff they didn't want and didn't have the time or motivation to
sell: electronic parts, computers, software, manufacturing scrap. Usually,
they knew it had some value and weren't willing to just throw it in the
trash. For a very brief moment in time, I was offered an entire stock
trading application for almost nothing ... Yup, I was offered software that




was being used to generate multi-millions in profit, for nothing.
Unfortunately, the decision to shut down that part of their business wasn't
actually finalized.

> [...] paid $10/ hour [...]

That probably hurt your resume. Most programmers and positions are
salaried. I.e., they can work you over 40 hours/week without overtime pay.
Salaried means you get the job done regardless of time it requires. That's
why you don't usually see hourly programming positions unless they are for
low pay or entry-level, i.e., overtime pay would be huge for typical
salaries. Back then, you probably would've been paid over 3 times as much
per hour, if you had been salaried, even if entry level. You can hire in as
hourly when desperate. However, you should get to a salaried position,
even if that means forfitting raises. Put the "I got conned into
programming for 'free'" experience behind you. Either decide to get back
into programming or move on to "greener pastures".

> There are very few people on this planet who are willing
> to pay money for a Forth cross-compiler.

I think that's probably true in general, but you never know. It might've
cost them substantially less to buy a cross-compiler than port a large
amount of code. Businesses frequently need stuff an average person would
never need and for much longer time periods. Most businesses don't like
change. Their employees have a way of doing things and stick to it like a
fanatical religion, even if it's entirely broken ...

Switching business software from one platform to another is usually a
challenge. The software must meet the existing needs and you have to have
new hardware that can support the network connections too. If those
connections go to some manufacturing equipment, the interface protocol could
be 40 years old. A computer operations center can have dozens of machines
or more all of which are running something: customer accounts, purchasing,
etc.

> Most likely, Testra was the only "live customer" who had
> approached Elizabeth Rather in many many years, and she was highly
> enthusiastic about the prospect of soaking them for a *lot* of money
> (a lot more than I asked for and got).
>

The established consultants that we hired were payed very well. They were
also expected to deliver on difficult tasks, i.e., be very experienced,
complete on time, etc.

> The whole Forth community is corrupt.

Everybody? Corrupt? Uh ... There are lots of greedy and desperate people.

> There is almost no money to be made programming Forth.

I think that's probably true, in general. But, how do you quantify "no" in
"no money". Zero? $500k/year? $1 million/year? $12ml? $50ml? What? A
very small company I worked for in a bad year would sell about 500 units a
month, e.g., about $6 mil per year in revenue, and had about 40 employees.
In good years, those number went up quite a bit. That was enough to keep
the owners happy and employees satisfied. If they get four or five Forth
maintenance contracts at $1ml each, that's a small business ... There are
many markets you'd think wouldn't make any money, that make lots of it.
E.g., low margins and low volume. But, they do. Why? Businesses need
products and services and pay well for it. Sometimes no one else remains in
the industry. They agressively underpay employees. E.g., ave. company
salary is 15% of ave. revenue per employee ... Wages and salaries are
usually the largest component of business expenses, but they get to write
those off on taxes. Etc. They usually have zero growth though, i.e., "cash
cow". How many industrial business parks do you pass by daily? (many) How
many failures or for lease signs do you see? (few) In just one of numerous
industrial areas that I can drive to, there are over 50 businesses. It's
probably 1/3 square mile in size, i.e., small relative to a typical US
county. I've seen numerous small to mid-size industrial and/or
manufacturing businesses operate for decades without fail. How do they get
money? I've also never seen a Chinese (American) restaurant anywhere go out
of business, but have seen many other restaurants fail.


Rod Pemberton

[Elizabeth D. Rather]

On 9/18/11 9:59 PM, Mark Wills wrote:
...

> I think it is true that Forth, *for Forths sake* is a limited market
> these days. However, it's just a language. MPE, to my knowledge (I
> know nothing about Forth Inc, sorry), do not win business just because
> they are a "Forth based" business. They don't win business because
> their clients are specifically looking for a project to be implemented
> in Forth. They are a consultancy, and they (presumably) compete with
> their competitors on price, and time-shedule. The language they
> execute thier projects in is really immaterial - it's just a language.

FORTH, Inc. has a very similar business model to MPE: we sell Forth
systems as well as books and Forth programming courses, but our primary
revenue is based on contract programming. And, indeed, our primary
competitive advantage is that we are able to complete projects far
quicker and for less cost than our competitors.

> Turning specifically to Forth, one could argue that a good Forth
> programmer could potentially complete a project faster than a good C
> programmer? Contentious I know, and I'm not really interested in
> hearing the endless arguing on that Front; more than likely, in MPEs
> case, they have a massive library of reusable code, not to mention a
> quarter of a century or more of experience in writing industrial
> grade, competitive software.

Yes, that is largely true of FORTH, Inc. as well. But the fact that a
good Forth programmer can complete projects faster than good C
programmers has been demonstrated many times. Most of our customers have
in-house programming staff members who are trained in Forth and do a lot
of the higher-level Forth code, while our programmers do more
system-level code such as drivers, communications protocols, etc. Most
of our customers' programmers were good C programmers before learning
Forth, and they are the first to say that they can work much faster in
Forth, largely because of the interactivity that Rod disdains.

> What I'm saying is, when one says "There's no money to be made from
> Forth", yes I agree. But the emphasis shouldn't be placed on Forth.
> Forth is just a tool in the toolbox, or a weapon in the armoury. A
> weapon is probably a better metaphor, since Forth in the wrong hands
> can do a lot of damage ;-)
>
> So, if you are running a small, competive consultancy, I'm sure you
> could make a lot of money using Forth. But Forth isn't really the
> selling point. The company is. :-)

All true. But I'll add that in the markets in which we work (primarily
embedded systems) it's necessary to have high competency in general
engineering as well as programming. We are frequently working with new
custom hardware, and (like software) it often has bugs. The
interactivity of Forth helps us debug the hardware as well as the
software, but being able to read circuit diagrams and understand how the
electronics works is essential.

[Hugh Aguilar]

On Sep 19, 3:46 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "Hugh Aguilar" <hughaguila...@yahoo.com> wrote in message

>
> news:059ccfb3-d529-44f8...@h11g2000vbc.googlegroups.com...
>
>
>
> > Unless they are actually planning on using the
> > MiniForth (nobody ever has used it outside of Testra),
> > then "MiniForth experience" is meaningless.
>
> Not necessarily ...  Two reasons.
>
> First, you know what you coded.  They have the rights to the exact code you
> coded, but you can still use that knowledge and skill to produce something
> similar, if you haven't already.  Just don't infringe outright ...

It would be great if somebody was building a processor similar to the
MiniForth; then my experience would get me the job for sure.
Unfortunately, nobody is. If somebody ever does do this, they will
likely be doing it on a shoestring budget because they have little
expectation of the project becoming profitable, and they will only be
able to afford to pay $10/hour so I'll be back in the same boat again.
R&D doesn't get a big budget in any company because it only offers a
vague promise toward future profit, which tends to not impress the
"bean-counters" in management very much.

More likely is that I will use my knowledge to write a cross-compiler
(Straight Forth) for the PIC24 or maybe even the ARM, and distribute
it for free to hobbyists.

> Second, you know the software exists.  You probably still have some
> "connections" or "relationships" with people there, even if they are bad.
> Does MiniForth have some commercial value?  Ask for it.  You could proffer
> to buy it, without placing a monetary value on it ...   Just let them know
> you're interested in it, if they ever decide let it go.  If they want to
> know why, just say it's for sentimental reasons until you get an actual
> opportunity to posses it.  If they get into financial trouble or decide to
> close down that aspect of the business, you might get a chance to buy it
> cheap or have it gifted to you.  

My big problem is that I don't know anything about electronics. My
interest is only in programming, but software isn't any good without
hardware. If I owned the rights to my own custom processor it wouldn't
do me any good because I don't know how to build boards!

When I was at Testra, I was told many times that Testra is in the
business of selling boards that do something (generally motion-
control, although they had other products as well). Boards are what
the bean-counters care about (they are "board-counters" really)
because boards are physical things that are in the inventory. Software
is abstract; it is not really in the inventory. I was told many times
that I could get a raise in my wage (enough that I could afford to
rent an apartment) if I were able to build and test boards, and I
would make real money if I were able to design boards.

I don't really know anything about electronics though. I did like
using Forth for testing. Forth is interactive so I could quickly write
test functions that would make the hardware do what it does, and
verify that it was actually doing what it was supposed to do using an
oscilloscope. Forth is much superior to C for this because of its
interpretive mode (STATE is FALSE). This was always done shoulder-to-
shoulder with an electrical engineer however because I didn't know
enough about electronics to use the electrical test equipment myself.

> > [...] paid $10/ hour [...]
>
> That probably hurt your resume.  Most programmers and positions are
> salaried.  I.e., they can work you over 40 hours/week without overtime pay.
> Salaried means you get the job done regardless of time it requires.  That's
> why you don't usually see hourly programming positions unless they are for
> low pay or entry-level, i.e., overtime pay would be huge for typical
> salaries.  

Overtime was never an issue. When I am struggling to figure something
out I can't really work very many hours. Overtime is only an issue
when the programmer is "grinding out" large amounts of fairly mundane
code.

I remember that I was totally baffled as to how to write a cross-
compiler. What I did was go on long bicycle rides to think about the
problem. Doing this I had a eureka moment (riding over by Papago Park)
when I suddenly figured out how to do it. After I got this fundamental
concept figured out, the cross-compiler became easy. It pretty much
just fell into place. Then the cross-compiler became largely a matter
of grinding out code.

Actually, the cross-compiler wasn't really the most difficult aspect
of the project. The assembler was much more complicated. This was
because the processor was a WISC (wide-instruction-set-computer). Up
to 5 instructions could be packed together into a single opcode and
would execute concurrently. My assembler would rearrange the
instructions so that the program would do the same thing as if it were
assembled with one instruction per opcode, but it would pack as many
instructions into each opcode as possible (to minimize the number of
NOP instructions that had to be put in there). I'm not aware of any
other micro-controller that does this --- the technique is only used
in big processors afaik.

[Albert van der Horst]

In article <4a83be8f-629a-40da...@k29g2000yqf.googlegroups.com>,
Hugh Aguilar <hughag...@yahoo.com> wrote:
<SNIP>

>
>Actually, the cross-compiler wasn't really the most difficult aspect
>of the project. The assembler was much more complicated. This was
>because the processor was a WISC (wide-instruction-set-computer). Up
>to 5 instructions could be packed together into a single opcode and
>would execute concurrently. My assembler would rearrange the
>instructions so that the program would do the same thing as if it were
>assembled with one instruction per opcode, but it would pack as many
>instructions into each opcode as possible (to minimize the number of
>NOP instructions that had to be put in there). I'm not aware of any
>other micro-controller that does this --- the technique is only used
>in big processors afaik.

You don't seem to pay attention.
Ever heard of green arrays. GA144? Ring a bell?

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

[Hugh Aguilar]

On Sep 20, 12:18 pm, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:
> In article <4a83be8f-629a-40da-8137-8355f2490...@k29g2000yqf.googlegroups.com>,

> Hugh Aguilar  <hughaguila...@yahoo.com> wrote:
> <SNIP>
>
>
>
> >Actually, the cross-compiler wasn't really the most difficult aspect
> >of the project. The assembler was much more complicated. This was
> >because the processor was a WISC (wide-instruction-set-computer). Up
> >to 5 instructions could be packed together into a single opcode and
> >would execute concurrently. My assembler would rearrange the
> >instructions so that the program would do the same thing as if it were
> >assembled with one instruction per opcode, but it would pack as many
> >instructions into each opcode as possible (to minimize the number of
> >NOP instructions that had to be put in there). I'm not aware of any
> >other micro-controller that does this --- the technique is only used
> >in big processors afaik.
>
> You don't seem to pay attention.
> Ever heard of green arrays. GA144? Ring a bell?

I haven't actually been paying much attention to the Green Arrays
project. I've never heard a clear explanation for what kind of
application such a thing would be used for. AFAIK, it is not a WISC.
The MiniForth had opcodes that executed sequentially like any
processor, but each opcode could contain up to 5 instructions that
executed concurrently during the clock cycle that the opcode executed
in. The trick was to not execute an instruction prior to or
concurrently with the instructions that set the register(s) that the
instructions needs to have already set. That was a fairly simple and
obvious criterium for my assembler to adhere to when it was
rearranging the instructions. By comparison, the Green Arrays thing
seems to be an array of processors that each run a program and the
processors communicate with the neighboring processors over some fast
data channel.

The Green Arrays thing seems to be more complicated than the
MiniForth, but I don't really know enough about it to comment. I
suppose I could do some research on it and try to figure it out. I
would feel a lot more motivated if I knew what the purpose of the
exercise was. With the MiniForth, the purpose was to run the motion-
control program faster than it had been previously run on the 80c320
processor. That was a straight-forward goal that customers cared
about. Has any program been written for the Green Arrays? What did the
program do? Is there some application domain that the Green Arrays is
targeted for? Are there customers?

Chuck Moore presumably knows who I am. If he contacts me I would talk
to him. I wouldn't contact him though, at least not until I have some
glimmer of what the heck he is doing.

[Paul E. Bennett]

Hugh Aguilar wrote:


[%X]

The individual processors in a GA chip are all fairly simple 18bit Forth
Engines that run Asynchronously. Their inter-communication is arranged such
that the collective of processors form a mesh. This is quite useful in terms
of rapidly processing some data then handing the results on to the next bit
of processing that needs to be done.

I have two projects that I am using mine for. The fun one (which I can
discuss) will be a little robot with binocular vision. The aim is to be
running something like "Canny Edge Detection" on the video streams and build
a map of the surroundings area (surfaces and potential pathways) to let the
robot navigate itself around. The other project has rather more commercial
implications and I will not be discussing that here (for obvious reasons).

I can imagine that there are many semi-parallel data processing applications
where the GA144 (or a collection of them) would be more cost effective than
other options.

--
********************************************************************
Paul E. Bennett...............<email://Paul_E....@topmail.co.uk>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

[Hugh Aguilar]

On Sep 21, 11:17 am, "Paul E. Bennett" <Paul_E.Benn...@topmail.co.uk>
wrote:

> The individual processors in a GA chip are all fairly simple 18bit Forth
> Engines that run Asynchronously. Their inter-communication is arranged such
> that the collective of processors form a mesh. This is quite useful in terms
> of rapidly processing some data then handing the results on to the next bit
> of processing that needs to be done.

From what you have described and what I have read elsewhere, the Green
Arrays is loose-coupled concurrency. This is more complicated than
tight-coupled concurrency (such as the MiniForth). On a related note,
Mark Willis tipped me off to PropForth
(http://code.google.com/p/propforth/wiki/PropForth) a while ago. Have
you or anybody else here ever used that? I'd be more likely to go that
way than to delve into Green Arrays --- Chuck Moore may be too far out
for me.

[Jerry Petrey]

On 9/16/2011 6:34 AM, jski wrote:

>
> First, thanks Elizabeth and Stephen.
>
> I'm back in a position to scratch an itch and pursue an embedded
> project in FORTH.
>
> Way back, when I worked at Martin-Marietta (when there was a Martin-
> Marietta) I worked in an embedded group which was divided into a large
> C group and a small but dedicated FORTH group. I quickly noticed that
> the FORTHers were simply better engineers. They had a better more
> fundamental understanding of the system-under-development - whatever
> system that might have been. Simply put: they (the FORTHers) were a
> cut above.
>
> I'm going to try to rekindle to embers.
>
> ---John

Having worked for Martin-Marietta (and later Lockheed Martin) as well as
Forth, Inc., I agree with you. There is something about Forth that
appeals to engineers, just like HP calculators (they both use RPN of
course). I can assure you Forth, Inc makes a quality product and you
will be happy with it. They also have a couple of great books on Forth.
(Elizabeth is too modest to remind people that she was the world's
second Forth programmer who worked with its inventor, Chuck Moore.)

Best of luck,

Jerry Petrey

[Hugh Aguilar]

On Sep 21, 9:13 pm, Jerry Petrey <gpet...@earthlink.net> wrote:
> Having worked for Martin-Marietta (and later Lockheed Martin) as well as
> Forth, Inc., I agree with you.  There is something about Forth that
> appeals to engineers, just like HP calculators (they both use RPN of
> course).  I can assure you Forth, Inc makes a quality product and you
> will be happy with it.  They also have a couple of great books on Forth.
> (Elizabeth is too modest to remind people that she was the world's
> second Forth programmer who worked with its inventor, Chuck Moore.)
>
> Best of luck,
>
> Jerry Petrey

I said that no customer of Forth Inc. can be found who will say
anything good about Forth Inc., but apparently Forth Inc. employees
will say that Forth Inc. is great --- Jerry doesn't tell us whether he
was a salesperson or a programmer though...

If he was a programmer, perhaps he was the programmer who wrote this
code:

ICODE ALIGNED ( a -- a )
RET END-CODE
\ aligned is noop, no alignment enforced

ICODE ALIGN ( -- )
RET END-CODE
\ align is noop, no alignment enforced

Or maybe he was the programmer who wrote this code:

: FEXPM1 ( r -- r ) FEXP #1.0E F- ;
\ (e to the x) - 1

: FLNP1 ( r -- r ) #1.0E F+ FLN ;
\ ln(x+1)

Here is an example of Elizabeth Rather being modest:
http://www.forth.com/resources/evolution/index.html

[Brad]

On Sep 16, 3:44 pm, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
> An analytical compiler would have generated code like this on its own.
> In SwiftForth however, the user is required to write this kind of
> stuff by hand in assembly language in order to obtain anything like
> respectable speed.

Or wrap the heavy stuff in a DLL, compiled by a good C compiler.
That's what I did, and it was especially convenient because the
algorithms and compilers were free for download.

-Brad