Free FORTH implementations?
Mike Burke
FORTH for over 20 years.
I'm looking for a free implementation of Forth that fits the following
criteria:
Works on x86 platforms,
Self contained environment (to boot from USB, floppy or CD),
Conforms to Chuck's and Jeff's philosophy for small, efficient programming
evironment.
I'm primarily interested in doing Robotics and AI, especially vision. Forth
didn't even cross my mind 'til I started reading some of the stuff on
moserware, and now I'm excited about the possibilities. I've been trying
colorForth and am looking for implementations with similar properties
(although I can forego the color part.
Is there any real research comparing the size, speed and ease of
implementation for different versions of Forth? Jeff and Chuck seem to think
that the ANSI Forth is bloated and slow. Is this true? Is there proof? Chuck
has a challenge page he calls "1% of the Code". Seriously, how much smaller
do Forth applications get? Where can I find a good repository of Forth
examples? Is there a good exmple or tutorial for writing drivers in Forth?
Jeff seems to think that writing an OS in Forth is a waste of time, but some
of my favorite programming experiences have been learning to respect Project
Oberon. Has anyone considered this type of thing for Forth? (It seems
ideal.)
I've read the FAQ, but the FAQ is fairly neutral and lacks the know-how I
might get from some of you folks. I hope my questions are not too
ridiculous, and I thank you in advance for your help and opinions.
Mike B.
Aleksej Saushev
> Jeff and Chuck
> seem to think that the ANSI Forth is bloated and slow. Is this
> true?
No. It is delusion, ANSI Forth is underpowered.
> Is there proof?
There's no published proof to my knowledge, but you can investigate yourself.
> Chuck has a challenge page he calls "1% of the Code".
> Seriously, how much smaller do Forth applications get?
In what terms? Lines of code? Bytes of code?
The gain is very small if any.
Though it depends on tasks you solve.
> Where can I find a good repository of Forth examples?
Repository? Forth programmers don't do repository!
When they need anything, they write it from scratch!
> Is there a good exmple or tutorial for writing drivers in Forth?
Drivers for what hardware and what usage? How does "driver" differ from
any other program?
> Jeff seems to think that writing an OS in Forth is a waste of
> time, but some of my favorite programming experiences have been
> learning to respect Project Oberon. Has anyone considered this
> type of thing for Forth? (It seems ideal.)
Many did, no usable code thus far.
--
HE CE3OH...
Anton Ertl
>I'm looking for a free implementation of Forth that fits the following
>criteria:
>
>Works on x86 platforms,
>
>Self contained environment (to boot from USB, floppy or CD),
>
>Conforms to Chuck's and Jeff's philosophy for small, efficient programming
>evironment.
ColorForth seems to fit the bill exactly.
>I've been trying
>colorForth and am looking for implementations with similar properties
>(although I can forego the color part.
Anything wrong with ColorForth?
>Is there any real research comparing the size, speed and ease of
>implementation for different versions of Forth? Jeff and Chuck seem to think
>that the ANSI Forth is bloated and slow. Is this true? Is there proof?
Maybe you should ask them.
IIRC the argument of Jeff Fox is that you should also count all the
infrastructure that a Forth system runs on and needs to build, i.e.,
the OS and various libraries, and, e.g., for Gforth, GCC.
>Where can I find a good repository of Forth
>examples?
You can find some examples mostly of standard or Gforth code on
<http://www.complang.tuwien.ac.at/forth/program-links.html>
>Jeff seems to think that writing an OS in Forth is a waste of time, but some
>of my favorite programming experiences have been learning to respect Project
>Oberon. Has anyone considered this type of thing for Forth? (It seems
>ideal.)
Yes.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2009: http://www.euroforth.org/ef09/
Jeff Fox
Your questions are not ridiculous but are provocative.
I think there are a number of systems that meet your criteria.
> Is there any real research comparing the size, speed and ease of
> implementation for different versions of Forth?
There is a lot of it, but most of it is pretty heavily filtered
or old.
> Jeff and Chuck seem to think that the ANSI Forth is bloated and slow.
I don't think there is really any single 'the ANSI Forth'
implementation and bloated and slow are terms that are best
applied to implementations. One might argue that ANSI as a
standard is bloated compared to some real implementations as
they may be clean and/or fast.
You need to remember that Chuck's context and my context is
usually in explaining what we are doing. Context is important.
In the context of comparisons to more modern Forth implementations
and/or on modern Forth hardware many ANSI Forth systems do appear
bloated. Many appear slow because speed was not a design issue
or because they are for slow processors. I am used to the idea that
a modern small processor should need five bits for most Forth
opcodes and execute then in one cycle at over 700 MHz while
many other people who use older or more conventional Forth will
think of sixteen or thirty-two bit Forth tokens that each need a
hundred machine cycles from a one megahertz clock. For
similarly priced, powered, sized etc. chips different Forth
have dramatically different size and speed. Sometimes people
use desktop chips and desktop software when a $1 target chip
could do the job. We only provide the actual size, performance,
power consumption etc. for things we have really done and
comparing them to the only other things that exist.
Many people have the opinion that Forth is stuck in the 70s or
80s or died then because those are the nature of many of the
stories of the old-timers.
We tend to explain the Forth we work on and when we make
comparisons we often compare to that. When ANS Forth is compared
to many other programming environments it may be very small
and/or fast in comparison. But Chuck and I don't talk much
about comparing ANSI Forth to non-Forth programming environments.
I do sometimes compare the different Forth systems that I
actually use.
We tend to compare to modern Forth that need only a K or two for
a compiler or a modern GUI. We tend to integrate OS as part of
Forth rather than use a generic OS like Linux. This confuses a
lot o people.
> Is this true? Is there proof?
The only 'proof' are 'existence proof.' That is there is code that
demonstrates that this or that can be as small and compact as it
has been shown to be. It does not prove that code cannot be smaller
but it does provide proof that some things are smaller or faster
than others.
SEAforth provided a coding challenge in that Forth code have
only 64 words of RAM on-chip. I found it funny that Chuck got
lots of negative comments for thirty years for saying that most
Forth programs were 1k or smaller and then designed a Forth
processor where many things had to compressed to 64 words or
less to fit at all.
You start with something that you did in 512 or 256 words last
time and implement it in 64 words or less. Then knowing that
efficiency is important you improve it. You feel a sense of
satisfaction when you can make it smaller and/or faster. Every
word of code you free up can be used for something else. It
is fun to 'prove' it can be done in 64, 50, 40, 30, 20 or
18 words of code as you improve the code. It is fun to
make the code ten times smaller and ten times faster than
what other people who wanted to make the code small and
fast said was possible. It is also easy to compare to the
code from people who simply don't care about how small or
how fast their code is. It is also fun to make things that
are hundreds or thousands of times smaller and faster than
that sort of code.
Sometimes even when people are trying to write small and fast
code and choose target chips with similar features the ratio
between really small and fast code and other code is sometimes
as dramatic as comparisons to systems that everyone agrees
are bloated and slow. These kind of comparisons really upset
some people and so are mostly avoided in c.l.f. but anyone
with real code on real systems can play the game.
If you want I can give you some specs and you can tell me
how much code it would take to implement it. Anyone who
can program can play.
> Chuck has a challenge page he calls "1% of the Code".
When pressed a lot a few years ago by the ANS Forth in C crowd
with comments that colorforth wasn't really Forth at all and
with logic that Forth can't be smaller than C because it is
after all written in C Chuck did respond by saying that Forth
should be 100x smaller than C. He even went so far as to say
that if something wasn't a hundred times smaller than typical
C code that it probably wasn't really Forth. However he
usually tries very hard to not say things that exclude things
other people call Forth from being called Forth.
We saw many examples over the years of code being 100x or
1000x smaller when going from C to well written Forth. Of
course if you apply heavy filtering and compare C to badly
written Forth code (as is common in c.l.f) or Forth on
top of C or 'good coding be damned style Forth' then C is
likely to not be a hundred times larger than that code.
Of course some might consider our ability to evolve the
hardware as a way to cheat. You start out with several
pages and a K of code, then you refine the hardware and
software design until you can code it in a paragraph,
then later a line, then later a word, and in some cases
it becomes zero words of RAM or ROM. When you reach
the level of zero words of code comparisons become
difficult.
> Seriously, how much smaller do Forth applications get?
When we worked at iTV QNIX published an OS, browser, email
program, editor, and utilities saying it was the smallest
example (existence proof) in the world because it fit on
a single floppy. Our Forth version was only about ten
times smaller but we could have made it another ten times
smaller if we had really needed to do that. Being ten
times smaller than the next smallest in the world was
enough for the investors and users. But if we had wanted
to make a stronger point for programmers we could have
ditched the rather bloated ANSI parts.
I have installed and used VLSI CAD software at several
jobs. Most people don't wince at the gigabyte of code
needed. Chuck wanted more accurate and faster code and
he wanted Forth source so he wrote his own version that
was a hundred thousand times smaller and of course
much faster and more accurate. He says it is the best
example of good Forth he has yet seen in his forty plus
years of Forth programming experience.
> Where can I find a good repository of Forth examples? Is
> there a good exmple or tutorial for writing drivers in Forth?
I would not recommend c.l.f.
> Jeff seems to think that writing an OS in Forth is a waste of time,
No. I think writing a C-style OS or Linux knock-off in Forth is
a waste of time. I have seen people waste years trying to do it.
We wrote 4OS as the OS for the target at iTV. It was just Forth
code but factored to classify some functions as generic OS. But
it was for Forth software, cooperative software, software designed
to be 'right-by-design.' It was not there to serve the purpose
of policing or recovering from ill-behaved or malicious C programs.
> but some
> of my favorite programming experiences have been learning to respect Project
> Oberon. Has anyone considered this type of thing for Forth? (It seems
> ideal.)
Forth firmware is close and there are Forth OS projects. But I have
also heard progress reports on ForthNIX drag on for years with lots
of interesting technical details only to eventually be abandoned
for reasons that became obvious along the way.
Chuck and I don't agree on all things. Chuck doesn't like mice and
point
and click GUI while I do as long as they are not bloated and buggy.
I have no problem with factoring some of the code into what looks
like an OS layer or integrating a GUI into the OS layer while Chuck
does not make as much distinction between doing Forth programming
and OS programing. When Chuck says OS he uses the term differently
than I. This should be clear when he said that "OS" was a dirty
word. What Chuck is saying is a generic one-size-fits-all OS/GUI
written in C is not appropriate for all applications. He is
suggesting that this is a dirty concept when compared to a
cleaner do-what-is-appropriate approach in Forth.
Chuck muses with the ideas of expanding colorforth to include code
often found in OS but remains focused on trying to make a business of
chip design and custom chip programming.
I have no problem with OS coding, but do know that most people mean
OS for a PC and that "PC" is a very fast moving target. So if you
don't just focus on what you need and try to provide everything
for every platform it is a many person full time job forever.
> I've read the FAQ, but the FAQ is fairly neutral and lacks the know-how I
> might get from some of you folks. I hope my questions are not too
> ridiculous, and I thank you in advance for your help and opinions.
c.l.f is best suited to providing specific help with specific
problems. The broadness of your questions have traditionally
spawned lots of discussions and people have expressed their
opinions many times on the related issues. POV tend to be
relative to what kind of Forth people do or don't do.
Best Wishes
Rod Pemberton
news:hanpve$1tio$1...@adenine.netfront.net...
> This has probably been covered here before, but I'm new. I haven't used
> FORTH for over 20 years.
>
> I'm looking for a free implementation of Forth that fits the following
> criteria:
>
> Works on x86 platforms,
>
Ok, lots of links...
> Self contained environment (to boot from USB, floppy or CD),
Not sure about that. Although easy to do, I doubt that any modern FORTHs
do. Most are implemented to execute within the confines of an existing OS.
So, I it might be hard to locate a standalone FORTH implemented as it's own
bootstrappable OS. FCODE, an embedded FORTH, is a part of some computer
BIOSes, mostly non-x86 platforms.
> Conforms to Chuck's and Jeff's philosophy for small, efficient programming
> evironment.
...?
> Is there any real research comparing the size, speed and ease of
> implementation for different versions of Forth?
There is some older information by Phillip Koopman on instruction usage:
http://www.ece.cmu.edu/~koopman/stack_computers/sec6_3.html
Various stuff by Anton Ertl, such as these:
http://www.complang.tuwien.ac.at/forth/performance.html
http://www.complang.tuwien.ac.at/forth/threading/
A post by me listing counts of needed "primitives", i.e., low-level words
not coded in FORTH, for various FORTHs:
http://groups.google.com/group/comp.lang.forth/msg/10872cb68edcb526
> Jeff and Chuck seem to think
> that the ANSI Forth is bloated and slow. Is this true? Is there proof?
I have no idea.
> Chuck has a challenge page he calls "1% of the Code".
Do you have a link? I've found "1% of the Code" mentioned in a interview...
But, I haven't found a challenge page.
> Chuck has a challenge page he calls "1% of the Code". Seriously,
> how much smaller do Forth applications get?
They can only get as small as an compiled array of addresses, primitives,
and an interpreter. The addresses are what a FORTH interpreter uses to call
functions or "words" in FORTH parlance. These addresses are a fixed size
integer. Specifically, they are the native integer address size for that
processor platform, e.g., 8-bit, 16-bit, 32-bit, 64-bit for common
microprocessors since '74.
Much of the "code density" of FORTH comes from "factoring", aka code reuse
and optimization. The remaining came from eliminating the bytes for the
call portion of a call instruction on 8-bit microprocessors, leaving just an
address. This had a larger effect on 8-bit and 16-bit micro's, than it does
on 32-bit or 64-bit micro's due to address size and instruction encoding.
E.g., x86 16-bit code can be similarly sized or smaller because there are
large numbers of powerful single byte instructions which can reduce the
average code size below that of the two bytes needed for an array addresses.
I.e., with 16-bit code, every FORTH instruction becomes two bytes for an
average instruction size two bytes. If two optimized and equivalent
programs, one with an average instruction size of two or less and the other
with an average instruction size of two, which is more likely to be the
smaller one?
Some of that compactness of the early x86 instructions carries over into
32-bit and 64-bit code, but only if it's coded for small size. Most x86
code is code for speed. Faster instructions are less powerful (more
instructions needed), easier to decode, and larger sized. So, comparing for
size depends on what you decide to compare. Are you comparing an x86
application written for small size, or one for speed, with interpreted FORTH
code?
The real question is: Why is the FORTH community so obsessed with code size
or density? FORTH interpreters effectively reimplement the cpu's hardware
functionality in code. This means slow...
The Hugi compo is an example of what can be done in very small sized 16-bit
x86 applications:
http://www.frontiernet.net/~fys/hugi/compoold.htm
http://www.hugi.scene.org/compo/compoold.htm
http://www.frontiernet.net/~fys/hugi/hcompo.htm
> Jeff seems to think that writing an OS in Forth is a waste of time,
>
Like it or not, there are solid reasons why C is preferred for OS
development to all other languages, including FORTH.
Here are some links to FORTH's that may or may not be worth your time...
http://bigforth.sourceforge.net/
http://freshmeat.net/projects/4th
http://christophe.lavarenne.free.fr/ff/
http://www.netbay.com.au/~dxforth/index.html
http://www.forth.hccnet.nl/pr-chf.html
http://www.annexia.org/forth
http://www.bentwookie.org/blog/kragen-hacks/2007-November/000469.html
http://www.softsynth.com/pforth/
http://retroforth.org/
http://pfe.sourceforge.net/
http://sourceforge.net/projects/spf/
http://sourceforge.net/projects/win32fx/
http://win32forth.sourceforge.net/
http://www.figuk.plus.com/4thres/systems.htm
http://t.webring.com/hub?ring=forth
http://sourceforge.net/projects/mrforth/#
HTH,
Rod Pemberton
Albert van der Horst
Rod Pemberton <do_no...@nohavenot.cmm> wrote:
>"Mike Burke" <meb...@rocomai.com> wrote in message
>news:hanpve$1tio$1...@adenine.netfront.net...
>> This has probably been covered here before, but I'm new. I haven't used
>> FORTH for over 20 years.
>>
>> I'm looking for a free implementation of Forth that fits the following
>> criteria:
>>
>> Works on x86 platforms,
>>
>
>Ok, lots of links...
>
>> Self contained environment (to boot from USB, floppy or CD),
>
>Not sure about that. Although easy to do, I doubt that any modern FORTHs
Easy? Not until you try it.
>do. Most are implemented to execute within the confines of an existing OS.
This is exactly why the OP asks the question.
>So, I it might be hard to locate a standalone FORTH implemented as it's own
>bootstrappable OS.
Hehe. There we are.
>CODE, an embedded FORTH, is a part of some computer
>BIOSes, mostly non-x86 platforms.
Again specifically not what the user asks.
>
>They can only get as small as an compiled array of addresses, primitives,
>and an interpreter. The addresses are what a FORTH interpreter uses to call
>functions or "words" in FORTH parlance. These addresses are a fixed size
>integer. Specifically, they are the native integer address size for that
>processor platform, e.g., 8-bit, 16-bit, 32-bit, 64-bit for common
>microprocessors since '74.
>
>Much of the "code density" of FORTH comes from "factoring", aka code reuse
>and optimization. The remaining came from eliminating the bytes for the
>call portion of a call instruction on 8-bit microprocessors, leaving just an
>address. This had a larger effect on 8-bit and 16-bit micro's, than it does
>on 32-bit or 64-bit micro's due to address size and instruction encoding.
>E.g., x86 16-bit code can be similarly sized or smaller because there are
>large numbers of powerful single byte instructions which can reduce the
>average code size below that of the two bytes needed for an array addresses.
>I.e., with 16-bit code, every FORTH instruction becomes two bytes for an
>average instruction size two bytes. If two optimized and equivalent
>programs, one with an average instruction size of two or less and the other
>with an average instruction size of two, which is more likely to be the
>smaller one?
This is a good point. The bottom line is that as a rule of thumb
an ITC is about proportional to the cells size.
Headers and high level code scale as the cells size.
So if mina is 16K, lina64 is about 64K. This pans out.
Native code is the same size for 16 and 64 bit Intel,
because they are literally the same!
Oh well, a prefix here and there.
<SNIP>
>
>The real question is: Why is the FORTH community so obsessed with code size
>or density? FORTH interpreters effectively reimplement the cpu's hardware
>functionality in code. This means slow...
Not at all.
Marcel Hendrix is obsessed, and makes compilers that
are not slow by any measure, including comparison to languages
reputed for speed.
Chuck Moore makes processors that are Forth machines.
All bets are off, because these machine are highly non-conventional.
But they are operating on a (sub)-nanosecond scale.
<SNIP>
>HTH,
>Rod Pemberton
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Albert van der Horst
Mike Burke <meb...@rocomai.com> wrote:
>This has probably been covered here before, but I'm new. I haven't used
>FORTH for over 20 years.
>
>I'm looking for a free implementation of Forth that fits the following
>criteria:
>
>Works on x86 platforms,
ciforth does.
>
>Self contained environment (to boot from USB, floppy or CD),
Yes, at least floppy.
The latest version is not up to date w.r.t. e.g. lina, it is
an embarassing version 3.124.
http://home.hccnet.nl/a.w.m.van.der.horst/ciforth.html
I must do version 5 real soon now, and make a new version
for the booting Forth too.
It is pretty universal compared to colorforth.
This is at the expense of switching to real mode in order to
use the BIOS for disk access.
>
>Conforms to Chuck's and Jeff's philosophy for small, efficient programming
>evironment.
??
>
>I'm primarily interested in doing Robotics and AI, especially vision. Forth
My ciforth was originally designed to power a self thinking computer,
which is necessarily learning and stand alone.
<SNIP>
>
>I've read the FAQ, but the FAQ is fairly neutral and lacks the know-how I
>might get from some of you folks. I hope my questions are not too
>ridiculous, and I thank you in advance for your help and opinions.
Nothing ridiculous about it.
>
>Mike B.
Elizabeth D Rather
> "Mike Burke" <meb...@rocomai.com> writes:
...
> Anything wrong with ColorForth?
>
>> Is there any real research comparing the size, speed and ease of
>> implementation for different versions of Forth? Jeff and Chuck seem to think
>> that the ANSI Forth is bloated and slow. Is this true? Is there proof?
>
> Maybe you should ask them.
>
> IIRC the argument of Jeff Fox is that you should also count all the
> infrastructure that a Forth system runs on and needs to build, i.e.,
> the OS and various libraries, and, e.g., for Gforth, GCC.
Much depends on what your needs are. "Bloat" may be defined in various
ways, including unnecessarily bad code, but a common meaning is
"contains a lot of stuff I don't need". The problem is, people's needs
differ. Modern PC-based Forth systems offer interoperability with the
host OS and related tools, such as programmers' editors and utilities,
as well as all the other programs you run on a PC. They also provide
more powerful optimizing code compilers that produce much smaller and
faster programs than the conventional Forths of the 80's, enhanced
debugging capabilities, convenient user interfaces, as well as
cross-compilers for most microcontrollers (including x86 parts) that do
run standalone and can certainly generate a target application of 1K or
less. Of course, these things may have no value for you.
>> Where can I find a good repository of Forth
>> examples?
>
> You can find some examples mostly of standard or Gforth code on
> <http://www.complang.tuwien.ac.at/forth/program-links.html>
There are lots of sample programs with SwiftForth, as well. SwiftForth
isn't free (though it's fairly inexpensive), but there's a free
evaluation version at www.forth.com if you want to try a modern Forth
with the bells and whistles and make your own evaluation of whether it's
"bloat" by your definition, as well as running speed tests related to
the kinds of work you have in mind.
>> Jeff seems to think that writing an OS in Forth is a waste of time, but some
>> of my favorite programming experiences have been learning to respect Project
>> Oberon. Has anyone considered this type of thing for Forth? (It seems
>> ideal.)
>
> Yes.
Depends on what you mean by "an OS". Writing something with equivalent
capabilities to Unix is a major, multi-year project with limited
financial return. A standalone multitasking application on a
microcontroller is something we do every day.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Albert van der Horst
Elizabeth D Rather <erather...@removeme.forth.com> wrote:
<SNIP>
>
>Depends on what you mean by "an OS". Writing something with equivalent
>capabilities to Unix is a major, multi-year project with limited
>financial return. A standalone multitasking application on a
>microcontroller is something we do every day.
A forth on a PC that can handle only a SATA drive, and a ps/2 keyboard,
and video char's that map on the old BIOS area (B0000) by somehow reverse
engineering some information in the BIOS would be very powerful. If it
installs cleanly from an USB chip so much the better.
I expect others to have the same fascination as I have for such
a system.
It is the direction colorforth goes, but only a quarter of the way.
>
>Cheers,
>Elizabeth
P.S
It may be very powerful, but missing all the communication: USB,
ethernet, firewire, m3, audio cd, youtube, even serial I/O and
parallel I/O.
Essentially it would like most amateur Forth implementers,
generating another Forth but no application.
I have made it a point of making at least one application for
each ciforth implementation and it is hard.
(No Marcel, an example program is not an application.)
ron
> Here are some links to FORTH's that may or may not be worth your time...
You missed mine: http://ronware.org/reva/ :)
But it's an OS-hosted Forth, not a standalone -- so it may not be what
the OP was looking for. However, it is a "small" system.
Marcel Hendrix
> (No Marcel, an example program is not an application.)
So what are manx, ants, corewars, spreadsheet,
brainless, brew, cd16sim, lexex, ramanujan,
diehard, fermatl, jacobi, pollard, rabin, sqlite3,
tinykiss, SMAS, sketcher, kalman, fir, iir, scomp,
trees, lf, sz, gray, hawk, regexp, rss, telnet, irc,
mail, news, LeCroy2raw, magtwrite, nspice, runspice,
rar, sod64, artemis, tbasic, tiny-C, fJACK AOR7030,
gaussj ... then?
-marcel
Bernd Paysan
There's also the "invisible program" problem. E.g. at least two of the
current state-of-the-art JavaScript implementations use Forth as part of
their JavaScript compiler, the one donated by Adobe (comes from Flash) and
now in Thunderbird, and AFAIK also the one in Safari.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Albert van der Horst
I make a distinction.
manx surely is an application as long as someone uses it
to play real music.
OTOH for example regexp is not an application, it is a toolbox.
pollard is a program for factoring, that is a typical example
program (what was the last time your mother needed to factor
something? Did she enjoy it? )
tbasic and tiny-c are languages, hence tools
etc.
That is what I meant.
>
>-marcel
>
Groetjes Albert
Mike Burke
don't recall being this engaged in a programming project since my cryptology
days on IBM 1401's.
You all have given me a lot to think about. I love the idea of writing code
thousands of times smaller than my C projects, and I love the idea that I
might be able to run in sub-nano speeds. The sheer wealth of possibilities
almost makes me dizzy. (This is common when I take on a new project and
don't have my specs clear yet.) I can see there is a major gap in my
know-how, and the process of learning to refactor or rewrite the code more
efficiently is a skill I might have to learn. It reminds me of learning
Chess and Go... The reason I was asking for repositories was to learn how to
create excellent Forth code by looking at examples. At this stage, I
wouldn't recognize good stuff from bad.
I can see that my AI apps will probably be done under a Linux OS, and I
guess I'm going to have to figure out how to take advantage of the small
size and how to get the speed. Right now I'm using LISP, and the thought of
refactoring my code (in Forth) to reduce the size and increase the speed has
the same appeal as writing macros to do that in LISP. My brain starts
humming at the thought of threading the number crunching through the nVidia
GPU's, but I haven't a clue how I'd do that in Forth yet.
My machinery will definitely benefit from tight coupling between the
language and the processor. My little prototypes so far have been
implemented on ARM-based FPGA electronics. Sometimes the feedback
adjustments are a little wacky and slow. If I can get the programs and the
speed fast enough, I could eliminate a number of hardware gyros and do all
the adjustments at the linkages from the processors.
As for drivers, I guess I was asking if anyone had examples of the
philosophy behind writing Forth to control floppies, USB ports, HDD's GPU's
etc.,.. Just in the last couple of days I've seen that direct Forth control
seems to be much more efficient than writing to the API (where it can be
done).
Thank you for all the suggestions.
Mike B.
Andreas
> As for drivers, I guess I was asking if anyone had examples of the
> philosophy behind writing Forth to control floppies, USB ports, HDD's
> GPU's etc.,.. Just in the last couple of days I've seen that direct
> Forth control seems to be much more efficient than writing to the API
> (where it can be done).
That's "simple": create your own device commands as Forth CODE words in
assembler.
However if you have an OS under your toes (eg Linux) you can and should
use syscalls.
You can then use those new device commands like any other regular Forth
word.
Andreas
