Anyone programming Windows apps in Forth?
John Dunn
work or CE work, but real, user interface intensive Windows apps? If so,
which Forth?
Both Forth, Inc. SwiftForth and MPE FVX look impressive, but the Windows
interface is still daunting and not at all like the elegant simplicity that
is Forth itself. iForth looks good too, especially the price and open
license. But as far as I can tell, there is no Windows GUI interface at
all.
As a long time Forth programmer, who turned to the dark side some 3 years
ago, to Visual Basic, and now (mostly because VB is about to become an
orphan) taking another look at Forth for Windows...I would really appreciate
any insight anyone here who is actually using Forth in a Windows app can
share.
John Dunn
Algorithmic Arts
http://algoart.com
Andreas Klimas
>
> Is anyone doing Windows applications in Forth anymore? Not embedded system
> work or CE work, but real, user interface intensive Windows apps? If so,
> which Forth?
that's a good question. I think one of the biggest advantages
of using Forth is the ability to remove complexity. this ends
(hopefully) in reliable programs. to have a reliable small
and well fitted program in Windows does not make sense to me.
because the base of all (Windows) isn't small and reliable.
it's like running a realtime application in Windows :-)
on the other side, if GUI programming is a must, I really
don't know how well Forth fits in this direction - sorry.
>
> Both Forth, Inc. SwiftForth and MPE FVX look impressive, but the Windows
> interface is still daunting and not at all like the elegant simplicity that
> is Forth itself.
this sounds nice, is it possible to write simple GUI applications
in Forth for Windows ? I don't think so because highly interactive
GUI systems are not simple.
may be Jeff Fox has good ideas. on his site he mentioned about some
thoughts for his OS 'AHA', but I didn't found real hints. may be it
is possible to design a small and simple GUI system based on WinXX.
a discussion around this topic would be nice.
> As a long time Forth programmer, who turned to the dark side some 3 years
> ago, to Visual Basic, and now (mostly because VB is about to become an
> orphan)
actually there is a Java hype and many customers of us would
like their programs written in Java, so we get money this way.
some years ago, same customers would like their programs written
in Smalltalk. well, let us make Forth a hype :-)
for me, after Smalltalk and Forth, Java is horrible.
> taking another look at Forth for Windows...I would really appreciate
> any insight anyone here who is actually using Forth in a Windows app can
> share.
me too.
Andreas
John A. Peters
install the widgets, the cost of the parts and the total cost for that
line entry.
In the following example where abbreviations are used as follows.
PL is plug,
SW is switch and
LT is light
Name of item Work to be done (abreviated) Time Cost
Dishwasher PL CB Circuit Cord 1.90 184.57
Disposal -->? PL CB Circuit Cord SW 2.75 264.46
Refrigerator PL 0.85 79.89
Stove Igniter PL 0.85 79.89
Counters 6 PL 2 GFCI 5.20 512.42
Util Circuits 2 CB 2 Circuit 1.60 158.20
Kitchen Layout 1 Hour Electrician 1.00 87.50
Total parts Total time Total Price
Kitchen Power 921.40 +1/3 14.15 hrs 1,366.93
NOTE
<--These items are typed in to the editor--> <-Forth emits these->
The first colums are entered by the user who then hits Ctrl+E to
extend the prices and the columns. The numbers are EMITed to the
screen (and file) automatically.
This application is not yet completly converted from DOS (F83S) to
Windows (Win32Forth) but the DOS version has been in use for over
ten years. I can easily and gladly demonstrate the DOS version to
any one interested via the use of VNC (Virtual Net Computer) which is
available via a search for VNC on Google.
When you get to the site VNC for windows is the 3rd check box where
it says Windows9x/2000 in bold lettering, not choice #11
After the down load finishes, choose SAVE to disk not Open
Click on the icon to install it and then give me an eMail to set up
a time via jape...@pacbell.net or a phone call at 415-509-3599 in
San Francisco.
John A. Peters
Stephen Pelc
wrote:
>Is anyone doing Windows applications in Forth anymore? Not embedded system
>work or CE work, but real, user interface intensive Windows apps? If so,
>which Forth?
lines of Forth source code. This is the software that planned the
new Hong Kong airport and is used all over the world. The system
was written using MPE's Forths for Windows.
Stephen
--
Stephen Pelc, s...@mpeltd.demon.co.uk
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.mpeltd.demon.co.uk - free VFX Forth downloads
John Dunn
> that's a good question. I think one of the biggest advantages
> of using Forth is the ability to remove complexity. this ends
> (hopefully) in reliable programs.
I completely agree. Plus Forth is such a nice interactive environment.
Plus, once you get used to it, Forth syntax is such a pleasure to use. It's
like the HP stack-type calculators, once you start using them, the old
parantheses type calculators feel awkward and obtuse.
> to have a reliable small
> and well fitted program in Windows does not make sense to me.
> because the base of all (Windows) isn't small and reliable.
> it's like running a realtime application in Windows :-)
Right. But that is exactly what I need to do, run realtime apps in Windows.
Which is why I would like to use Forth. It gets rather circular.
> on the other side, if GUI programming is a must, I really
> don't know how well Forth fits in this direction - sorry.
...which is why I am asking others who may have done it, to let us know how
they faired. To know something can be accomplished is to be well on the way
to having it accomplished.
> > Both Forth, Inc. SwiftForth and MPE FVX look impressive, but the Windows
> > interface is still daunting and not at all like the elegant simplicity
that
> > is Forth itself.
>
> this sounds nice, is it possible to write simple GUI applications
> in Forth for Windows ? I don't think so because highly interactive
> GUI systems are not simple.
No, they are not. But Microsoft did it with their Visual paradigm. I don't
think Forth needs a Visual type interface, but a better means of wrapping
Windows programming constructs should be possible. Both MPE and Forth, Inc.
have taken a very good first step in this, but I don't think it goes far
enough to pull in people who aren't already highly motavited to program
their application in Forth.
John
Algorithmic Arts
http://algoart.com
Bernd Paysan
> > this sounds nice, is it possible to write simple GUI applications
> > in Forth for Windows ? I don't think so because highly interactive
> > GUI systems are not simple.
>
> No, they are not. But Microsoft did it with their Visual paradigm. I don't
> think Forth needs a Visual type interface, but a better means of wrapping
> Windows programming constructs should be possible. Both MPE and Forth, Inc.
> have taken a very good first step in this, but I don't think it goes far
> enough to pull in people who aren't already highly motavited to program
> their application in Forth.
I'm not convinced that GUIs "are not simple". The way large commercial
GUI libraries are build clearly results in a hodgepodge of complex
interfaces, but that's not part of the problem, but part of the way they
try to solve it (just like any other coordinated effort of hundrets of
developers automatically results in bloat just by putting so many people
on the task).
MINOS for sure itself is not a really simple piece of work, as it has to
deal with two and a half different graphic libraries (Win32, X, OpenGL),
but after that gluing is done, it is fairly simple to program. All the
GUI stuff I've done in MINOS was much simpler than writing the program
logic it covers, in contrast to the typical estimation, that writing a
GUI is at least as time-consuming as the underlying project.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Marcel Hendrix
[..]
> Both Forth, Inc. SwiftForth and MPE FVX look impressive, but the Windows
> interface is still daunting and not at all like the elegant simplicity that
> is Forth itself. iForth looks good too, especially the price and open
> license. But as far as I can tell, there is no Windows GUI interface at
> all.
'At all' is wrong. iForth assumes the user has acquired a resource editor
from another source. Resources (not OCX!) are loaded dynamically into iForth.
I've done my best to use as little window-specifics in iForth as possible.
Most message loops are behind the scenes and programs (even graphics ones)
still look to the programmer like they are commandline and KEY based.
Appended is the smallest windows example in the iForth distribution.
-marcel
==============================
(* LANGUAGE : ANS Forth
* PROJECT : Forth Environments
* DESCRIPTION : Testing the GUI extensions available from WIN32
* CATEGORY : Example code
* AUTHOR : Marcel Hendrix, May 9, 1998
* LAST CHANGE : Marcel Hendrix, May 9, 1998
*)
NEEDS -dialogs
REVISION -basicapp "ÄÄÄ Basic Application Version 1.00 ÄÄÄ"
DOC
(*
Adapted from WinForth application skeleton with frame window, DEMO04.4TH.
Note that (in practice) there is no need to *change* anything, only to
*add* the real application code. This is the standard framework for an
iForth base application.
*)
ENDDOC
-- Standard identifiers for menu items
#600 =: IDM_FILEEXIT
#601 =: IDM_FILEABOUT
-- Standard sub-menus
0 VALUE appmenu
CURRENT-FILE: $NAME
-- display error message and OK button in message box
: ERRORBOX ( c-addr u -- )
$NAME COUNT \ messagebox title
W: MB_ICONHAND
W: MB_SETFOREGROUND OR
W: MB_OK OR \ icon, button
MSGBOX ;
:NONAME ( hDlg msg wParam lParam -- result )
LOCALS| lParam wParam msg hDlg |
W: WM_INITDIALOG msg = IF 1 EXIT ENDIF
W: WM_HELP msg = IF S" Help?!" ERRORBOX 0 EXIT ENDIF
W: WM_COMMAND msg <> IF 0 EXIT ENDIF
wParam $FFFF AND TO msg
W: IDOK msg = IF hDlg #11 END-DIALOG 0 EXIT ENDIF
W: IDCANCEL msg = IF hDlg #10 END-DIALOG 0 EXIT ENDIF
0 ; 4 CALLBACK modal_handler
-- Load a modal dialogbox from the forthpad.RES file
S" forthpad.h" S" forthpad.res" CREATE-RESOURCE :res:
IDD_4APPLICATION :res: FIND-DIALOG-ID
modal_handler ==: modaldialog
: (DELETE-PROC) ( u -- )
DROP HWND 0= IF EXIT ENDIF
S" Closing application" ERRORBOX
appmenu MITEM-DELETE
S" Graphics Terminal" SETWINDOWTITLE \ set frame window caption
#-201 SETICON \ set icon from exe;
\ range = 201 .. 222
W: SW_MINIMIZE SHOW-WINDOW DROP
0 INSTALL-WINPROC CLEAR HWND ;
: DELETE-PROC ( -- )
0 (DELETE-PROC) ;
:NONAME ( hwnd msg wParam lParam -- result )
LOCALS| lParam wParam msg hwnd |
W: WM_COMMAND msg <> IF 1 EXIT ENDIF
wParam $FFFF AND TO wParam
wParam IDM_FILEEXIT = IF delete-proc 0 EXIT ENDIF
wParam IDM_FILEABOUT = IF modaldialog RUN-MODALDIALOG DROP 0 EXIT ENDIF
1 ; 4 CALLBACK winproc_handler
-- "main word" of sample application;
: DEMO ( -- )
$NAME COUNT SETWINDOWTITLE \ set frame window caption
#22 CHOOSE #201 + NEGATE SETICON \ set icon from exe;
\ range = 201 .. 222
CREATE-POPUP TO appmenu
0 appmenu W: MF_POPUP S" &Application" MITEM-APPEND
appmenu IDM_FILEEXIT W: MF_STRING S" &Stop" MITEM-APPEND
appmenu 0 W: MF_SEPARATOR S" " MITEM-APPEND
appmenu IDM_FILEABOUT W: MF_STRING S" &About" MITEM-APPEND
winproc_handler INSTALL-WINPROC
FORCE-FOREGROUND ;
' (DELETE-PROC) IS-FORGET DEMO
:ABOUT CR ." iForth basic Windows application loaded."
CR ." To run the demo, type: DEMO <Enter> "
CR ." Exit with STOP on the Application Popup of the Graphics Terminal."
CR ." (This demo does nothing, but try ``About'')"
CR ;
.ABOUT -basicapp CR
(* End of File *)
Andreas Klimas
>
> John Dunn schrieb:
> > > this sounds nice, is it possible to write simple GUI applications
> > > in Forth for Windows ? I don't think so because highly interactive
> > > GUI systems are not simple.
> >
> > No, they are not. But Microsoft did it with their Visual paradigm. I don't
> > think Forth needs a Visual type interface, but a better means of wrapping
> > Windows programming constructs should be possible. Both MPE and Forth, Inc.
> > have taken a very good first step in this, but I don't think it goes far
> > enough to pull in people who aren't already highly motavited to program
> > their application in Forth.
>
> I'm not convinced that GUIs "are not simple".
whats about drag/drop, context sensitive popup and pulldown menus
(which enables and disables context dependend). hierarchical
(sorted) trees and so on ?
might GUI systems like HTML Forms could be a simple solution.
Andreas
Jos v.d. Ven
"John Dunn" <john...@charter.net> schreef in bericht
news:u3rqunb...@corp.supernews.com...
> Is anyone doing Windows applications in Forth anymore? Not embedded
system
> work or CE work, but real, user interface intensive Windows apps? If so,
> which Forth?
Did you look at Win32Forth ?
You can download it from http://home.wxs.nl/~josv
Jos
Elizabeth D. Rather
>
> Is anyone doing Windows applications in Forth anymore? Not embedded system
> work or CE work, but real, user interface intensive Windows apps? If so,
> which Forth?
I posted this message (unedited) on the SwiftForth email group, and will
post relevant replies. Here's one.
From: "Robert Dickow" <dic...@uidaho.edu>
To: <sft...@forth.com>
Subject: [sftalk] Re: [Fwd: Anyone programming Windows apps in Forth?]
Date: Thu, 10 Jan 2002 17:13:59 -0800
Concerning Forth + Windows application programming, I recently finished
a
full-fledged Windows interface to a web page management system. The
system
manages our music department event calender, allowing our office
secretaries
to enter and edit concert/recital/lecture events at their desks. The
program
is basically a database manager that generates web pages, produces
wordprocessor-ready fliers, text files, reports, automatic ftp services,
and
many other features, and transparently uploads the material to the
university web server directories. The program has a complete
button/window/menu-based interface. I may be releasing this system to
shareware at some point.
I found the SwiftForth environment perfectly easy to program in, much
nicer
than C. However, I did have to do a lot of the interface design from a
pretty low level. Compared to that, try Borland JBuilder and see that it
only takes a few minutes to create a windowed interface and have it
generate
all the Java code for you. Such utilities also exist in the C world, and
such programs are probably big selling points for a development
environment.
Interface programming is onerous at best. I can program the core
algorithms
for a program in a day or two, but spend months on the interface. Ugh!!!
This is a problem with all modern graphical interfaces. The Windows API
came
pretty easily to me, having had experience programming for the Amiga
Intuition API, which is somewhat analogous in design.
Bob Dickow
Assoc Professor of Music
Lionel Hampton School of Music
--
================================================
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
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
================================================
Elizabeth D. Rather
>
> Is anyone doing Windows applications in Forth anymore? Not embedded system
> work or CE work, but real, user interface intensive Windows apps? If so,
> which Forth?
Here's another:
From: "Mike Ghan" <mike...@logix-controls.com>
To: <sft...@forth.com>
Subject: [sftalk] Re: [Fwd: Anyone programming Windows apps in Forth?]
Date: Thu, 10 Jan 2002 19:18:59 -0800
We have been providing custom Operator Interface software developed with
SwiftForth for our industrial control systems for about 6 months now.
It features real-time animation, trend data plotting and ODBC export,
context-sensitive HTML help, TCP/IP and TAPI (Modem) access. We had no
previous Windows programming experience, our previous product, while
graphical, was DOS based. While there is always room for improvement,
we estimate our OI development time has been cut by a third.
http://www.logix-controls.com/snapshot/Clarity.html
Best Regards,
Mike Ghan
Doug Hoffman
writes:
>that's a good question. I think one of the biggest advantages
>of using Forth is the ability to remove complexity. this ends
>and well fitted program in Windows does not make sense to me.
>because the base of all (Windows) isn't small and reliable.
>it's like running a realtime application in Windows :-)
>
>don't know how well Forth fits in this direction - sorry.
I suppose the question of GUI programming depends on your
intended users.
As for how well Forth fits when programming for a GUI
environment, I have to ask why shouldn't it fit?
I've seen what can be done with Forth on the Mac OS and
the fit looks pretty darn good.
-Doug
Jerry Avins
breaks a little more nicely? Edit after pasting, quoting (at least with
Netscape) or forwarding should all work. Thanks.
Jerry
--
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------
John Dunn
news:a1na8m$df4$1...@reader05.wxs.nl...
>
> Did you look at Win32Forth ?
I have followed the development of Win32Forth over the years with great
interest. It is an amazing system that Tom Zimmer and all those who helped
him have created; a real public service.
But for a commercial application, I would never use a Public Domain Forth.
Not ever, no matter how impressive it is. Commercial apps go out to
thousands, if not hundreds of thousands of users. They need the kind of
support, robustness, and high performance that only a full time active
commercial provider can provide.
Andreas Klimas
like Linux, gcc, and so much other tools ?
Andreas
John Dunn
"Andreas Klimas" <kli...@k-r.de> wrote in message
news:3C4056C6...@k-r.de...
> like Linux, gcc, and so much other tools ?
Well, I wouldn't be using Linux as part of my application - it is an
operating system. But, yes, For a commercial release I would want robust
commercial support. Period. This does not apply if I am programming
something as a prototype, maybe, or for my own use. But released software
goes out to every imaginable computer configuration, and many I couldn't
imagine. My time is limited, and if I am working for weeks or months on a
commercial project, I don't want is squandered because I tried to save a few
dollars (or even a lot of dollars) working with free but unsupprted PD
tools.
Andreas Klimas
you are right and you are not right. I agree with using
reliable comercial products. the problem is to know how
to decide the correct company/product. defects are also
in comercial products and companies will come and go.
some years ago we have decided to use a comercial SQL database
for Linux. this database had many defects and most of them
were repaired. but it was a waste of time and this database
is dog slow and even contains strong bugs. about two years ago
this company has been closed and we don't get support further.
before Linux we have used UnixWare (those days from Novell)
and there were even many havy bugs (the only UNIX I know where
you get 'vi' to fail). we have payed much money for UnixWare
and a comercial SQL sever. the only support we got was to
reformat our hard disk and reinstall UnixWare (we did it
several times).
since we have changed to using open source databases we get
support from newsgroups and our reported defects would be
repaired in a week or shorter. and if not, we have the source code
to do self the correction.
we are responsible for our programs (complete systems). our customers
don't care from where defects are coming - we are responsible anyway.
this is the reason why I like the idea of Forth. the total amount
of used software components should be as small as possible. so
there simply couldn't be that much defects. it doesn't metter
if it is PD or not. for me quality and reliablitity of product
and support is important. I think WinXX and Access are also comercial
products, but I don't trust M$ nor Access so I simply did't use them.
I like the idea of having only Forth as OS.
Andreas
William Stewart
I understand your concern for support of your customers!
There is only one area that I have experienced with
commercial products (not procured by the military).
They change! Often they don't even tell you that it is
planned/has happened! If you control your own source
you don't have to worry about this problem.
As Tom would say, just a thought
Bill S.
Gary Chanson
"William Stewart" <bi...@neto.com> wrote in message
news:3C40C94D...@neto.com...
> John:
> I understand your concern for support of your customers!
> There is only one area that I have experienced with
> commercial products (not procured by the military).
> They change! Often they don't even tell you that it is
> planned/has happened! If you control your own source
> you don't have to worry about this problem.
Successful commercial products keep backward compatibility in mind (but
not TOO much in mind).
--
-GJC
-gcha...@shore.net
-War is the last resort of the incompetent.
Bernd Paysan
> since we have changed to using open source databases we get
> support from newsgroups and our reported defects would be
> repaired in a week or shorter. and if not, we have the source code
> to do self the correction.
I think what John Dunn really wants is "robust support" without
attribute. He just assumes that you get robust support from commercial
vendors, because they advertize that. PD or free software systems may or
may not have that robust support, it just depends on how much time the
developers can spent on the product, how much they care, or if they lose
interest, and leave the project orphaned. Fixing an orphaned program
yourself is then still possible (in contrast to commercial software,
which is completely unfixable once orphaned).
However, commercial support is often more a joke than anything else, and
the only obviously commercial part of it is the price. E.g. the company
I work for has "support" from Cadence. Their software is really buggy.
Unfortunately, they have a sort of monopoly, and the stuff they aquired
from other companies by swallowing them actually is quite usable (just a
pity that these companies don't exist anymore). Support however costs
millions. And they won't help nor fix bugs.
E.g. their software is still limited to 8 bit depth. You either have to
use an overlay or cripple your graphic card to 8 bit. There software
also has some timing problems. You save a view, and perform another
operation, and after hours of waiting, it tells you that the view you
saved *before* is newer than the data this program has extracted from
that view. Cadence just tells us that they don't know what to do. For a
support fee that exceeds a million dollar.
That's how bigFORTH's and Gforth's support works: I'm interested in
bigFORTH and Gforth working, because I use them myself. It gets more
difficult for parts I don't use, e.g. the debuggers, or ports to
operating systems I don't use (Windows ;-). I'll still fix these bugs,
but it might take more time. And maybe the bug report has to be more
precise, because I'm less inclined to search long for the reason. But at
least, you can directly reach the programmer.
However, commercial support from big companies works different. You
don't reach the programmers, but some people in low-cost contries that
do the telephone hotline. If you are lucky, they know that the big
company actually has the product you are demanding support for. They
won't be able to give help, and the bugs you report won't be fixed,
though. But it's commercial support, because they'll charge you like
telephone sex. I'd recommend to use a sex line directly, because the
people there are more friendly, and the likelyhood that they know a
solution to your problem is actually higher (there's a Dilbert cartoon
on this issue - a typo in the manual caused people to dial a telephone
sex service, and complaints about the hotline were ways down ;-).
Bernd Paysan
> whats about drag/drop, context sensitive popup and pulldown menus
> (which enables and disables context dependend). hierarchical
> (sorted) trees and so on ?
Ok, I haven't yet implemented drag&drop in MINOS, mostly because X has
several of them (i.e. raises the bar to do it right: if anything, I'd
want to d&d with at least Gnome and KDE, plus another d&d interface to
Windows). Once that would be done, the act of d&d covering itself would
be dead easy, it would be just another method for the action part of an
object, and you'd have to define code for it (or take default actions)
to handle d&d.
MINOS often provides only "underlying constructs" to do something. E.g.
take hierarchical trees. MINOS doesn't provide a "hierarchical tree view
widget", like Windows does. But it provides a toggle icon (with two
states and switching between two icons depending on state), and a way to
show/hide a box. So each nested layer of a tree view is a toggle button,
a title line (for the tree itself), and below a box with the foldable
elements. The toggle button's action is to show or hide the box below.
Creating the tree view is dead easy, e.g. the tree constructor in the
class browser is 14 lines long.
Same can be done for context sensitive popups or pulldowns. You put the
context sensitive parts into boxes that hide or show depending on the
context. Or you write some code that creates a menu, and adds only items
that are valid in the current context (since once displayed, the menu
won't change, except if you want to implement something like what
Windows and Office 2k provide: crippled menus).
Elizabeth D. Rather
> Andreas Klimas schrieb:
> > since we have changed to using open source databases we get
> > support from newsgroups and our reported defects would be
> > repaired in a week or shorter. and if not, we have the source code
> > to do self the correction.
>
> I think what John Dunn really wants is "robust support" without
> attribute. He just assumes that you get robust support from commercial
> vendors, because they advertize that. PD or free software systems may or
> may not have that robust support, it just depends on how much time the
> developers can spent on the product, how much they care, or if they lose
> interest, and leave the project orphaned. Fixing an orphaned program
> yourself is then still possible (in contrast to commercial software,
> which is completely unfixable once orphaned).
The "Pro" versions of our products include complete source, even the
meta compiler for the kernel, so if you wish to, you can be completely
self-sufficient. "Commercial" does not automatically equate to "no
source."
> ...
>
> However, commercial support from big companies works different. You
> don't reach the programmers, but some people in low-cost contries that
> do the telephone hotline. If you are lucky, they know that the big
> company actually has the product you are demanding support for. They
> won't be able to give help, and the bugs you report won't be fixed,
> though. But it's commercial support, because they'll charge you like
> telephone sex. I'd recommend to use a sex line directly, because the
> people there are more friendly, and the likelyhood that they know a
> solution to your problem is actually higher (there's a Dilbert cartoon
> on this issue - a typo in the manual caused people to dial a telephone
> sex service, and complaints about the hotline were ways down ;-).
Ahem, it was Forth we were talking about. I doubt if any commercial
Forth houses could afford that type of service (either call-center drones
_or_ sex lines ;-) even if we wanted to.
Our support is provided by experienced engineers who are using
the products daily.
Cheers,
Elizabeth
Andreas Klimas
>
> Bernd Paysan wrote:
>
> > Andreas Klimas schrieb:
> > > since we have changed to using open source databases we get
> > > support from newsgroups and our reported defects would be
> > > repaired in a week or shorter. and if not, we have the source code
> > > to do self the correction.
> >
> > I think what John Dunn really wants is "robust support" without
> > attribute. He just assumes that you get robust support from commercial
> > vendors, because they advertize that. PD or free software systems may or
> > may not have that robust support, it just depends on how much time the
> > developers can spent on the product, how much they care, or if they lose
> > interest, and leave the project orphaned. Fixing an orphaned program
> > yourself is then still possible (in contrast to commercial software,
> > which is completely unfixable once orphaned).
>
> The "Pro" versions of our products include complete source, even the
> meta compiler for the kernel, so if you wish to, you can be completely
> self-sufficient. "Commercial" does not automatically equate to "no
> source."
yes, this is true for your product and this is quite seldom.
try to get source code for IBM VisualAge or CINCOM VisualWorks :-)
> > However, commercial support from big companies works different. You
> > don't reach the programmers, but some people in low-cost contries that
> > do the telephone hotline. If you are lucky, they know that the big
> > company actually has the product you are demanding support for. They
> > won't be able to give help, and the bugs you report won't be fixed,
> > though. But it's commercial support, because they'll charge you like
> > telephone sex. I'd recommend to use a sex line directly, because the
> > people there are more friendly, and the likelyhood that they know a
> > solution to your problem is actually higher (there's a Dilbert cartoon
> > on this issue - a typo in the manual caused people to dial a telephone
> > sex service, and complaints about the hotline were ways down ;-).
>
> Ahem, it was Forth we were talking about. I doubt if any commercial
> Forth houses could afford that type of service (either call-center drones
> _or_ sex lines ;-) even if we wanted to.
>
> Our support is provided by experienced engineers who are using
> the products daily.
yes, the forth community is small and we know us (more or less).
but there are tons of others companies where the support is
equal or lower a sex hotline, as mentioned (like our UnixWare vender).
so this is a sensitive subject.
Andreas
Anton Ertl
"Elizabeth D. Rather" <era...@forth.com> writes:
>Ahem, it was Forth we were talking about. I doubt if any commercial
>Forth houses could afford that type of service (either call-center drones
>_or_ sex lines ;-) even if we wanted to.
You mean, you cannot even afford that?-) Seriously, though, I remember
complaints (IIRC by Wolfgang Allinger) about IIRC LMI Forth support;
but then, LMI are no longer in the Forth business, are they?
- 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
John Dunn
I also taught Forth to art and music students at the University of Michigan
using LMI Forth. Always, Ray Duncan gave extremely good tech support. Fast,
accurate, and complete. I never had a complaint abut support from him, and
there were times when I was somewhat of a pest.
Ray Duncan's LMI Forths were excellent commercial products, that evolved as
the computer platforms evolved. Fast, robust, and complete. Additionally,
Ray did not orphan his products when he went out of the Forth business. He
released the still evolving Windows Forth as a PD; the other Forths were
fully mature.
LMI was exactly the kind of commercial company I think of when I say I want
commercial support. It does not have to be big; it just has to have a full
time commitment of some very good people. And it only takes a short time to
weed out the good from the pretenders.
As best as I can tell, the 3 commercial Forths I am aware of - SwiftForth,
VFX, and iForth - all exhibit this kind of dedicated support from their
respective providers, and I would be comfortable in using Forth from any of
them. No one can really tell whether a company is going to stay around
(want to buy some Enron stock?), but you can get a fair handle on how they
act while they are. Of course it helps one sleep at nights when buying the
source code is an option.
Some PD or political-License folks are very good at support also, but
generally only while they are focused on the product, and as was posted
earlier, often with uneven support depending (naturally) on the author's
personal interest. The idea of *customer* support is non existent and
irrelevant. I think these people are doing a terrific service. PD is often
the best place to start while in learning mode, maybe even while in
prototype mode. But not as a foundation for a commercial release unless of
course you (your company) essentially becomes the commercial vendor of the
previously PD product. But that's another issue entirely.
John Dunn
Algorithmic Arts
http://algoart.com
This is the kind of commercial support I referred to in an earlier post.
"Anton Ertl" <an...@mips.complang.tuwien.ac.at> wrote in message
news:a1trae$ga3$1...@news.tuwien.ac.at...
Stephen Pelc
wrote:
>However, commercial support from big companies works different. You
>don't reach the programmers, but some people in low-cost contries that
>do the telephone hotline.
Just to set the record straight, there are people on this newsgroup
who get their technical support from MPE from me and other working
programmers. This is Forth we are talking about, isn't it? The Forth
vendors are all small companies and we take advantage of being small.
Small companies by comparison with big companies.
Felix Franz
> "Elizabeth D. Rather" wrote:
[snip]
>>The "Pro" versions of our products include complete source, even the
>>meta compiler for the kernel, so if you wish to, you can be completely
>>self-sufficient. "Commercial" does not automatically equate to "no
>>source."
>>
>
> yes, this is true for your product and this is quite seldom.
> try to get source code for IBM VisualAge or CINCOM VisualWorks :-)
Slightly offtopic:
the VisualWorks NonCommercial-version includes the full Smalltalk-source
without VM-source. If you are a paying customer you can get the source
for the VM also.
Cheers,
felix
Anton Ertl
"John Dunn" <john...@charter.net> writes:
>I used LMI Forth from the z80 days all the way through 386 Protected Mode.
>I also taught Forth to art and music students at the University of Michigan
>using LMI Forth. Always, Ray Duncan gave extremely good tech support.
Looking up "Wolfgang Allinger LMI support" on groups.google.com
brought up the postings I was remembering, e.g.:
http://groups.google.com/groups?selm=6a3bFRnM7QB%40business.forth-ev.de
>Ray did not orphan his products when he went out of the Forth business. He
>released the still evolving Windows Forth as a PD; the other Forths were
>fully mature.
Did someone take up the maintenance? If not, they were orphaned, at
least by my definition of the word (although an orphan with source and
rights to change and redistribution has a chance of being adopted
(e.g., PFE).
>Some PD or political-License folks are very good at support also, but
>generally only while they are focused on the product, and as was posted
>earlier, often with uneven support depending (naturally) on the author's
>personal interest. The idea of *customer* support is non existent and
>irrelevant.
The idea of customer support depends also on the company's interest.
Or have you never heard that companies prioritized fixes and
extensions by the expected number of paying customers affected (with
priority given to (prospective) customers of whome the company still
expects to make money). As Bill Gates put it bluntly (paraphrased):
"[Some MS product] has no bugs that customers will pay for fixing".
Well, if you fit the model of the average future customer of the
marketing department (or whoever is in charge), fine, otherwise you
are out of luck (although maybe less likely out of luck than for some
other prioritizing schemes companies or developers may use).
OTOH, apart from pursuing personal interests in the development of new
features, I also use some crude statistics for estimating impact on
existing users (such as: "This system has behaved in this way for 5
years, and nobody complained about it, so it's apparently not a big
problem"), not some imagined future users.
[trailing quote deleted]
Please quote properly (see
http://www.complang.tuwien.ac.at/anton/mail-news-errors.html#quoting).
Tom Zimmer
Your view is a very valid one, and should I think be the one held by most
application developers. Why should a developer have to support the system they
are working on, when their time is better used writing and refining their
application. They shouldn't. Unfortunately there are valid reasons to both use
and write your own development system, or to use a public domain development
system. Developers sometimes can't get the tools they need to get the job done,
so they have to write their own. That represents the primary reason Win32Forth
was written in the first place. Win32Forth was written before there was a
viable Forth development system available for WindowsNT. There was one
development system available, but the sources were not available for its
internals, and it was not mature enough for our use. Win32Forth was written out
of a need to complete a project in a fixed amount of time. Win32Forth is public
domain because I didn't want to have my time wasted writing a development system
that I knew would one day be discarded and replace with a C++ application. It
was quicker to write a Forth system, and port the Forth application to it, than
it was to re-write it in C++. The company did complete the task of re-writing
it in C++, but it took an additional three years and 14 programmers. The Forth
team completed in six months the project of developing Win32Forth and ported the
existing application with a crew of five.
So, not only did we choose to use a public domain development system, we chose
to write one. In a similar situation, you might have done the same.
Just my thoughts,
Tom Zimmer
Glenn Dixon
medium one, and one huge one that includes fancy features--hardware
cards with DSPs, web-deployed control and status screens, distrubuted
web and and LAN EXEs, database, low-level sound card and Winsock
interfaces, etc. One GUI includes drag-and-drop icon-based flowchart
programming.
We use Swiftforth and have been very satisfied with it.
At one point we seriously tried to move the app to Visual Basic, and
again to Delphi, but found that after you dip below the visual
interface the underlying environment was more difficult to work with
than Forth.
This is because when you do a sophisticated Windows app, you spend
most of your time programming, not in the language you chose, but in
the language of the Windows API. It is a world of incomplete and
incorrect documentation, bugs in API calls, poor migration from
version to version, and a dozen different interfaces. Forth gives you
a window (pun?) into this world and allows you to play with API calls
like no other language. We spent A LOT of time doing this.
Hope this helps.
Glenn Dixon
"John Dunn" <john...@charter.net> wrote in message news:<u3rqunb...@corp.supernews.com>...
> Is anyone doing Windows applications in Forth anymore? Not embedded system
> work or CE work, but real, user interface intensive Windows apps? If so,
> which Forth?
>
> Both Forth, Inc. SwiftForth and MPE FVX look impressive, but the Windows
> interface is still daunting and not at all like the elegant simplicity that
> is Forth itself. iForth looks good too, especially the price and open
> license. But as far as I can tell, there is no Windows GUI interface at
> all.
>
> As a long time Forth programmer, who turned to the dark side some 3 years
> ago, to Visual Basic, and now (mostly because VB is about to become an
> orphan) taking another look at Forth for Windows...I would really appreciate
> any insight anyone here who is actually using Forth in a Windows app can
> share.
John Dunn
Your view is a very valid one also. I have no argument with anything you've
said, given the circumstances you've stated. However there are now no less
than 3 solid, commercial Forths for Windows, so happily application
developers have the option of selecting pro tools that you did not have at
the time.
That said, it cannot be denied that Win32Forth has been an enormous
contribution to the Forth community. I, like countless others, have found
it to be an invaluable resource. Thanks much for making it available!
John
Algorithmic Arts
http://algoart.com
"Tom Zimmer" <tzi...@thermofinnigan.com> wrote in message
news:3C4310CE...@thermofinnigan.com...
Wolfgang Allinger
On 14 Jan 02 at group /comp/lang/forth in article
<3C4310CE...@thermofinnigan.com>
<tzi...@thermofinnigan.com> (Tom Zimmer) wrote:
Hallo Tom,
[...developing Win32Forth...]
>The company did complete the task of re-writing it in C++, but it took
>an additional three years and 14 programmers.
Thats 14*3*12=504 MM (ManMonth)
>The Forth team completed in six months the project of developing
>Win32Forth and ported the existing application with a crew of five.
Thats 5*6=30 MM
What kind of management burns another 504 MM of time (=money), just to
have it in C++? How did they justify that to their headquarter?
Really incredible (no, not the 16.8 times better performance of the
forthers :-)
Bye from germany
Wolfgang
--
FORTHing @ work | *Cheap* ...pick any
Dipl.-Ing. Wolfgang Allinger | *Fast* *Good* ... *two* of them
Germany ------------------------------------
## KreuzPunkt XP2 R ## | reply address set
Elizabeth D. Rather
>
> >...
> >The company did complete the task of re-writing it in C++, but it took
> >an additional three years and 14 programmers.
>
> Thats 14*3*12=504 MM (ManMonth)
>
> >The Forth team completed in six months the project of developing
> >Win32Forth and ported the existing application with a crew of five.
>
> Thats 5*6=30 MM
>
> What kind of management burns another 504 MM of time (=money), just to
> have it in C++? How did they justify that to their headquarter?
>
> Really incredible (no, not the 16.8 times better performance of the
> forthers :-)
There are many such tales.
In about 1980 a customer of ours called Cybek wrote the first EFT system
for Citibank in Cybos, a multi-user database system based on polyFORTH.
It was very successful, and cost ~$1M. Citibank subsequently spent $5M
in a failed attempt to re-write it in COBOL.
In 1995 the Gas Company (So. Calif.) got a fixed-price bid of $30,000
from us to port a 6809 meter testing program in chipFORTH to a PC.
Instead, they hired a $30/hr C programmer to rewrite it from scratch in
C. In late 1999 they called us in a panic to see if we would fix Y2K
issues in the 6809 version, as the C version still wasn't working yet
(by that time they had several people working full-time on it).
And many more...
Of course, we can see that it's a disaster in hindsight. My guess is
that management is reasoning something like this:
1. All programming languages are about the same, and since it cost $X
to do it the first time, it should be about the same or less to do it in
another language.
2. Since Forth programmers are scarce and [C, COBOL, ...] programmers
are hanging around every street corner, it will be cheaper in the long
run if we do the conversion.
3. Yes, I know the project is a little behind schedule, but they're
almost done...
There are several fallacies here:
A. Forth is different. You can do some things easily in Forth that
it's very hard to do in other languages (especially COBOL!!). Forth has
probably allowed some design decisions to be implemented that are
nightmarish to reproduce without it.
B. Forth is easy to learn. If you take a programmer who is familiar
with the application domain, that person can learn Forth quickly, and
pick up the project easier than a person familiar with the language in
which the project is written but not the application domain. And the
greater productivity of a Forth programmer makes up for the learning
curve on the first project.
C. The captain of the Titanic probably didn't _really_ believe the ship
could sink until his feet got wet. It's very hard to admit you've made
a mistake, and the bigger the mistake gets the harder it becomes.
Unfortunately, we don't do a sufficiently good job of telling our
stories. We share them with each other, when it's the outside world
that needs them.
Example: Stephen Pelc and I hang out in comp.arch.embedded, for
example, putting in our $0.02 worth whenever an occasion arises, but the
regulars there know that we're vendors and discount everything we say.
Those of you who aren't selling anything but who have real-world
experience using Forth in embedded systems would be infinitely more
credible there telling your stories and offering your opinions. Any of
you who are bemoaning the unpopularity of Forth and wondering what you
can do about it may take the hint!
Cheers,
Elizabeth
John Dunn
news:2dd77556.02011...@posting.google.com...
> My son Tom and I have done several small Windows apps (with GUI), one
> medium one, and one huge one that includes fancy features--hardware
> cards with DSPs, web-deployed control and status screens, distrubuted
> web and and LAN EXEs, database, low-level sound card and Winsock
> interfaces, etc. One GUI includes drag-and-drop icon-based flowchart
> programming.
Do you have a web site, with screen shots of your software? I'd be
interested in how your flowchart looks.
> We use Swiftforth and have been very satisfied with it.
> At one point we seriously tried to move the app to Visual Basic, and
> again to Delphi, but found that after you dip below the visual
> interface the underlying environment was more difficult to work with
> than Forth.
Right.
> This is because when you do a sophisticated Windows app, you spend
> most of your time programming, not in the language you chose, but in
> the language of the Windows API. It is a world of incomplete and
> incorrect documentation, bugs in API calls, poor migration from
> version to version, and a dozen different interfaces. Forth gives you
> a window (pun?) into this world and allows you to play with API calls
> like no other language. We spent A LOT of time doing this.
Thanks for that insight. It is a bit intimidating having to deal directly
with with Win API now, but I expect you are right about being able to test
things on the fly. It's what Forth does so well.
> Hope this helps.
It does, thanks.
Jos v.d. Ven
"Tom Zimmer" <tzi...@thermofinnigan.com> wrote
news:3C4310CE...@thermofinnigan.com...
> Win32Forth was written out
> of a need to complete a project in a fixed amount of time. Win32Forth is
public
> domain because I didn't want to have my time wasted writing a development
system
> that I knew would one day be discarded and replace with a C++
application. It
> was quicker to write a Forth system, and port the Forth application to it,
than
> it was to re-write it in C++. The company did complete the task of
re-writing
> it in C++, but it took an additional three years and 14 programmers. The
Forth
> team completed in six months the project of developing Win32Forth and
ported the
> existing application with a crew of five.
Dear Tom,
Would you be so kind to tell us a bit more about this project ?
Jos
Jos v.d. Ven
"John Dunn" <john...@charter.net> wrote
news:u40foa...@corp.supernews.com...
>
> But for a commercial application, I would never use a Public Domain Forth.
> Not ever, no matter how impressive it is. Commercial apps go out to
> thousands, if not hundreds of thousands of users. They need the kind of
> support, robustness, and high performance that only a full time active
> commercial provider can provide.
I wrote 2 applications using Win32Forth which are not commercial atractive
for a third party.
The applications are still running stable and reliable for about 250 users
without any need to update them in a professional environment which change
quite often under windows.
This already exceeds the lifetime for some commercial applications.
Jos
Wannabe h4x0r
> Is anyone doing Windows applications in Forth anymore? Not embedded
> system work or CE work, but real, user interface intensive Windows apps?
> If so, which Forth?
>
> Both Forth, Inc. SwiftForth and MPE FVX look impressive, but the Windows
> interface is still daunting and not at all like the elegant simplicity
> that is Forth itself. iForth looks good too, especially the price and
> open license. But as far as I can tell, there is no Windows GUI
> interface at all.
>
> As a long time Forth programmer, who turned to the dark side some 3
> years ago, to Visual Basic, and now (mostly because VB is about to
> become an orphan) taking another look at Forth for Windows...I would
> really appreciate any insight anyone here who is actually using Forth in
> a Windows app can share.
>
> John Dunn
> Algorithmic Arts
> http://algoart.com
>
>
>
>
I've been doing some basic spreadsheet stuff in both Windows and XWindows
using a combination of Forth wrapped in Spark Ada95. I havent had to open
a debugger at all. You might wanna try this method. I've been using the
Ada.Interfaces "libraries" to create 1-to-1 correspondences between my
Forth code and the GUI written using GTKAda.
Mr. Caffiene
Bruce Gordon Rennie
Darin Johnson wrote:
>
....
>
> I seriously suspect that a program written in 6 months in one language
> being translated to any other language will involve at least 12 months
> effort. The large difference in style between typical Forth and
> Typical C or COBOL is going to compound that.
Depends on the new language being used - does it have the features required to
make it easy to do the application required. From my own experience, I was given
the task of writing a small billing program in Turbo-Pascal 3 (use the log files
produced from a dialup connection box into a Honeywell-BULL network to create
connection and usage billing records - not a overly hard task, other than the
moving target of changing format of the logfiles). The biggest problem with
maintenance of the system was the changing format of the logfiles which meant
changing various parts of the program. I looked around for a better solution to
this and came across the ICON programming language (Uni of Arizona - a
descendent of SNOBOL 4). In three days, I rewrote the system and lessened the
maintenance from that day forward. The three days included learning the new
language. Used the language there after for much of the adhoc programming
(predominately data analysis and data conversions) that I was required to do on
a daily basis for many years. In the workplace that I was in, SNOBOL 4 was used
quite regularly to manage and control the Datanet 8 configuration files as well
as analyse the various communication logs produced from the Datanet 8's.
To have suggested to those involved that the programming should be done in C or
COBOL or even in PASCAL would have caused great consternation (and probaly a
riot) amongst some of the networking staff of the time.
Yet, I have also seen system conversions that were supposed to take a couple of
months at most still in existance and not yet finished years later.
I seriousl;y suspect that no matter which side of the fence you sit on in this
matter that horror stories will come forth (ha ha) to support or dispute your
stand.
All of us have such varying experiences that all one can say is "This is what I
have seen".
regards
--
Bruce Rennie ( from God's Own Country Downunder )
Disciple of Jesus Christ in Training
The Cross of Jesus Christ - Salvation for all men.
Song of Solomon ( Song of Songs ) - The greatest Love Story Ever
and a story for our times.
Be a GOD Chaser.
Tom Zimmer
The port was from 20MHz DOS 386 to 120 MHz WindowsNT. We added GUI to make it
easier to use, and ported several complex algorithms from assembly to Forth.
The original program did data acquisition, data processing, data management and
library searching. We ported all but the acquisition portion to Forth. Andrew
McKewan wrote the acquisition portion in C using standard Visual C tools.
Overall, the program ran substantially slower in the new environment than it did
under DOS, but it had better customer acceptance, because the user interface was
much better (in my opinion of course). It was interesting to occasionally run
the old DOS version for a comparison test, and find that it would do most
operations instantaneously on 20MHz hardware, where we had to wait for the
100MHz hardware and OS to finish. To be fair though, this was a very
conservative port, done by people (including myself) that didn't know the
original application, so we had to be very careful to get equivalent operation
in a large body of code that we didn't understand. I know that probably sounds
strange, but this was a scientific application, and had encoded within it some
very special undocumented algorithms that had to be carried forward unchanged.
The C++ equivalent had to do all that we were doing, and at the same time, had
to be modularized to allow multiple kinds of instruments to be connected to the
same application, so they were trying to do much more than we on the Forth
project were.
Tom Zimmer
John A. Peters
XWindows
using a combination of Forth wrapped in Spark Ada95.
Please elaborate a bit on the resulting application and it's features.
What does "wrapped" mean
John Peters
Ian Yellowley
Anton Ertl wrote:
> In article <u45h5ih...@corp.supernews.com>,
> "John Dunn" <john...@charter.net> writes:
>
>>I used LMI Forth from the z80 days all the way through 386 Protected Mode.
>>I also taught Forth to art and music students at the University of Michigan
>>using LMI Forth. Always, Ray Duncan gave extremely good tech support.
>>
>
> Looking up "Wolfgang Allinger LMI support" on groups.google.com
> brought up the postings I was remembering, e.g.:
> http://groups.google.com/groups?selm=6a3bFRnM7QB%40business.forth-ev.de
>
>
>
SNIP
I remember Wolfgang's post and being surprised at his comments. We used
the LMI Metacompiler, URForth in 16 and 32 bit versions as well as
WinForth. Yes we had one problem...it was fixed in a business like
manner. I think it unfortunate to rewrite one message from several years
ago...I am sure that there are lots of people who have fired up PD
Forths and given up very quickly. LMI documentation was complete and the
product very capable...in our experience. We use both PD and commercial
FORTH's, I have a preference for commercial products where we actually
ship code to others who will also need support...please this is a
preference not an invitation for war,
regards
Ian
Andrey Cherezov
> work or CE work, but real, user interface intensive Windows apps? If so,
> which Forth?
Look at Eserv (http://www.etype.net/, http://www.eserv.ru/)
it is server suite, but with the GUI interface (for server admins).
It is written in SP-Forth (http://spf.sourceforge.net/)
Best regards,
--
Andrey Cherezov
http://www.forth.org.ru/
Wannabe h4x0r
Basically I handle all I/O through my Ada Libs. The Ada libraries capture
the input and then instantiate a "task" which uses the Forth code for
performing the calculations. It's super-fast. Of course I'm creating
object files from the Forth code to link into the Ada runtime rather than
running them through an interpreter.
The one to one correspondence is achieved by using Ada's strong typing
mechanisms and boolean flags to insure that the Input is restricted to
exactly what my Fort routines are expecting.
It's very experimental right now.(I'm a student, not an engineer, yet.)
But the results look promising. I'll post up some code once it's
actually usable.
Mr. Caffiene
ch...@dont.spam.me
Michael Coughlin
> Unfortunately, we don't do a sufficiently good job of
> telling our stories. We share them with each other, when
> it's the outside world that needs them.
> Example: Stephen Pelc and I hang out in comp.arch.embedded,
> for example, putting in our $0.02 worth whenever an occasion
> arises, but the regulars there know that we're vendors and
> discount everything we say.
> Those of you who aren't selling anything but who have
> real-world experience using Forth in embedded systems would
> be infinitely more credible there telling your stories and
> offering your opinions. Any of you who are bemoaning the
> unpopularity of Forth and wondering what you can do about
> it may take the hint!
Well, yes, Forth programmers only preach to the converted. I
try to preach the virtues of Forth to people who should use it
but don't. Sometimes I can get their attention, especially if
they don't know what programming is but want to find out. It
used to be that I could advise them to go to their local book
store or library and get "Starting Forth". I can't do that
anymore.
When I talk to people who know a little about programming, I
have another problem. If Forth is as good as I claim, why
haven't they heard about it and why haven't they ever used a
program written in Forth? A decade or two ago, I would meet
people who did have a slight knowledge of Forth and knew the
source code was unreadable, even by the person who wrote it.
Younger programmers are much more numerous than those
old-timers, so that problem is not as serious today.
If a clever Forth programmer tells his story on
comp.arch.embedded, it woun't do any good. Everybody knows there
are some programmers who can work miracles by having amazing
memories and knowing thousands of sneaky tricks. What can Forth
do for ordinary programmers?
Java merchants had the right idea. I didn't even know Java
was a computer language when I first heard about it. I heard
about Hot Java, the web browser. Months later I learned about
the Java language, the Java virtual machine, and so on. Since I
only use computers that are old and obsolete, I didn't see Hot
Java for several years. When I did see it, I was astonished.
Grass grows faster than Hot Java runs. Its only practical use is
to download a copy of Netscape. But Hot Java served its purpose.
It showed the world the Java language could be used to write
applications. I have been waiting twenty years to see a Forth
program that would would do for Forth what Hot Java did for
Java. Where is it? But I'm even harder to please. This demo
program should be published as a source listing that is easy to
understand. Can such a program be written? If it can't, why are
we bothering with Forth?
--
Michael Coughlin m-cou...@ne.mediaone.net Cambridge, MA USA
Marcel Hendrix
[..]
> When I did see it, I was astonished.
> Grass grows faster than Hot Java runs. Its only practical use is
> to download a copy of Netscape.
> But I'm even harder to please. This demo
> program should be published as a source listing that is easy to
> understand. Can such a program be written? If it can't, why are
> we bothering with Forth?
The problem, and I'm only half-joking, is that Forth programmers
are not interested in downloading Netscape.
-marcel
Gary Chanson
"Marcel Hendrix" <m...@iae.nl> wrote in message
news:3c47d740$0$225$4d4e...@read-nat.news.nl.uu.net...
>
> The problem, and I'm only half-joking, is that Forth programmers
> are not interested in downloading Netscape.
Of course not! At least not until there's an ARM version of it. ];)
--
-GJC
-gcha...@shore.net
-War is the last resort of the incompetent.
John Dunn
> people who did have a slight knowledge of Forth and knew the
> source code was unreadable, even by the person who wrote it.
All computer languages are unreadable by humans who don't know the
language. So are natural languages. That's irrelevant. What is
relevant is can other Forth programmers read Forth source? Which is
entirely dependent on how well (readable) the author made it. It's no
different than other languages, except Forth allows the flexibility to
really obscure things if the programmer is unskilled or lazy or just
doesn't care. You've heard it before: Forth is an amplifier.
> Younger programmers are much more numerous than those
> old-timers, so that problem is not as serious today.
>
> If a clever Forth programmer tells his story on
> comp.arch.embedded, it woun't do any good. Everybody knows there
> are some programmers who can work miracles by having amazing
> memories and knowing thousands of sneaky tricks. What can Forth
> do for ordinary programmers?
Here is how old-timer programmers who, alas, no longer have amazing
memorys write readable code (in addition, of course, to all the things
we've always done - consistant block struture, short words, long
comments, etc.):
LONG-WORD-NAMES.
John Dunn
Algorithmic Arts
http://algoart.com
"Michael Coughlin" <m-cou...@ne.mediaone.net> wrote in message
news:3C47A827...@ne.mediaone.net...
Elizabeth D. Rather
>
> Michael Coughlin <m-cou...@ne.mediaone.net> writes:
>
> > Well, yes, Forth programmers only preach to the converted. I
> > try to preach the virtues of Forth to people who should use it
> > but don't.
>
"Preaching" isn't what's needed. But the folks on comp.arch.embedded,
the example I originally gave, frequently describe their experiences
with projects, exchange tips on how to do things, etc., and it
would be helpful to have Forth approaches represented, especially
since embedded systems is an area where Forth has been most
successful.
> > If a clever Forth programmer tells his story on
> > comp.arch.embedded, it woun't do any good. Everybody knows there
> > are some programmers who can work miracles by having amazing
> > memories and knowing thousands of sneaky tricks. What can Forth
> > do for ordinary programmers?
>
> That's a big problem. You just don't run across many Forthers of the
> "I'm not all that smart, but with Forth I can do wonders" type.
I think most of us feel that way!
> > Can such a program be written? If it can't, why are
> > we bothering with Forth?
Isn't it a little facetious to say that if Forth isn't visible
in one particular niche is isn't worth bothering with? Forth was
originally designed for embedded systems. It's been successfully
used elsewhere as well. Sun spent millions of $$ promoting Java
even before it had been used for anything useful. We don't have
millions of $$ to spend, but we do have some real-world experience.
We should share it outside this narrow community.
Peter Lawrence
.
.
.
> Isn't it a little facetious to say that if Forth isn't visible
> in one particular niche is isn't worth bothering with? Forth was
> originally designed for embedded systems.
What are people's working definitions of "embedded system"? On the one hand
the last poster was there, so she ought to know whather Forth was originally
designed for them or not. On the other hand, by my own working definition
that's an impossibility as there weren't any then, except maybe in military
use (which wasn't what gave the world Forth).
To me, an embedded system is a bit like what somebody said about a good
digestion: if you've got one, you don't know it's there. So a system that is
visible enough to the people who are its users that they have to remain aware
of, confronted with, the fact that there's a computer doing all the work -
isn't embedded. If you can't ignore the computer, it isn't embedded. I'm not
talking about people who go out of their way to look at it, who want to know
about it; "ars est celare artem" applies to the punters' experience, not the
artist's trade itself.
What other definitions work better? That's a genuine question. PML.
--
GST+NPT=JOBS
I.e., a Goods and Services Tax (or almost any other broad based production
tax), with a Negative Payroll Tax, promotes employment.
See http://users.netlink.com.au/~peterl/publicns.html#AFRLET2 and the other
items on that page for some reasons why.
Klaus Seegebarth
<era...@forth.com> wrote:
[snip...snip]
>"Preaching" isn't what's needed. But the folks on comp.arch.embedded,
>the example I originally gave, frequently describe their experiences
>with projects, exchange tips on how to do things, etc., and it
>would be helpful to have Forth approaches represented, especially
>since embedded systems is an area where Forth has been most
>successful.
From my point of view, it is not enough to have some success stories.
I am one of these people, who are using Forth in embedded systems
successfully and i am also reading c.a.e, but until now i would not
recommend Forth neither there nor in other places.
My experience with Forth systems is simple: they just fit one purpose
only (the needs of its creator), and if someone before you already had
the same needs, you probably get happy. If not, better forget Forth or
do-it-yourself.
I bought a commercial Forth (cross compiler for 166 family) several
years ago. Because there was only one major Forth supplier with a
german representive, i bought theirs.
It was impossible to use sequential files and to print out was only
possible on HP Laserjet printers. Nice for Forth-junkies, but not for
me (my printer was a LA100 attached to VAX via network).
It is still unused and you can have it for a bottle of good wine.
Two years ago i looked around once more for a commercial Forth system.
My former supplier was no longer alive, maybe i know why. The
competitors regularly crashed my computer, when i visited their
website. A german representive is not available. My conclusion: they
only serve local customers, who always buy the newest Windows stuff
and i am not on their customer radar.
So i get the impression, that Forth suppliers are interested only in a
very small part of the business. Why should i recommend them ?
Yes, yes, i know. This is not very essential for a real Forth
programmer and it is not essential for the real work, because you can
overcome this situation with some additional effort. But you do this
additional effort only, if you are already convinced!!!
Why choose a complicated solution when you can have a simple one ???
Best regards
Klaus
PS:
Desparately hoping someone can demonstrate me, that i am totally
wrong, because i am still interested in a commercial Forth cross
compiler.
Needs to run in plain DOS.
Needs to create assembler output, which i can link to C-programs.
Needs to support several popular uCs.
Needs to support sequential files, which i can print everywhere.
Needs to support a minimal Forth inside the target via serial link
Andreas Klimas
>
> On Fri, 18 Jan 2002 18:35:42 GMT, "Elizabeth D. Rather"
> <era...@forth.com> wrote:
>
> [snip...snip]
> >"Preaching" isn't what's needed. But the folks on comp.arch.embedded,
> >the example I originally gave, frequently describe their experiences
> >with projects, exchange tips on how to do things, etc., and it
> >would be helpful to have Forth approaches represented, especially
> >since embedded systems is an area where Forth has been most
> >successful.
>
> From my point of view, it is not enough to have some success stories.
> I am one of these people, who are using Forth in embedded systems
> successfully and i am also reading c.a.e, but until now i would not
> recommend Forth neither there nor in other places.
what else ?
I think Forth has a maximum on power with a minimum of effort.
the only problem is that one has to understand the problem
and to think about a well fitted solution. this is what many
coworkes of me simply don't. I call this brute force developers.
Smalltalk guides one to well OO programs, Forth guides one
to thoughtful written programs.
>
> My experience with Forth systems is simple: they just fit one purpose
> only (the needs of its creator), and if someone before you already had
> the same needs, you probably get happy. If not, better forget Forth or
> do-it-yourself.
forget Forth and use what ?
may be Java, and then ?
today there are so many languages, and they come and go. Smalltalk
IDE's are rare today and mostly expensive. if a vendor dies, one
is out of luck because it's not possible to support it yourself,
or it's too complex. this is not only true for comercial products,
this is true for every large system.
>
> I bought a commercial Forth (cross compiler for 166 family) several
> years ago. Because there was only one major Forth supplier with a
> german representive, i bought theirs.
hopefully you got the complete source.
> Yes, yes, i know. This is not very essential for a real Forth
> programmer and it is not essential for the real work, because you can
> overcome this situation with some additional effort. But you do this
> additional effort only, if you are already convinced!!!
> Why choose a complicated solution when you can have a simple one ???
one only can decide between solutions in which one is familiar with.
if one only knows COBOL and Pascal why one should select C++ for
his solution ?
>
> PS:
> Desparately hoping someone can demonstrate me, that i am totally
> wrong, because i am still interested in a commercial Forth cross
> compiler.
> Needs to run in plain DOS.
> Needs to create assembler output, which i can link to C-programs.
> Needs to support several popular uCs.
> Needs to support sequential files, which i can print everywhere.
> Needs to support a minimal Forth inside the target via serial link
hopefully these are not real requirements. at least not all together
in same time. probably there are some different targets, at least
one with an underlying file system (your sequential files requirement).
which Forth architecture is required (DTC, ITC, STC, number of bits ?)
may be DTC is better for one target then STC. this depends on your
(different) targets.
so I think _one_ solution for all these requirements didn't make
sense (at least to me). I would take a small Forth system (polyForth,
pygmy, ... ?) which is quite simple to understand and then implement
my own stuff. Forth development is very fast, might it's faster then
searching for existing solutions :-)
Andreas
Jeff Fox
> What are people's working definitions of "embedded system"?
I think a dictionary definition of embed as "to make something
an integral part of" is quite sufficient. With regard to
computers it is simply meant to distinguish between systems
designed to provide a human/machine interface for general
purpose computing, or that are specialized to perform a
single specific task.
A good common sense rule of thumb with regard to embedded
computing is the number of programs that the computer runs,
if it only ever runs one program it is an embedded application.
> On the other hand, by my own working definition
> that's an impossibility as there weren't any then,
It sounds like you have equated micro with embedded.
But PCs use micros and yet are more or less general
purpose computes. People did build special purpose
computers, dedicated to a single application before
micros were invented.
Forth was invented before the microprocessor and
microcontroller. People can embed large computing
systems or small ones, the defintion is not about
size, but rather functionality.
> To me, an embedded system is a bit like what somebody said
> about a good digestion: if you've got one, you don't know
> it's there.
That's just a defintion of ignorance. I know that my
washing machine has an embedded processor, does that make
it into a PC? I am not unaware of the fact that this mouse
has an embedded processor in it. Does that disqualify it
as an embedded computer?
My VCR has a embedded processor in it, it is obvious that
it does, I can even program it. Yet most people define that
as an embedded processor application, all it can ever do
is run one program that controls the equipment that it
is embedded in.
Most people just turn on a PC and do email or surf the web.
They use their PC like an internet appliance with an embedded
application and may never run other programs or program the
computer themselves. Does their behavior and ignorance
mean that their PC is an embedded computer?
To many users it is clearly not an embedded systems, but
some users may see it and use it that way. On the other
hand, no one is going to run Windows or Linux or GCC on my
washing machine. Maybe the next model will give you the
option to run Word along with the spin cycle.
> So a system that is
> visible enough to the people who are its users that
> they have to remain aware of, confronted with, the fact
> that there's a computer doing all the work -
> isn't embedded.
That touches on the "user illusion" issue. Ignorant
users have no idea, so what? They can also easily
confuse a computer for a human being and be totally
unaware of the fact that a silicon computer, not a
carbon based unit is doing all the work. I don't
think that can be used as a definition of embedded/not.
> If you can't ignore the computer, it isn't embedded.
My car has no embedded computers (yet) unless one defines
a relay as an embedded computer. Now again it is a matter
of degree, with enough relays it could become what we call
a computer.
But most cars have lots of embedded computers, and you
can't drive the car without interacting with them. They
provide a car/human interface, not a human/general-purpose-
computing-interface (in most cases) so driving a car means
looking at the embedded computers.
Of course the designers, programmers, installers, testers,
and drivers have to look at them in various ways. To the
end user, they are embedded in the functionality of the
car, as an intergral component rather than being used
as general purpose, or multi-purpose, computing machines.
> What other definitions work better? That's a genuine question. PML.
It is a tricky question. Embedded computers are often visible.
Embedded computers often have a visible user interface, my
VCR remote does, it has buttons and a visible LED to communicate
to me, my washing machine does, it has dials and buttons, I
can certainly even "program" my microwave oven or VCR.
I think the only useful defintion is "made an integral part of"
but also to me it implies dedicated function rather than run
any old program like a general purpose computer.
It certainly cannot be based on size. It cannot be based on
a user interface. It cannot be based on a user's ignorance
of computing or inability to recognize another intelligent
machine in the first place.
Elizabeth D. Rather
> Peter Lawrence wrote:
> > What are people's working definitions of "embedded system"?
>
> I think a dictionary definition of embed as "to make something
> an integral part of" is quite sufficient. With regard to
> computers it is simply meant to distinguish between systems
> designed to provide a human/machine interface for general
> purpose computing, or that are specialized to perform a
> single specific task.
>
> A good common sense rule of thumb with regard to embedded
> computing is the number of programs that the computer runs,
> if it only ever runs one program it is an embedded application.
> >...
> > What other definitions work better? That's a genuine question. PML.
>
> It is a tricky question. Embedded computers are often visible.
> Embedded computers often have a visible user interface, my
> VCR remote does, it has buttons and a visible LED to communicate
> to me, my washing machine does, it has dials and buttons, I
> can certainly even "program" my microwave oven or VCR.
>
> I think the only useful defintion is "made an integral part of"
> but also to me it implies dedicated function rather than run
> any old program like a general purpose computer.
>
> It certainly cannot be based on size. It cannot be based on
> a user interface. It cannot be based on a user's ignorance
> of computing or inability to recognize another intelligent
> machine in the first place.
It was 1971. The computers for which the first standalone
Forth that we'd all recognize was developed were used to do
data acquisition and control for the 36' (11M) radio telescope
belonging to NRAO on Kitt Peak Mtn, Arizona. They had
16K and 24K bytes memory, respectively. They were
dedicated to their respective functions, and certainly couldn't
have been used for "general purpose computing" (only
mainframes could do that then).
The Nobel Prize winning discovery of large molecules in
interstellar space was made on this system, by Penzias
& Wilson of Bell Labs.
The issues that Chuck and I confronted mainly revolved
around making maximum use of limited resources (memory
and time, since the applications were real-time and timing
accuracy was essential). But we were also working in
a research environment, where new equipment and
analysis algorithms came along regularly, so the software
had to be flexible and easy to change. Finally, observing
time was precious, so the system had to be extremely
reliable.
Forth was designed to meet these needs, and has done
so successfully through all its evolution ever since. These
are still major issues in today's embedded systems.
Cheers,
Elizabeth
Peter Lawrence
>
> Peter Lawrence <pet...@netlink.com.au> writes:
>
> > To me, an embedded system is a bit like what somebody said about a good
> > digestion: if you've got one, you don't know it's there. So a system that is
> > visible enough to the people who are its users that they have to remain aware
> > of, confronted with, the fact that there's a computer doing all the work -
> > isn't embedded.
>
> ultrasound, ethernet routers, ATM's, and Lego Mindstorms.
How so? I thought I was making exactly that sort of distinction. The people
who have to maintain ATMs remain aware of their computer basis, the customers
who use them may or may not be aware of it from their own levels of computer
literacy - but nobody needs to bear computer issues in mind to use them, and
quite a few younger people just take them for granted. PML.
Peter Lawrence
>
> Jeff Fox wrote:
>
> > Peter Lawrence wrote:
.
.
> It was 1971. The computers for which the first standalone
> Forth that we'd all recognize was developed were used to do
> data acquisition and control for the 36' (11M) radio telescope
> belonging to NRAO on Kitt Peak Mtn, Arizona. They had
> 16K and 24K bytes memory, respectively. They were
> dedicated to their respective functions, and certainly couldn't
> have been used for "general purpose computing" (only
> mainframes could do that then).
What they did have, what made their computer aspect so in-your-face, was like
the things that made early motorcars so obviously internal combustion engine
devices. They confronted people with maintenance needs that meant they needed
an insight into circuitry, with backup needs that required an insight into
version control issues, etc. There was a considerable overlap with what
computers had, so nobody could detach from that. I'd guess that pre-Forth the
ways of coding them left the users very confronted with the realities of
batch-oriented crashes and dumps, too.
I'm not saying that the users applied all the computer expertise, only that
they needed a first aider's knowledge of what to do and when to get an expert
in.
.
.
.
Finally, observing
> time was precious, so the system had to be extremely
> reliable.
>
> Forth was designed to meet these needs, and has done
> so successfully through all its evolution ever since. These
> are still major issues in today's embedded systems.
I'd certainly agree that those systems had needs of their own, not present in
other systems of the day but that still turn up in today's embedded systems.
I just don't see that they had yet turned into embedded systems, except maybe
the ones that were found in military avionics etc. PML.
Dave Bennett
If your programming language has become a religion rather than a choice,
you're in the wrong business. Programming has nothing to do with languages,
per se. Programming is understanding the principles and mechanics of how to
control a computing device, regardless of the processor type or language
available to achieve the task. Someone who says to me "I'm a VisualBasic
programmer" is not a programmer, but a person who knows how to operate a
program called "VisualBasic" to achieve some control over a predefined
computing device in a predefined context. Someone who says "I'm a
forth" programmer to the exclusion of all other possibilities in all
situations is likewise limited.
I've programmed in several languages over the years, not because I "wanted"
to change languages all the time, but because sometimes learning a new
language was necessary to generate the best product for the defined task at
hand. In the 20 years I worked professionally in the IS field (the last 5
as a CIO), I would say that the most prevalent task I saw programmers
undertake was to explain why the "defined task" had to be further redefined
so they could use only tools they were already familiar with. (It seems
that for most people the belief is that learning things stops once you get
the diploma.)
I had heard of forth for years, but never had occasion to use it until late
1998. I write recreationally these days for the Palm OS, using Quartus
forth. I initially wrote some apps using gcc and cross-compiled from a
Linux box. However, the "best" tool turned out to be forth. I have the
complete development environment on my Palm and it allows me to work the
way the Palm itself was designed to be used- anywhere.
Instead of "preaching the word" of forth, it would be better to educate
those learning programming (and those managing them) that different tools
work best in different places and to not place penalties on
programmers on-staff who would mention using a different tool or language
to achieve the best result for a defined task. I have hired programmers who
were fired from their previous employment merely for suggesting using a
different tool than the one "everyone already knows". I've had their
managers tell me that "he wanted to use something 'no one' had heard of".
When schools offer course like "java programming" because companies say
that is the checkbox they want to see filled on a resume app, you have to
think that the education business has already compromised itself and
performed a great disservice to those it is teaching as well as those who
depend on the quality of person being turned out by schools.
This is not a new problem, but the endless discussions I've seen like this
over the years about <insert your favorite language here depending on the
buzzword of the year you are thinking of> do little to help. I don't think
there is a solution, this is just the way things are, and unfortunately,
most likely will continue to be until the goal is to produce the best
application from the user's perspective instead of filling development
department full of same-minded clones.
As someone said in this thread, if you're happy with the tool and it's use,
then the language has reached some small degree of success in you.
--
--
Dave
Bernd Paysan
> When schools offer course like "java programming" because companies say
> that is the checkbox they want to see filled on a resume app, you have to
> think that the education business has already compromised itself and
> performed a great disservice to those it is teaching as well as those who
> depend on the quality of person being turned out by schools.
Unfortunately, that's the way most of the business work. Your ignorant
manager who fires people who suggest using tools he (and his ignorant
subordinates hired from Dogbert's cadaver program) doesn't know, is very
typical. These people think that ignorance is a virtue, but I think it
is a shame.
A lot of people indeed think that using a particular language is
necessary. A coworker told me a story about an EDA CAD supplier. This
company used a programming language they made themselves, and they had
problems finding people who are willing to work for them. One of his
friends had an interview, but refused to work there, because if he would
leave after some years, all he could write in his resume was "programmed
in obscure language nobody knows". This is so silly that I couldn't even
laugh. He could have written into his resume "wrote part of widely known
EDA CAD suite".
The company finally tried to convert the program into C, with an huge
effort (after all, they *could* hire C programmers). They failed. The
company afterwards was bought by one of the big sharks in the EDA CAD
business. My coworker recently got an error message out of one of their
programs, which indicated that the inner workings are still written in
that "obscure" language. That's why he told me this story.
For a professional programmer, it should not take long to learn
programming in any language. A language is a tool, and no artisan would
come to you and say "I'm a hammer user" or "I'm a screwdriver user",
though different artisans have obvious preference in tools. Different
programming languages have their places, and the obscure language
mentioned above obviously was right for the job.
Forth however, is mostly a meta-language, one to make tools, not really
a tool itself (although you should use the tools that are already there
to accomplish the task). It's more like a smithy than a hammer,
screwdriver or swiss army knive. You have a board on the wall with Leo
Brodie's simple tools for easy tasks, and you have forge, hammer, and
anvil to make your own simple tools if you need them.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Gary Chanson
"Bernd Paysan" <bernd....@gmx.de> wrote in message
news:3C4B429D...@gmx.de...
>
> A lot of people indeed think that using a particular language is
> necessary. A coworker told me a story about an EDA CAD supplier. This
> company used a programming language they made themselves, and they had
> problems finding people who are willing to work for them. One of his
> friends had an interview, but refused to work there, because if he would
> leave after some years, all he could write in his resume was "programmed
> in obscure language nobody knows". This is so silly that I couldn't even
> laugh. He could have written into his resume "wrote part of widely known
> EDA CAD suite".
>
> The company finally tried to convert the program into C, with an huge
> effort (after all, they *could* hire C programmers). They failed. The
> company afterwards was bought by one of the big sharks in the EDA CAD
> business. My coworker recently got an error message out of one of their
> programs, which indicated that the inner workings are still written in
> that "obscure" language. That's why he told me this story.
>
> For a professional programmer, it should not take long to learn
> programming in any language. A language is a tool, and no artisan would
> come to you and say "I'm a hammer user" or "I'm a screwdriver user",
> though different artisans have obvious preference in tools. Different
> programming languages have their places, and the obscure language
> mentioned above obviously was right for the job.
I wouldn't jump to that conclusion. So far, I am yet to see ANY
significant program ported from any language to any other significantly
different language without signifcant hardship and significantly larger cost
then the original implementation. The operative work here is
"significantly". If one of the above languages if Forth, you can be sure
that there will be significant differences.
> Forth however, is mostly a meta-language, one to make tools, not really
> a tool itself (although you should use the tools that are already there
> to accomplish the task). It's more like a smithy than a hammer,
> screwdriver or swiss army knive. You have a board on the wall with Leo
> Brodie's simple tools for easy tasks, and you have forge, hammer, and
> anvil to make your own simple tools if you need them.
I like to equate Forth to a machinist's tool chest. You can be sure to
find home made tools in either!
Elizabeth D. Rather
> Elizabeth D. Rather wrote:
> >...
> > Forth was designed to meet these needs, and has done
> > so successfully through all its evolution ever since. These
> > are still major issues in today's embedded systems.
>
> I'd certainly agree that those systems had needs of their own, not present in
> other systems of the day but that still turn up in today's embedded systems.
> I just don't see that they had yet turned into embedded systems, except maybe
> the ones that were found in military avionics etc. PML.
Ok, I'm not sure splitting hairs over this is so important, the original topic
had to
do with comp.arch.embedded, and their definition of "embedded systems" is
pretty broad, generally encompassing not only things that don't immediately
look like computers but also computer-controlled widgets and other dedicated
apps.
Cheers,
Elizabeth
Jeff Fox
> the original topic had to do with comp.arch.embedded, and
Yes, it was brutal, for mentioning Forth you were asked
whether you were just a lying vendor or just promoting
Forth as a religion. Then it was said that you summoned
the Forth hords! Shame on you! ;-)
I gave up on comp.arch.embedded a few years ago because
most experts there were so clueless. The majority wanted
to embed their old surplus DOS based PCs so that they could
use the totally inappropriate for embedded processing desktop
software that they always used on the desktop. Today they want
to embed their old surplus PCs so they can run Windows or Linux
based "embedded" apps where the term seems to mean surplus
junk.
But all in all I think c.a.e has improved greatly over
the years, with one exception, there are more Forth
haters there than ever. They do pretty well as long
as you don't mention Forth. I think while c.a.e has
improved c.l.f has gone the other way and are about at
the same marginal level today.
But I also used to read comp.realtime and I had to give
up on those people as totally clueless. For one thing
the comp.realtime faq clearly states that the definition
of realtime requires pre-emptive multitasking and thus
the cooperative multitasking schemes used in most Forths
need not apply, they don't qualify as realtime. Even
if the Forth approach lets one respond faster in real-time
and meet tighter real-time requirements, it simply is
not real-time programming according to comp.realtime.
I gave up on them a few years ago when the majority
opinion was that a 100Mhz Pentium was incapable of
more than 2000 empty loops per second. They had plenty
of "proof" of that, their own code! And of course no one
there could believe the simple facts about how fast
we change tasks or how little code it all takes.
> their definition of "embedded systems" is pretty broad,
As it should be. There are billions of embedded systems
built every year. They are not all the same. They cover
a much wider range than PCs.
> generally encompassing not only things that don't immediately
> look like computers but also computer-controlled widgets and
> other dedicated apps.
That makes me wonder, what does a computer look like?
ri...@cougar.no.domain
> But I also used to read comp.realtime and I had to give
> up on those people as totally clueless. For one thing
> the comp.realtime faq clearly states that the definition
> of realtime requires pre-emptive multitasking and thus
> the cooperative multitasking schemes used in most Forths
> need not apply, they don't qualify as realtime.
One particularly weird thing I've played with is putting a yield() in
Next. This made a cooperative multitasking scheme appear pre-emptive
to Forth.
I seem to have many more bad ideas than good ones...
> I gave up on them a few years ago when the majority
> opinion was that a 100Mhz Pentium was incapable of
> more than 2000 empty loops per second. They had plenty
> of "proof" of that, their own code!
Strange. The rule of thumb I used for performance estimation on
a 25MHz MIPS box many years ago was one million lines of C per second.
I was handling 75,000 interrupts per second on that machine, under
Unix. It wasn't doing much else, but it was handling the interrupts.
--
Roger Ivie
iv...@cc.usu.edu
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Jeff Fox
> One particularly weird thing I've played with is putting a yield() in
> Next. This made a cooperative multitasking scheme appear pre-emptive
> to Forth.
Perhaps we should just call our cooperative multitasking
pre-emptive/cooperative multitasking. If one mucks around
with the task ring with some priority mechanism or
multiple occurances of one task in the ring I do
think that does qualify as pre-emptive, but perhaps
people also assume that it must be timer and interrupt
driven to be pre-emptive. Of course in almost all cases
Forth will be rejected anyway unless it is just a thin
layer written in C for scripting purposes because of
integration issues.
> > I gave up on them a few years ago when the majority
> > opinion was that a 100Mhz Pentium was incapable of
> > more than 2000 empty loops per second. They had plenty
> > of "proof" of that, their own code!
>
> Strange. The rule of thumb I used for performance estimation on
> a 25MHz MIPS box many years ago was one million lines of C per second.
> I was handling 75,000 interrupts per second on that machine, under
> Unix. It wasn't doing much else, but it was handling the interrupts.
You mean that you were not using visual basic for realtime? ;-)
Yes, it is strange when people use the limits of their own software
as proof of the ultimate limits of hardware. There were people
who argued that Windows is a realtime enviroment because it can
respond to events in realtime and with a maximum latency of only
about 20 seconds. And they had proof! You must be wrong! ;-)
(It _was_ 20 seconds on my 120Mhz Pentium Win95 and is still
20 seconds on my 400Mhz Pentium II NT system. Maybe it is
better on a 2GHz Pentium IV with XP, maybe it is only
5 or 10 seconds, but I wonder. ;-) I recently had to
change the format on my CD when I learned that they worked
in 95,98, and NT, but not in 2K or XP. Oh well, at least
I found it before some user who had upgraded to a more broken
version of the MS software than I was using.
I was told by one of the top Unix and C experts that I know
recently that about 30K interrupts per second was about all
that one could count on with todays very deep pipelines
and caching issues. Phil Koopman wrote a very good paper
on that years ago where he said that the problem is that
the architecture is so non-deterministic that what kills
you are the occasional interrupts that have 100 times
greater access times than the average. It may be worse
today, that was on 386.
If you don't have a hard requirement you can get interrupts
that have a very short average time. The problem is with hard
timing requirements where you have to multiply the average
by 100 to be relatively safe. The most I have done is about
10M per second but it was not on a PC and was deterinistic.
Finding those events that only occur once every
ten billion times is a tricky problem. Finding
a subtile hardware problem that only occurs that
often is even a trickier problem.
When we work out a design for sub-nanosecond interrupt
processing it must just look crazy to PC types working
happily many orders of magnitude down on the scale of
speed and orders of magnitude up on the scales of
cost and power consumption. This sort of thing seems
to contribute to the unpopularity of Forth.
IMHO the main problem with Forth's unpopularity is
that it is too good at what it does. People resent
that and thus most sound-bytes in circulation repeat
and exagerate the most absurd things about Forth. I
think this is true for the people using Forth as much
as those who don't. There are certainly more negative
sound-bytes about Forth in c.l.f than anywhere else.
Michael Coughlin
Elizabeth D. Rather wrote:
> It was 1971. The computers for which the first standalone
> Forth that we'd all recognize was developed were used to do
> data acquisition and control for the 36' (11M) radio
> telescope belonging to NRAO on Kitt Peak Mtn, Arizona.
> They had 16K and 24K bytes memory, respectively. They
> were dedicated to their respective functions, and certainly
> couldn't have been used for "general purpose computing"
> (only mainframes could do that then).
> The Nobel Prize winning discovery of large molecules in
> interstellar space was made on this system, by Penzias
> & Wilson of Bell Labs.
OH HORRORS! False doctrine. Penzias & Wilson of Bell Labs
did not discover large molecules in interstellar space. Actually
nobody has ever discovered large molecules in interstellar
space, just small ones. Penzias & Wilson discovered cold black
body radiation (2.7 Kelvin) in outer space. Did they really use
Forth? I never heard that before.
> The issues that Chuck and I confronted mainly revolved
> around making maximum use of limited resources (memory
> and time, since the applications were real-time and timing
> accuracy was essential). But we were also working in
> a research environment, where new equipment and
> analysis algorithms came along regularly, so the software
> had to be flexible and easy to change. Finally, observing
> time was precious, so the system had to be extremely
> reliable.
>
> Forth was designed to meet these needs, and has done
> so successfully through all its evolution ever since. These
> are still major issues in today's embedded systems.
Everyone should save the above message. There will be exam
questions about it on comp.lang.forth in the future. Just be
sure to remove the part about Penzias & Wilson.
Jeff Fox
>
> (boo, hiss, to people who don't change the subject line)
or who create misleading subject lines. According to
Chuck's web page he had been doing Forth for some time
before Forth Inc. was started. The first published
paper went back to 1968 but applications existed
before that. Elizabeth said "the first application
that we'd all recognize" not the "first application."
> > The Nobel Prize winning discovery of large molecules in
> > interstellar space was made on this system, by Penzias
> > & Wilson of Bell Labs.
>
> OH HORRORS! False doctrine. Penzias & Wilson of Bell Labs
> did not discover large molecules in interstellar space. Actually
> nobody has ever discovered large molecules in interstellar
> space, just small ones. Penzias & Wilson discovered cold black
> body radiation (2.7 Kelvin) in outer space. Did they really use
> Forth? I never heard that before.
That was certainly not the impression that I had back
in my astrophysics days. The signature of some very
complex and most improbable molecules have been identified
in interstellar space.
> Everyone should save the above message. There will be exam
> questions about it on comp.lang.forth in the future. Just be
> sure to remove the part about Penzias & Wilson.
And they should read it more carefully, and quote it more
carefully than you did. I haven't looked up the details
of who discovered the large molecules but I was not
working with that radio telescope or Forth back in those
days like Elizabeth and Chuck.
a...@redhat.invalid
> (boo, hiss, to people who don't change the subject line)
> Elizabeth D. Rather wrote:
>
>> It was 1971. The computers for which the first standalone
>> Forth that we'd all recognize was developed were used to do
>> data acquisition and control for the 36' (11M) radio
>> telescope belonging to NRAO on Kitt Peak Mtn, Arizona.
>> They had 16K and 24K bytes memory, respectively. They
>> were dedicated to their respective functions, and certainly
>> couldn't have been used for "general purpose computing"
>> (only mainframes could do that then).
>
>> The Nobel Prize winning discovery of large molecules in
>> interstellar space was made on this system, by Penzias
>> & Wilson of Bell Labs.
> OH HORRORS! False doctrine. Penzias & Wilson of Bell Labs
> did not discover large molecules in interstellar space. Actually
> nobody has ever discovered large molecules in interstellar
> space, just small ones.
Penzias, Wilson and their Bell Labs co-worker Keith Jefferts
discovered the existence of deuterium (heavy hydrogen) in outer space
in 1973, providing additional clues to the birth of the universe.
"The most personally satisfying portion of this work for me was the
discovery in 1973 of a deuterated molecular species, DCN," Penzias
said. "This work provided us with evidence for the cosmological origin
of this important substance, which earned the nickname 'Arno's white
whale' during this period" - a reference to the elusive whale in
Herman Melville's classic, Moby Dick.
http://www.bell-labs.com/user/feature/archives/penzias/
I suppose DCN is deuterium cyanide.
The question hinges on whether that molcule is "large" or "small".
Andrew.
Jeff Fox
> I would say that's nearly identical to pre-emptive multitasking. Even
> in a real pre-emptive system, the CPU generally waits until the
> current instruction has finished executing before delivering the
> interrupt, and waits until all interrupts have processed before
> switching tasks. That is, task switching happens between
> instructions.
Just currious, if one is executing a repeat move with
a count of say 64K and an interrupt occurs does it
happen between two moves or at the end of the repeat
part of the instruction? In other words where to
interrupts occur when some instructions can take a
very large number of clock cycles.
(never having done any real-time programming tasks on
that architecture I have always wondered about that.)
Elizabeth D. Rather
> > The Nobel Prize winning discovery of large molecules in
> > interstellar space was made on this system, by Penzias
> > & Wilson of Bell Labs.
>
> OH HORRORS! False doctrine. Penzias & Wilson of Bell Labs
> did not discover large molecules in interstellar space. Actually
> nobody has ever discovered large molecules in interstellar
> space, just small ones. Penzias & Wilson discovered cold black
> body radiation (2.7 Kelvin) in outer space. Did they really use
> Forth? I never heard that before.
Ok, half-false. The Nobel was for the black body radiation,
measurements made in 1965 on a very primitive horn at Bell Labs.
Their work with interstellar molecules was done on the NRAO 36'
telescope controlled by Forth.
-------------
From http://www.bell-labs.com/user/feature/archives/penzias/:
Penzias also has been honored for his pioneering work in interstellar
chemistry, discovering the presence of key chemicals among the stars.
Using his pioneering techniques to observe millimeter-wave radio spectra
emanating from space, Penzias and his colleagues identified carbon
monoxide and several other simple molecules in the dusty clouds in
interstellar space.
Among other finds, the team pinpointed the nuclear composition of the
constituent atoms of these molecules--the remnants of burned-out stars
and the raw materials for new ones. This work gave astronomers an
important new window into stellar composition and life cycles, and has
grown into a flourishing branch of astronomy.
Discovering deuterium in outer space Penzias, Wilson and their Bell Labs
co-worker Keith Jefferts discovered the existence of deuterium (heavy
hydrogen) in outer space in 1973, providing additional clues to the
birth of the universe.
------------
From www.tuc.nrao.edu/meeting/proceedings/contributions/preface.ps:
Interstellar carbon monoxide (CO) was first detected in 1970 with the 36
foot diameter telescope of the National Radio Astronomy Observatory on
Kitt Peak in Southern Arizona. R. W. Wilson, K. B. Jefferts, and A. A.
Penzias of Bell Labs reported, "We have found intense 2.6 mm line
radiation from nine Galactic sources which we attribute to carbon
monoxide."
Soon afterward, several other basic molecules were also observed in
space. IAU Symposium 170, CO: Twenty Five Years of Millimeter Wave
Spectroscopy, was organized to commemorate those discoveries. The
Symposium reviewed the accomplishments of a quarter century of research
on interstellar molecular gas, surveyed the current state of
millimeter-wave spectroscopy, and
gave a glimpse of what the next 25 years might hold.
---------------
The Forth system on the 36' telescope continued in operation for a long
time, through several major upgrades, until the telescope itself was
dismantled in (I think) 1998. At the time I was working there (1971-73)
I worked closely with Penzias, Wilson, Jefferts, et al., as they came to
observe several times a year and almost always had some special
requirements that I could help them with. They had dinner at my house
on a number of occasions.
William Park
> IMHO the main problem with Forth's unpopularity is that it is too good
> at what it does. People resent that and thus most sound-bytes in
> circulation repeat and exagerate the most absurd things about Forth.
> I think this is true for the people using Forth as much as those who
> don't. There are certainly more negative sound-bytes about Forth in
> c.l.f than anywhere else.
From outsider's perspective... I think Forth language itself is reason
for its unpopularity. The step-by-step layout of Forth program makes it
difficult to write, read, and maintain. To illustrate, programming math
formula into HP calculator may be fun at first, but it's pain to go over
it later. In-line notation is much easier to write and read.
Maybe Forth has changed since...
--
William Park, Open Geometry Consulting, <openge...@yahoo.ca>
8 CPU cluster, NAS, (Slackware) Linux, Python, LaTeX, Vim, Mutt, Tin
Jeff Fox
>
> From outsider's perspective... I think Forth language itself
> is reason for its unpopularity. The step-by-step layout of
> Forth program makes it difficult to write, read, and maintain.
> To illustrate, programming math formula into HP calculator may
> be fun at first, but it's pain to go over it later. In-line
> notation is much easier to write and read.
>
> Maybe Forth has changed since...
I don't think Forth has changed in that respect. I certainly
know what you mean and have heard it before. In fact I agree
with you about that but it is not what I was getting at.
I suppose the way that I see it is that Forth is about
man machine control or man machine communication and
as such lets one get very close to the machine. When
you get really close you see that things are postfix
like in Forth. But people are taught math in infix
notation so since they already know that it is easier
than seeing things the way they appear to the
computer.
Of course we have a problem already with the fact that
the way we read, write and speak math are all so
different that it makes it much harder for us to learn
it than it could be. Once a person learns one thing, the
hard way, they are often predisposed to see learning
it a different way even harder. If you learn it
backwards in the first place then forward looks backward
and is difficult. But the real problem is that
we learn it backwards, upside down, and with holes so
when we see it in a simple straightforward way it
can look backwards and upside down to us.
If you learned infix, and most people did, then there
is a learning curve to actually understand what
computers actually do. Most people would rather not
deal with that and let a compiler turn things around
and over for them. In Forth we prefer to be the
compiler and understand more of what the computer is
doing. We prefer a deeper understanding and degree
of control.
Of course as far as calculators go it is also fun
to enter equations in infix for a while. After you
have entered the equations hundreds of times you
begin to wish that you had a real computer that
could have extensible software and learn what
you did yesterday and built on it today so that
you wouldn't have to type in that whole equation
again today.
We start with what appears pretty backward to
people who only have a surface infix understanding
of what is going on. That part is definately not
for everyone. Most people prefer not ever getting
that close to the metal, and they shouldn't.
I saw a Linus Torvals interview last year. I thought
he was very funny. He said that it was ridiculous
that we try to teach everyone to program computers
in school today and don't teach anyone to be plumbers.
He said that not everyone _should_ program computers
and that if we dumb it down enough to even try that
that our computer and our plumbing will get all
clogged up with the same thing. As politically
incorrect as that is I had to love it.
Forth requires a driver, a responsible driver. Forth
is an amplifier and will amplify good or bad ideas.
It does make it pretty useless to people who don't
have any good ideas to amplify. I never felt that
Forth was that sort of thing. I think amplifying
average does not produce good.
The trend for the last couple of decades has been
to dumb down the programming enviroment thinking
that if the tools are smarter then less knowledgable
programmers can do the job. So less knowledgable
programmers are not prepared to deal with anything
except algebreic notation and need tools that do
more of the work for them. That's fine but it
is not a good match to Forth.
As a result we have a generation of managers who
can't do analysis and a generation of code monkeys
who can't either. So we have an industry that
builds things out of buggy libraries with no hope
of ever reversing the spiraling complexity, bloat,
and intentional wastefullness. It does make for
more jobs and more work and more replacable humans
which is all good for keeping the green paper moving.
Of course I was not talking about people who
don't have the background to do Forth and don't
like it because they need an infix scripting
language with rigid syntax. I was talking
about very sharp technical people who could do
a much better job with Forth but who simply
hate Forth for non-technical reasons. The people
who try to do what we try to do with Forth. The
people who look at the compiled code with a
debugger and try to get the dumb compiler to
do a better job!
I was talking about the people who are good
programmers who have annoyed by some newbie
"preaching" Forth to them and trying to "convert"
them while showing no real understanding of the
language at all. Of course they will come away
with the impression that Forth is a religion not
a programming language. Then they tell other
people about their experince with some of these
overly enthusiastic newbies, especially the ones
who have remained newbies for twenty years and
are still "preaching" to expert programmers
while repeating every ridiculous negative sound
byte about Forth that exists.
Another reason that people seem to hate Forth is
that it sounds too good to be true. It sounds like
a lie. Most stuff in the industry is and so by
Occam's Razor the most likely thing is that Forth is
a lie too.
They just have a hard time understanding what they
hear and if what they hear were true it can be very
crushing to their ego or threatening. I often tell the
story about the guy who said that he hated Chuck's
presentation because Chuck called him an idiot for
using C.
What was funny was that Chuck had not mentioned C
or Intel at all that day. Not a single word about
anything like that. All Chuck did was report what
he was doing with Forth. This guy just thought to
himself that if what Chuck said was true, if Chuck
could write his own language, write his own compiler,
solve industry wide problems in CAD, design his
own chips, and beat companies with thousands of
employees and billion dollar development budgets
while working virtually without any funding, if Chuck
could do that much with Forth, that much more than
what he could do with C, that he considered himself
an idiot for using C. I mean how many C programmers
did it take just to write those 10 CD of C code that
Chuck replaced with a few K of his code? How many
engineers did it take to design the chips that needed
1000x times as many transistors to reach X mips?
It is often far easier for people to screen out the
truth than to face it. That is just human nature.
I think Forth is unpopular because all most people
know about it are the damaging sound bytes in
circulation, it does not appear to be dumbed down
as much as other things, it can make programs that
are too small and too fast compared to what they
are used too, it can get the work done sooner,
it can provide more reliable solutions, and
simply does not require the skills that many
people have or requires skills that many people
don't have. It is understandable and doesn't
require the expertise that they are being paid
for having.
I don't see it as good or bad. It just is. Popular
is ok. I prefer exceptional. Exceptional is rarely
popular. Forth is exceptional. For those who want
to push the limit it is good. I would not want
everyone trying to push the limit.
When I am out on the racetrack I really hope that
the other drivers will be experts and drive at about
the same speed that I drive. I get more than enough
of dealing with "average" drivers on the streets
every day. Sheesh!
I think of Forth the same way. When I go to FIG
meetings there are some very sharp (and often strange)
people there who are Forth types. I learn a lot more
from them than I do from average people. That is
fine with me. I like that.
I have no interest in dumbing down Forth to make it
more like other things just to make it more popular.
I am very outspoken about the fact that I see most
suggestions for how to change Forth to be of that
type. We can take all the bad ideas that are popular
and amplify them with Forth, but why? Sure what
we get might be more popular, but so what? Popular
was never at the top of any of my lists.
Forth is extensible so we can make it look just like
something else that already exists, but why?
I think Forth appeals to people who want to get the
most out of themselves. That appeals to me. That
is what I like about it.
But I certainly do understand what you said.
2 + 2 = 4 ...
what is this wierd 2 2 + stuff?
Well that just how it works. You can't do a + until
you have two arguments!
As a physics major math was just a tool to me, but I was
a math major for one semester. I got the impression from
that and from Loglan and the Warf-Sapier hypothesis that
the first problem is that we teach math backward and
upside down. I think we should teach programming
before math. If I had understood the algorithms that
I learned by rote as child it would have made a lot
more sense to me.
Perhaps that is why talking Barbie says "Math is hard!" ;-)
> William Park, Open Geometry Consulting, <openge...@yahoo.ca>
> 8 CPU cluster, NAS, (Slackware) Linux, Python, LaTeX, Vim, Mutt, Tin
Jeff Fox, 21st century Forth, Forth hardware, parallel Forth,
AI, user interfaces, unpopular rants. ;-)
William Park
> William Park wrote:
>>
>> From outsider's perspective... I think Forth language itself
>> is reason for its unpopularity. The step-by-step layout of
>> Forth program makes it difficult to write, read, and maintain.
>> To illustrate, programming math formula into HP calculator may
>> be fun at first, but it's pain to go over it later. In-line
>> notation is much easier to write and read.
>>
>> Maybe Forth has changed since...
>
> I don't think Forth has changed in that respect. I certainly
> know what you mean and have heard it before. In fact I agree
> with you about that but it is not what I was getting at.
> What was funny was that Chuck had not mentioned C
> or Intel at all that day. Not a single word about
> anything like that. All Chuck did was report what
> he was doing with Forth. This guy just thought to
> himself that if what Chuck said was true, if Chuck
> could write his own language, write his own compiler,
> solve industry wide problems in CAD, design his
> own chips, and beat companies with thousands of
> employees and billion dollar development budgets
> while working virtually without any funding, if Chuck
> could do that much with Forth, that much more than
> what he could do with C, that he considered himself
> an idiot for using C. I mean how many C programmers
> did it take just to write those 10 CD of C code that
> Chuck replaced with a few K of his code? How many
> engineers did it take to design the chips that needed
> 1000x times as many transistors to reach X mips?
I'm old enough (but not too old) to have had experience of hand
assembling 6809/68000. And, I used to be keen about my HP calculators.
Then, I grew up and discovered that there are only 26 hours in a day.
:-)
Most people don't need the flexibility and control that Forth gives over
the machine. Even I don't need such control. I just want my mail,
news, web, etc. Also, Unix is written in C.
However, I've always been fascinated by stack engine. If it's so much
better than conventional memory addressed CPU, why do we not see Forth
engine more?
--
Gary Chanson
"Jeff Fox" <f...@ultratechnology.com> wrote in message
news:3C4C7470...@ultratechnology.com...
> ri...@cougar.no.domain wrote:
> > One particularly weird thing I've played with is putting a yield() in
> > Next. This made a cooperative multitasking scheme appear pre-emptive
> > to Forth.
>
> Perhaps we should just call our cooperative multitasking
> pre-emptive/cooperative multitasking. If one mucks around
> with the task ring with some priority mechanism or
> multiple occurances of one task in the ring I do
> think that does qualify as pre-emptive, but perhaps
> people also assume that it must be timer and interrupt
> driven to be pre-emptive. Of course in almost all cases
> Forth will be rejected anyway unless it is just a thin
> layer written in C for scripting purposes because of
> integration issues.
No way! Pre-emptive multitasking by definition interrupts the executing
task without its cooperation.
Gary Chanson
In Intel CPUs, MOVS is a single instruction and REP is a prefix so
interrupts would be processed between iterations.
Gary Chanson
"William Park" <openge...@DELETE.yahoo.ca> wrote in message
news:UL438.1010$Vd.2...@news.eol.ca...
>
> From outsider's perspective... I think Forth language itself is reason
> for its unpopularity. The step-by-step layout of Forth program makes it
> difficult to write, read, and maintain. To illustrate, programming math
> formula into HP calculator may be fun at first, but it's pain to go over
> it later. In-line notation is much easier to write and read.
I don't agree. I loved using HP calculators so much that I picked Forth
because it was similar to HP syntax. I mostly get paid to program in C
these days, but I prefer Forth because it's EASIER to write and maintain.
Bernd Paysan
> It waits until the end of the current iteration before transferring to
> the interrupt handler. However, if the cause of the exception is a
> fault, then the original state of the registers is restored to what
> they were before the instruction started executing, in order to allow
> instruction restart.
No, even in an exception, only the original state of the registers ath
the beginning of the faulting iteration is restored. E.g. think of rep
movs half a gigabyte of virtual memory around. This rep movs has to be
interrupted several times to allow the VM to swap. It has to be
restarted at the faulting point, not all over again (because with all
over again, it wouldn't be able to solve the problem).
The complex addressing modes of the VAX and the 68020 made it necessary
to restart faulting instructions *in the middle* of an instruction,
because a single instruction could access a number of pages (on VAX I
think up to 6). The VM didn't guarantee a LRU depth of 6, so it would be
possible that swapping in page 6 swapped out page 1, and making the
instruction fault again if restarted from scratch.
Instead of getting a big club and hitting the instruction set designer
over the head (which would have been the right solution), they dumped
microcode storage on the stack ;-).
Klaus Seegebarth
wrote:
>Klaus Seegebarth wrote:
>> [snip...snip]
>> I am one of these people, who are using Forth in embedded systems
>> successfully and i am also reading c.a.e, but until now i would not
>> recommend Forth neither there nor in other places.
>
>what else ?
Nothing, i just keep my mouth closed. We were talking about
recommendations in c.a.e, where people are using any hardware between
a 12bit PIC and full blown PCs for embedded work, not about general
purpose computers.
I am not talking about different programming languages, i am talking
about the fact, that from my point of view it is too difficult for
beginners to start with Forth and therefore i do not recommend it,
although i use it and like it.
It is my point, that all Forth systems i have seen so far, all put
more restrictions on the user than necessary and that therefore these
systems are useful only in limited areas. It is my experience that i
can use assemblers and C-compilers without these restrictions and
therefore it is quite normal for me, that embedded programmers mostly
prefer C or Assembler (or PL/M or Ada or ...).
[snip... snip]
>> I bought a commercial Forth (cross compiler for 166 family) several
>> years ago. Because there was only one major Forth supplier with a
>> german representive, i bought theirs.
>
>hopefully you got the complete source.
Nice joke !
>one only can decide between solutions in which one is familiar with.
>if one only knows COBOL and Pascal why one should select C++ for
>his solution ?
I agree. But perhaps one can make Forth looking so attractive, that
you would like to learn it ?
>>
>> PS:
>> Desparately hoping someone can demonstrate me, that i am totally
>> wrong, because i am still interested in a commercial Forth cross
>> compiler.
>> Needs to run in plain DOS.
>> Needs to create assembler output, which i can link to C-programs.
>> Needs to support several popular uCs.
>> Needs to support sequential files, which i can print everywhere.
>> Needs to support a minimal Forth inside the target via serial link
>
>
>hopefully these are not real requirements. at least not all together
>in same time. probably there are some different targets, at least
>one with an underlying file system (your sequential files requirement).
>which Forth architecture is required (DTC, ITC, STC, number of bits ?)
>may be DTC is better for one target then STC. this depends on your
>(different) targets.
Once again, we were talking about cross compilers originally. With the
exception of the last item, all C-compilers fullfill all these
requirements. It is my point, that Forth systems have to fullfill
these needs too, to be widely accepted.
>so I think _one_ solution for all these requirements didn't make
>sense (at least to me). I would take a small Forth system (polyForth,
>pygmy, ... ?) which is quite simple to understand and then implement
>my own stuff. Forth development is very fast, might it's faster then
>searching for existing solutions :-)
>
You are knowing good enough, that i am doing exactly this. But
nevertheless i always hope that i can avoid this work :-)
Regards
Klaus
Stephen Pelc
<openge...@DELETE.yahoo.ca> wrote:
>However, I've always been fascinated by stack engine. If it's so much
>better than conventional memory addressed CPU, why do we not see Forth
>engine more?
PSC1000, they either had inadequate peripherals and/or did not
match market need.
The history of non-standard CPU cores is littered with examples
which failed for reasons such as this. Historically, CPUs that
were language specific have never been successful, probably
because the fashionable lifetime of a programming language
is much shorter than the lifetime of a CPU core. Examples
are Transputer, Hobbit, WD Pascal Engine, Novix ...
Nowadays, the actual CPU is a (very?) small part of the total
chip. With system on chip designs, you have to use standard
tools to produce the CPU design so that you can add the
peripherals. And you will have to make sure that the stack
machine CPU will run C style languages efficiently.
Research is continuing at York University (UK) on advanced
stack machine implementations.
Stephen
--
Stephen Pelc, s...@mpeltd.demon.co.uk
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.mpeltd.demon.co.uk - free VFX Forth downloads
a...@redhat.invalid
> However, I've always been fascinated by stack engine. If it's so much
> better than conventional memory addressed CPU, why do we not see Forth
> engine more?
It's hard to generate good code for stack machines from conventional
languages. However, I believe that there has been some research into
this.
Conventional design practices, CAD systems, ect, tend to be optimized
for register machines.
It's harder to make a superscalar stack machine.
Andrew.
Stephen Pelc
Seegebarth) wrote:
>>> Desparately hoping someone can demonstrate me, that i am totally
>>> wrong, because i am still interested in a commercial Forth cross
>>> compiler.
>>> Needs to run in plain DOS.
new targets. However, our 16 bit DOS compilers for many 8 bit CPUs
are still available. How about a console mode Windows app?
>>> Needs to create assembler output, which i can link to C-programs.
point of satisfying 90% of the users. In addition, even when you have
satisfied the linker format issues, then you have to satisfy the
C calling convention issues. We have solved these issues in special
cases, but the solution of placing a jump table at an appropriate
location is simple and works. The tool to automatically generate
appropriate assembler labels is not difficult.
>>> Needs to support several popular uCs.
>>> Needs to support sequential files, which i can print everywhere.
>>> Needs to support a minimal Forth inside the target via serial link
Jeff Fox
> No way! Pre-emptive multitasking by definition
> interrupts the executing task without its cooperation.
That was my point. According to comp.realtime Forth
is not a realtime operating system period. No way!
It does not matter if it can meet much tighter
realtime requirements than what the narrow minded
define as "realtime".
Jeff Fox
>
> However, I've always been fascinated by stack engine. If it's so much
> better than conventional memory addressed CPU, why do we not see Forth
> engine more?
I think there are at least as many reasons are as the
number of different Forth engines that have been built.
They each have their own story but some people will
pigeon hole all Forth chips together or even all chips
that don't look like more of the same.
I find it funny that people say that because Lisp
machines were way too expensive that it proved that
designs that map to the intended task will never be
practical. I think that is just too small of a viewing
window. But it does slam the door on any serious
discussion of the issues.
I know in the cases of some of the chips that I have
dealt with the reasons to sell the design or manufacture
in quantity or not can be very complex. It is much
easier to pigeon hole the topic than to deal with
actual chip histories. Of course people lump the
technical details together and mix them up about
as much as the history of different chips.
I will write a long history in a book someday to
detail some of the more exciting chapters in the
story of my chip. If I try to give you the short
answer to why at least one chip has not been more
visible I would say,
luck, greed, and responsible behavior.
Jeff Fox
> In Intel CPUs, MOVS is a single instruction and REP is a prefix so
> interrupts would be processed between iterations.
That's what I figured, I mean if you had to wait 64K or 32M
cycles for an interrupt it would all but useless. On various
Intel processors what are the maximum number of clock cycles
that instructions can take between interrupt points? I
haven't been doing cycle counting on those machines for
many years.
As the average instruction cycle count has gone down a
few instructions have seen the cycle count go up. If
the maximum count is low today then the pipeline stall
and cache issues are really all that will count. But
I am currios about just how low is it on various models?
Jeff Fox
>
> No way! Pre-emptive multitasking by definition
> interrupts the executing task without its cooperation.
Perhaps the tack we should take is to say that Forth
is like microcode, we define new instructions. Like
other architectures we setup the hardware to change
tasks between the instructions. We have control
over the priority of tasks and use it to meet
realtime requirements.
But as I say I just gave on comp.realtime as clueless
years ago, not only is Forth not realtime by their
definition but they just think you are nuts if you
tell them how fast your realtime code actually is.
They just think you were off by a few million or
billion.
It is why I often say "Please provide units!" one
person is talking seconds, another milliseconds,
another microseconds, another nanoseconds, and
another picoseconds and all seem to assume that
everyone else will assume the same units that
they do. What can you say to people who argue
that a 20 second event latency is real realtime
stuff?
Jeff Fox
> Historically, CPUs that
> were language specific have never been successful, probably
> because the fashionable lifetime of a programming language
> is much shorter than the lifetime of a CPU core. Examples
> are Transputer, Hobbit, WD Pascal Engine, Novix ...
And each have very different and quite complex stories.
I was amazed over the years at how often people would
echo that sound byte. I would say, and so we have this
design that is 1000 times cheaper for computing ...
and have been interrupted many times by the other
person saying, "history has proven that language specific
chips will always fail because they are too expensive."
end of discussion.
> Nowadays, the actual CPU is a (very?) small part of the total
> chip.
Certainly with stack machines that is very true.
> With system on chip designs, you have to use standard
> tools to produce the CPU design so that you can add the
> peripherals.
If you can build a better CPU with custom tools you can
also integrate better peripherals the same way. But
again, the sound byte says that "you have to ..."
end of an serious discussion. Time to move on.
There is nothing you can do when the argument is
"you have to use C, period."
> And you will have to make sure that the stack
> machine CPU will run C style languages efficiently.
And since countless man years have been invested in
making C compilers work on register based designs
and on register based designs trying to add features
to support C the idea that C must efficiently
target the machines puts the control over whether
stack designs can be used into the hands of the
C programmers. Kill it. End of any further
discussion since C will never target these machines
efficienty compared to Forth.
When you say, you see, with Forth hardware and Forth
software we can compute same result with 1000 times
less hardware and less software the typical response
is, yes, but I have to run C and it will run 1000
times less efficiently on that architecture than
what you are talking about so it is useless. End
of any serious discussion about stack machines
by simply saying "you have to program in C."
The only solution that most people will accept seems
to be to program in C and Forth at the same time on
convention hardware. "If it's not written in C it
isn't real Forth." Forth in Forth or Forth on Forth
is what is really unpopular. As long as it is mostly
C it is not a threat to C and is mostly popular.
Jeff Fox
> > is much shorter than the lifetime of a CPU core. Examples
> > are Transputer, Hobbit, WD Pascal Engine, Novix ...
I only had experience with the transputer and the Novix.
The impression of the people in the Parallel Processing
Connection in Silicon Valley was that Inmos shot themselves
in the foot a bunch of times. Despite goverment subsidies
they seem to lock the design into using only their own
support chips. But the biggest problem was that people
didn't want to learn a new language.
Of course as Chuck as said Forth the language and
Forth the programs came first and Forth the chips
were designed to run existing code and an existing
language with a reasonable existing audience. I guess
one thing I didn't expect was that much of the Forth
audience would move to ANS Forth and be more hostile
to the idea of Forth hardware than say C programmers.
I heard that Novix was top heavy. They spent their
money on lots of things but never finished the design
and fixed the bugs in the original prototypes. Then
they sold the thing to Harris which ... as we know.
Other designs raised eight figure funding but the
money got spend on very odd things and many opportunites
to sell millions or billions of units were passed over
for quite a variety of complex reasons.
a...@redhat.invalid
> Of course as Chuck as said Forth the language and
> Forth the programs came first and Forth the chips
> were designed to run existing code and an existing
> language with a reasonable existing audience. I guess
> one thing I didn't expect was that much of the Forth
> audience would move to ANS Forth and be more hostile
> to the idea of Forth hardware than say C programmers.
Me neither. In fact, I'm surprised that any Forth programmers are
hostile to Forth hardware. Who are these people?
Andrew.
Michael Coughlin
[snip]
> ... We were talking about recommendations in c.a.e, where
> people are using any hardware between a 12bit PIC and full
> blown PCs for embedded work, not about general purpose
> computers.
>
> I am not talking about different programming languages,
> i am talking about the fact, that from my point of view
> it is too difficult for beginners to start with Forth and
> therefore i do not recommend it, although i use it and like
> it.
>
> It is my point, that all Forth systems i have seen so far,
> all put more restrictions on the user than necessary and
> that therefore these systems are useful only in limited
> areas. It is my experience that i can use assemblers and
> C-compilers without these restrictions and therefore it is
> quite normal for me, that embedded programmers mostly
> prefer C or Assembler (or PL/M or Ada or ...).
[snip]
What would you suggest be done to make a Forth system that
you could recommend to a beginner?
When I first learned about Forth, I found that it was far
less restrictive than any other language or operating system. It
let me get at the bare hardware as well as write high level code
with equal ease. It was described very well by the following
quote from the article "FORTH - A Language for Interactive
Computing" which was written by Charles H.Moore and Geoffrey C.
Leach in 1970. The whole thing is posted at
http://www.UltraTechnology.com/f70c1.html
"The software provided with large computers supplies
a hierarchy of languages; The assembler defines the language for
describing the compiler and supervisor; the supervisor the
language for job control; the compiler the language for
application programs; the application program the language for
its input. The user may not know, or know of, all these
languages; but they are there. They stand between him and
the computer, imposing their restrictions on what he can
do and what it will cost.
And cost it does, for this vast hierarchy of languages
requires a huge investment of man and machine time to produce,
and an equally large effort to maintain. The cost of
documenting these programs and of reading the documentation is
enormous. And after all this effort the programs are still
full of bugs, awkward to use and satisfying to no one.
We maintain that this multi-level nightmare is precisely
that. We place the blame upon the lack of a suitable language.
FORTH provides a suitable language, and by using it an order of
magnitude improvement in the cost, effort and efficiency of
providing a terminal interface."
I still agree that the above descibes the hierarchy of
languages that make up a C+Unix, Ada, etc. We no longer use
"terminal interfaces" for program development, but Forth would
work just fine with a graphical interface with multiple windows.
Why do you prefer the more complicated systems instead of the
simple ideal of Forth? Do you think the modern versions of Forth
are true to Chuck Moore's invention of 1970, or have they become
something else?
William Park
> software we can compute same result with 1000 times less hardware and
> less software the typical response is, yes, but I have to run C and it
> will run 1000 times less efficiently on that architecture than what
> you are talking about so it is useless. End of any serious discussion
> about stack machines by simply saying "you have to program in C."
Hi Jeff, I've heard this at least 1000 times. So, rather than rehashing
old arguments... where do you (and other Forth developers) go from here?
Historically, people embraced PC because it was so much better than
typewriter. And, they continue to use computers mainly for "word
processing" stuffs, ie. MS-Word. This is true for Unix as well. I
started with Linux because I needed TeX/LaTeX to do my thesis. Now,
it's too late to duplicate that with Forth.
The only market that I can think of for Forth chip is NAS (network
attached storage). NAS is essentially a server with lots of harddisks
which can be mounted over the net. Usually, the disks are in software
or hardware RAID; and, on top of that, you put your filesystems and run
NFS.
Do you foresee Forth chip making inroads into RAID or NAS area?
Andreas Klimas
>
> On Sat, 19 Jan 2002 16:10:13 +0100, Andreas Klimas <kli...@k-r.de>
> wrote:
>
> >Klaus Seegebarth wrote:
> >> [snip...snip]
> >> I am one of these people, who are using Forth in embedded systems
> >> successfully and i am also reading c.a.e, but until now i would not
> >> recommend Forth neither there nor in other places.
> >
> >what else ?
>
> Nothing, i just keep my mouth closed. We were talking about
> recommendations in c.a.e, where people are using any hardware between
> a 12bit PIC and full blown PCs for embedded work, not about general
> purpose computers.
>
> I am not talking about different programming languages, i am talking
> about the fact, that from my point of view it is too difficult for
> beginners to start with Forth and therefore i do not recommend it,
> although i use it and like it.
a good point. it takes me a year to find a way through that
many different Forth systems. it depends on what one will achieve.
the beginning is not so easy as some people here want to told
us. this is not a problem of Forth, it's a problem of many different
Forth systems and documentations. but it's worth of time to
read most of them :-) but after one is familiar with Forth
the there are many advantages against C.
>
> It is my point, that all Forth systems i have seen so far, all put
> more restrictions on the user than necessary and that therefore these
> systems are useful only in limited areas. It is my experience that i
> can use assemblers and C-compilers without these restrictions and
> therefore it is quite normal for me, that embedded programmers mostly
> prefer C or Assembler (or PL/M or Ada or ...).
so what are you are meaning by 'restrictions' ?
I'm not familiar with embedded programming and didn't have a clue.
>
> [snip... snip]
>
> >> I bought a commercial Forth (cross compiler for 166 family) several
> >> years ago. Because there was only one major Forth supplier with a
> >> german representive, i bought theirs.
> >
> >hopefully you got the complete source.
>
> Nice joke !
>
> >one only can decide between solutions in which one is familiar with.
> >if one only knows COBOL and Pascal why one should select C++ for
> >his solution ?
>
> I agree. But perhaps one can make Forth looking so attractive, that
> you would like to learn it ?
the ability to control the complete system without emergencies is
my favorite argument.
> >so I think _one_ solution for all these requirements didn't make
> >sense (at least to me). I would take a small Forth system (polyForth,
> >pygmy, ... ?) which is quite simple to understand and then implement
> >my own stuff. Forth development is very fast, might it's faster then
> >searching for existing solutions :-)
> >
> You are knowing good enough, that i am doing exactly this. But
> nevertheless i always hope that i can avoid this work :-)
to do this is fun (for me) - and for you, I guess :-)
Andreas
Jeff Fox
> I still agree that the above descibes the hierarchy of
> languages that make up a C+Unix, Ada, etc. We no longer use
> "terminal interfaces" for program development, but Forth would
> work just fine with a graphical interface with multiple windows.
I agree. That is why Chuck moved to GUI more than decade ago
and why I have focused a lot on writing GUI over the years.
Chuck said last year that the idea that Forth provides a
command line interface is another obsolete concept.
I was quite jazzed when I first read Peter Knagg's essay
about how Forth needed a GUI to move into the modern age.
I was going right along with him saying, yes, yes, Forth
can do a Smalltalk like GUI system in a few lines of code.
YES!
Forth can do a GUI better than anything else, then I got
to where Peter concluded that the only way to provide
the GUI was to graft Forth on top of Windows and use
the dreadful windows API which is about as anti-thetical
to Forth as I could imagine. And I said, Oh no, is that
what's coming?
I worried that as the vendors tell us that the interface
would dwarf Forth itself and require most of the code
and most of the complexity and make Forth many many
times more complex instead of simpler and easier than
ever. I worried that people would throw out the Forth
OS, the Forth GUI, and maybe even write their Forth
in C instead of Forth to make it easier to make it
more like everything else in the windows world.
Of course I have only used winForth, ProForth for
Windows, Win32forth, and SwiftForth and have only
looked at VFX and several other Forths for Windows.
One of the most interesting Forth's for Windows
that I looked at was never released.
I always found the windows API work very distasteful.
At least I sometimes was being paid to do it. But
I must say that Forth does provide a nice way to
get a handle on it and make it as palatable as
possible.
I have been most impressed recently with Alegra. As
the author said, he picked a "real" problem, not a
"toy" problem. He made a list of the most important
fifty or so functions in windows and set out to do
it right. He said it was not as easy as I sometimes
make it sound to write a good Forth program and that
there is a lot of inherent complexity in managing
multiple overlapping resizable scalable windows with
a set of widgets on top. He said, it isn't trivial.
It took considerable effort to get the top fifty windows
functions down to 258 words of code. (not 258 Forth
words, 258 cells.) Of course he did make the problem
much harder by aiming to take full advantage of using
software to manipulate the hardware to do hardware
windows acceleration.
But I loved his comment that like Chuck's comments
about how these small on-chip stacks were virtually
infinite stacks that he had come to feel that he could
fit just about anything into the remaining space in
the "infinite 1K page" that he had been working on for
some time and which was still 3/4 empty.
> Why do you prefer the more complicated systems instead of the
> simple ideal of Forth? Do you think the modern versions of Forth
> are true to Chuck Moore's invention of 1970, or have they become
> something else?
It depends on what you mean by "modern." I think of it as
21st century Forth, not twenty year old Forth grafted to
today's monstrosities.
Elizabeth D. Rather
>
> I am not talking about different programming languages, i am talking
> about the fact, that from my point of view it is too difficult for
> beginners to start with Forth and therefore i do not recommend it,
> although i use it and like it.
I am sorry that you have found it difficult. What books and tutorials
have you used?
> It is my point, that all Forth systems i have seen so far, all put
> more restrictions on the user than necessary and that therefore these
> systems are useful only in limited areas. It is my experience that i
> can use assemblers and C-compilers without these restrictions and
> therefore it is quite normal for me, that embedded programmers mostly
> prefer C or Assembler (or PL/M or Ada or ...).
>
> [snip... snip]
>
> >> I bought a commercial Forth (cross compiler for 166 family) several
> >> years ago. Because there was only one major Forth supplier with a
> >> german representive, i bought theirs.
> >
> >hopefully you got the complete source.
>
> Nice joke !
Since you're reporting from bad experience, could you tell us what
product, how long ago, and what restrictions bothered you?
Unfortunately, we do not support the 166 family, but we do have
cross-compilers for many microcontrollers, which most of our
customers say they find easy to use and quite free of restrictions
(and they do include all source for the target).
Andreas Klimas
>
> Michael Coughlin wrote:
>
> > I still agree that the above descibes the hierarchy of
> > languages that make up a C+Unix, Ada, etc. We no longer use
> > "terminal interfaces" for program development, but Forth would
> > work just fine with a graphical interface with multiple windows.
>
> I agree. That is why Chuck moved to GUI more than decade ago
> and why I have focused a lot on writing GUI over the years.
> Chuck said last year that the idea that Forth provides a
> command line interface is another obsolete concept.
>
> I was quite jazzed when I first read Peter Knagg's essay
> about how Forth needed a GUI to move into the modern age.
> I was going right along with him saying, yes, yes, Forth
> can do a Smalltalk like GUI system in a few lines of code.
every Smalltalk I know includes a complete different
approach for doing GUI. the best solution, IMO, is done by
VisualWorks, but I want to see and understand a GUI system
written in and for Forth.
Andreas
Elizabeth D. Rather
> ...
> The only market that I can think of for Forth chip is NAS (network
> attached storage). NAS is essentially a server with lots of harddisks
> which can be mounted over the net. Usually, the disks are in software
> or hardware RAID; and, on top of that, you put your filesystems and run
> NFS.
>
> Do you foresee Forth chip making inroads into RAID or NAS area?
I don't know about Forth chips, but I do know that Greg Bailey at
Athena Programming <gr...@minerva.com> produces incredibly reliable,
high-performance, and secure Internet servers and storage systems
based on off-the-shelf PCs running a proprietary Forth-based OS.
These systems are, at the moment, sold only through his OEMs, but
far out-perform anything on be market based on Unix, Linux, or
(of course) Windows.
Jeff Fox
>
> Hi Jeff, I've heard this at least 1000 times. So, rather than
> rehashing old arguments... where do you
> (and other Forth developers) go from here?
I can't speak for other developers. I am considering various
options personaly. As for F21 I might make them in the third
world that now has "obsolete" cheap fabs and interest in
inexpesive computers. I might upgrade and produce them on
.25u or .18u and increase speed to 1000mips or 2700mips,
50Gig timer, 400Mhz analog etc. I might look into upgrading
to a new design in OKAD II, an F32 or more generic multiprocessing
chip design like 25x. There has been interest in a 1000x and
10,000x. I would love to get access to state of the art
fabs and upgrade to 5000mips per core.
Meanwhile I will finish up Aha and put it on the new desktop
and interrupt driven GUI, or make an Alegra port, and do
some demo software that people have asked for. Then I have
several applications that interest me personally.
I may do more documentation, but quite frankly I have
become very tired of trying to explain things to other
people only to have them want to argue with you about
what you are doing. I may just do it and stop making
the information public. It would make things alot
easier in many ways.
But long term I have not made any decisions. I will
say that my long term plan had been to transition
from the computer industry to the spacecraft industry
at 2000 and I am little behind schedule. But as long
as it remains fun...
Who knows, I have other interests besides computers and
Forth too. I have no need to do anything except what I
love doing. ;-)
> Historically, people embraced PC because it was so much better than
> typewriter. And, they continue to use computers mainly for "word
> processing" stuffs, ie. MS-Word. This is true for Unix as well. I
> started with Linux because I needed TeX/LaTeX to do my thesis. Now,
> it's too late to duplicate that with Forth.
Right. They also are good for games and for the small
percentage of people who want to develop software.
> Do you foresee Forth chip making inroads into RAID or NAS area?
Yes. There are people working on getting Forth chips
into the hard drives to get more out of them. There are
interested hard drive makers.
Also there have been several chip designs specialized for this
purpose. That was the reason for several multiple gigabit
fiberchannel compatible I/O ports on a $1 almost ten years
ago. The idea was that it would cheaper than big boxes
for routing and protocol translation on gigabit data streams.
If the routers at the end of the fiber only cost $1 to
build then fiber would become more ubiquitous sooner.
It would also make it easy to interface almost anything
to the end of that fiber.
(this was before I saw how they could put 8,000,000
gigabit data streams on one fiber and run it through
a router. Not exactly PC consumer type stuff today. ;-)
Chuck's current approach, characterized by 25x is rather
more difficult to understand than previous chips because
of the programable hardware aspect of it. It is almost
like an FPGA.
The question of "what exactly can an FPGA do" is very
difficult to answer because it like asking "just exactly
what is software capable of doing" or "what exactly
are computers capable of doing?" You just can't
enumerate all the different pieces of hardware that
an FPGA becomes with software added or exactly what
every possible different piece of "programmed" hardware
could do. Even with a small FPGA the number of different
configurations of the hardware is nearly infinite.
With an FPGA about all you do is describe the architecture,
the number of I/O pads, the paths, the speed of the
circuits, and other constraints. You just can't
enumerate exactly everything that it could do.
I like the idea of lots and lots of multi-gigabit
fiber connections and hundreds of thousands of Forth
mips for routing and protocol translation on a $1
silicon chip. What exactly could one do with that?
Well for one thing we could improve our networks
and storage access.
I expect that Chuck has gotten very tired of people
mostly asking about running Microsoft Windows or
Linux on his chips. I think it is pretty clear that
25x was not designed for that sort of thing.
Gary Chanson
>
> That was my point. According to comp.realtime Forth
> is not a realtime operating system period. No way!
> It does not matter if it can meet much tighter
> realtime requirements than what the narrow minded
> define as "realtime".
Forth can be preemptive. I've experimented with Forth-based preemptive
multitasking. In one case, I implemented that type of multitasker for a
client just to prove to him that it would not work as well as cooperative
multitasking for his project. Windows based Forth systems are by design
preemptive.
The appeal of preemptive multitasking to many programmers is that they
can use it without taking the responsibility for properly sharing the CPU
(at least they think they can). In reality, they wind up dealing with
priority problems which can be much harder to solve then cooperative sharing
problems.
Gary Chanson
>
> That's what I figured, I mean if you had to wait 64K or 32M
> cycles for an interrupt it would all but useless. On various
> Intel processors what are the maximum number of clock cycles
> that instructions can take between interrupt points? I
> haven't been doing cycle counting on those machines for
> many years.
Off hand, I don't know. The longest instruction might be something like
75 cycles, but that might well be a small part of the interrupt latency due
to the various states that must be saved by the CPU.
Gary Chanson
>
> What can you say to people who argue
> that a 20 second event latency is real realtime
> stuff?
I'd say that the actual value is unimportant to the definition (of
course not to the application). "Real time" means predictable timings. It
could be measured in microseconds or years, but must be deterministic.
Windows is not a real time operating system because Microsoft refuses
(for good reasons) to guarantee maximum latencies, not because it's "too
slow".
William Park
> William Park wrote:
>> ...
>> The only market that I can think of for Forth chip is NAS (network
>> attached storage). NAS is essentially a server with lots of harddisks
>> which can be mounted over the net. Usually, the disks are in software
>> or hardware RAID; and, on top of that, you put your filesystems and run
>> NFS.
>>
>> Do you foresee Forth chip making inroads into RAID or NAS area?
>
> I don't know about Forth chips, but I do know that Greg Bailey at
> Athena Programming <gr...@minerva.com> produces incredibly reliable,
> high-performance, and secure Internet servers and storage systems
> based on off-the-shelf PCs running a proprietary Forth-based OS.
> These systems are, at the moment, sold only through his OEMs, but
> far out-perform anything on be market based on Unix, Linux, or
> (of course) Windows.
Hmm, I don't think "internet server" would go over very well, simply
because there are so many different network services, ie. Apache, DHCP,
Sendmail, Samba, FTP, DNS, etc.
But, NFS file server may be more marketable, because it is very
specific. You just plug the power and turn it on; and, it does one
thing and nothing else. If Forth chip is as cheap as Jeff say it is,
then you just add harddisks.
I can't think of any other major market or product for Forth, though.
Perhaps, Python running on a Forth stack engine... :-)
Gary Chanson
>
> I was quite jazzed when I first read Peter Knagg's essay
> about how Forth needed a GUI to move into the modern age.
> I was going right along with him saying, yes, yes, Forth
> can do a Smalltalk like GUI system in a few lines of code.
> YES!
>
> Forth can do a GUI better than anything else, then I got
> to where Peter concluded that the only way to provide
> the GUI was to graft Forth on top of Windows and use
> the dreadful windows API which is about as anti-thetical
> to Forth as I could imagine. And I said, Oh no, is that
> what's coming?
No, it's already here.
Elizabeth D. Rather
> ...
> > I don't know about Forth chips, but I do know that Greg Bailey at
> > Athena Programming <gr...@minerva.com> produces incredibly reliable,
> > high-performance, and secure Internet servers and storage systems
> > based on off-the-shelf PCs running a proprietary Forth-based OS.
> > These systems are, at the moment, sold only through his OEMs, but
> > far out-perform anything on be market based on Unix, Linux, or
> > (of course) Windows.
>
> Hmm, I don't think "internet server" would go over very well, simply
> because there are so many different network services, ie. Apache, DHCP,
> Sendmail, Samba, FTP, DNS, etc.
Greg presently handles FTP, DNS, SMTP and some others, in addition
to providing the primary Internet connection for a network of
computers running Windows, Unix, or whatever. It includes the
functions of a NFS plus more, but is configurable to provide
exactly what you need.
Jeff Fox
> > I was quite jazzed when I first read Peter Knagg's essay
> No, it's already here.
Well I was talking about reading Peter's essay when
it was first published. We didn't have all those Forths
for Windows back then. I assumed he was talking about
adding Windowing to Forth as had been done in PolyFORTH
until he said that the only way to do it was to add a
Forth layer on top of MS Windows. It wasn't there yet
back then.
Was winForth first? When was it released? It was a long
time ago, I know that much.