Comparison of Propeller Forth Implementations

MJB

I am quite new to Prop, and thinking about starting with FORTH.
But I could not find a comparison of strength, weaknesses, features - so which Forth do I start with?

I searched and read many forum posts about different Forth implementations like

- PropForth - which seems to be around some time http://forums.parallax.com/showthread.php?138399-Propforth-5.0-is-available-for-download
- Tachyon - which has a vera active thread http://forums.parallax.com/showthread.php?141061-TACHYON-A-Fast-and-small-Forth-byte-code-VM-(source-code-available)-Web-pages

others ??

If the knowledgeable people could contribute their insights in one place and some links for forther reading this could be helpful for other newcomers as well.

Thanks MJB (Germany)

Peter Jakacki

This comes back down to what you are trying to do. PropForth is very mature and has a lot of features for multiprocessing etc. Tachyon is barely a month old baby but has been designed from the ground up to for what it claims, to be both fast and small and especially geared toward fast I/O operations at the familiar Forth level. Eventually (think weeks) it will have full stand-alone capabilities with VGA, SD, keyboard and text editing yet it is primarily designed for efficient runtime operation as a resident target Forth with bare-bones hardware. At present it is strong enough to run and jump around unassisted. Next stage is to teach it to fly!

You might also notice that I have been doing up the source documents on-line along with Introductions and tutorials. This will probably end up as many different project pages, much like a series of project articles in a magazine complete with schematics and photos as well as videos. It's all fun.

prof_braino

Peter's forth is tailored to what Peter does the way he does it; Sal's forth is tailored to what Sal does, the way he does it. Is what you want to do closer to Peter's way or Sal's way? If you can't tell, then maybe play with both until you can make a decision.

Since you're in Germany, check out Hive-project.de
They have forth and variants, and the relatively large community has a lot of smart members. But they are doing their own specialization, so it think it would be a third separate option. I don't read German well (or google translated German for that matter) but I believe Hive forth (M?) is significantly different from both PF and Tachyon.

In the case of Propforth, my influence is to make a general purpose forth tailored to the prop, and accessible to the greatest number of folks. Since my goals generally coincide with Sal's goals, Sal accepts my interference in exchange for my testing, documentation, and administrative functions. Propforth is on its final iteration of kernel development (after something like 5 years) and we are moving on to bring all our previous extensions to the current release now that we have automated testing complete. We should have the JupiiterACE f(from v3.2) brought forward shortly, so you will have another option for VGA, keyboard, SD forth system on you demo board compatible hardware. We also support adding unlimited props (cog and I/O pin resources), and multiple high speed links to the PC/workstation (display/communication/storage/processing resources).

Any participation or contribution you chose will be welcome.

MJB

For me reading through the many posts - - - a search in the forums about FORTH gives up for to many entries ... !!! - - -
I can not easily see what is 'Peter's way --- or Sal's way'

that is why I started this thread.

so what are Peter's goals? compared to Sal's goals ??

EDIT: ok, so even without knowing any of the Forth implementations I started collecting what I found - please correct and extend appropriately
this is a living table !!!



feature
PropForth
Tachyon


Serial
Standard serial I/O
MCS: Multi-Channel Synchronous Serial mcs.f

13 kBaud 1 channel
11,5kBaud/channel for 8 channels

• Linux might be more than twice the throughput as windows
• the lowest linux box (OLPC 433MHz) throughput 32 channels
  (3400-4500 cps) was nearly quadruple throughput of the fastest
  windows box (2 core 3.4Ghz) at 32 channels (855-891)
• the lowest linux box (OLPC 433MHz) throughput 32 channels
  (3400-4500 cps) was higher than the biggest windows box
  (4 core 2.54Ghz) at 8 channels (1741-3971)
• the number of core has an impact
• using linux has a bigger impact

-- End 20120604 --
up to 3+ Mbaud (depends on FTDI chip)


I2C
+
+


SPI




SD
Final SD support

• micro SD slot support for Spinneret, C3, etc
• Multiple partitions
• Multiple files per partition
• Any Cog may access any partition it has MOUNTED
• One Cog may access multiple files
• Multiple Cogs man access the same file
• NO BUFFERING FOR the FILE SYSTEM.

This method is nearly as fast as the speed of the SD card data transfer.

• The last file referenced is the current file, regardless of cog or partition.

NOTE:

• NON FAT compatible in RAW form.
  We can't plug the SD into a windows box and read the files.

FAT on SD




EE-filesystem
+
+ (save running image to EE)


KBD
+
+


VGA
HiRes VGA Option

b. 128 characters (columns) wide by 64 lines (rows)

c. VGA screen is divided into two sections, top half and bottom half.

Tops half is Cog 3 forth prompt
and bottom half is cog 4 forth prompt.
Serial terminal is now cog 5

d. Serial communications from cog5 to PC terminal program is also active

e. uses standard PS/2 keyboard for communication with VGA terminal

32x15 VGA text support as extension' LowResVGA.f

+


speed

350ns minimum instruction cycle time (single bytecode)
Empty loops can execute in 550ns to 875ns (absolute worst case)

Two to one stack operations ( + * AND etc)
inc opcode fetch take 900ns to 1.087us (absolute worse case) *



size




n-cogs
nprops * 8
1 ? mult soon ?



mult props
+
Master with Dependent Propellers
Master with Independent Propellers
-


logic analyzer
LogicAnalyzer.f
La.f - a lighter version of La, missing the GUI but more power and easily usable
in other forth words. Can also sample every clock cycle.



Ethernet




Spinneret
Final Spinneret Code

• Ethernet support
• telnet support using character (byte) transfer
• HTTP server support
• NIST support
• remote development over Internet support
• running forth from a HTTP page

PWM
PWM support:

• examples in forth for servo control
• examples in forth for ESC control (electronic speed controller)
• examples in forth for stepper motor control

FloatingPoint
float.f - ieee754 floating point routines added



CommandLine


can run loops while still in interactive mode



homepage

http://code.google.com/p/propforth/
https://docs.google.com/document/pub?id=1bEH0DfGmu99M1SqCbmlzl991Ssv2J5m6XWmkJX0XSl8

mindrobots

I haven't tried Peter's forth yet. It's on my plans now that one of my major time suckers for the summer is behind me.

PropForth is very mature as others have already stated. It does have a lot of information on the Wiki pages and there are several threads discussing it as you've found out. There was a BIG change in PF between version 4 and version 5. Version 5 takes a bit of retraining if you were using an older version but starting at 5 should be pretty straight forward. The PF package is very complete and has a number of supporting functions for various hardware configurations (IP support, EEPROM file system, SD file system, servos, etc.). There are a few PF users around on the forums to help you get started and it's always good to get new user feedback because some day there will be more comprehensive documentation on getting started. PF has full support of the Propeller's multi-processor architecture and allows you to easily do a number of interesting things - multiple Props, high-speed Prop-to-Prop communication, multi-channel PC to Prop communication.

Tachyon is impressive in how fast Peter has gotten it up and running and the results he has shown. I haven't run it yet but I've been following along and am really excited to see what he's coming up with. He's added a number of interesting features in the way Tachyon operates and integrates to the Propeller. It's appearing to be a lean and fast implementation with a lot of his experience showing up in it.

I'm starting to envision the two being used together in a multi-Propeller configuration as both have features that are currently unique and very useful.

Either way, the Propeller and forth go together very well and it's a useful environment for hardware testing and general Propeller play!

prof_braino

Short answer is Peter's does what Peter wants, and Sal's does what Sal wants. Longer answer is Peter wants a virtual machine running a small number of byte codes, I'm guessing for automation control applications. Sal wants a general interactive tool tailored to the prop for his experiments; it must be absolutely stable and predicable, and and the absolute "minimum necessary and sufficient" to perform the stated tasks. Both can (eventually) do most anything the other does, Propforth is much older and has a larger accumulated base of extensions, notes, instructions; but often the "forth" parts apply to either, and the chip architecture parts apply to either, the main differences are implementation details (of which I deny any knowledge). Propforth implements "create" different from "Standard" forths, and does not implement "DOES>"; it requires instead that we explicitly specify compile time behavior and run time behavior separately. This bothers some folks, but all are encouraged to make any modifications necessary for any use, just don't expect radical changes to be supported by the main kernel without careful consideration.

Peter's stuff is newer, and more likely to be volatile, but is something you can take a hand in its development and direction; and you get the chance to work with the developer during its creation.

But in any case you are off to a good start. Eventually, both versions will begin to talk to each other, and plot take over the world, or at least a couple prop chips.

I would request that you take you post from #4 and start trying to fill it out. Noone else has tried that yet, and its interesting, but I'm too busy with other projects.

jazzed

Just to make sure the Forthers that came beforth get due respect and attention:

http://code.google.com/p/propellerforth/
http://www.jacobsdesign.com.au/software/jdforth/jdforth.php

Both are described here: http://propeller.wikispaces.com/Programming+in+Forth
Whether they are of any value is subjective.

daSilva said there were 2 more which I can't find.

KevinH

You may also consider writing your own Forth or Forth-like program in Spin or PASM, especially if you have clear goals for your software. I've been much more productive after moving away from using or developing a general purpose Forth environment on the Propeller to implementing a much more focused subset that meets my needs.

prof_braino

KevinH wrote: »

You may also consider writing your own Forth or Forth-like program in Spin or PASM, especially if you have clear goals for your software. I've been much more productive after moving away from using or developing a general purpose Forth environment on the Propeller to implementing a much more focused subset that meets my needs.

that is a good idea. propforth is an example of a general purpose tool. tachyon is optimized for bit banging. . i would be interested in seeing another specialized version. Personally i favor the jupiterace-as-forth- terminal model, so i will be looking to make propforth even more generalized. effort to the other extreme provide a useful contrast.

Dave Hein

pfth is coming soon. It will be a fully ANS Forth compliant implementation, which will ease the effort of porting Forth code from other developers. I have to implement just 17 more of the 133 core words, and then I'll post the code. I hope to have the first version posted by Sunday night.

prof_braino

Dave Hein wrote: »

pfth is coming soon. It will be a fully ANS Forth compliant implementation, which will ease the effort of porting Forth code from other developers. I have to implement just 17 more of the 133 core words, and then I'll post the code. I hope to have the first version posted by Sunday night.

Just curious, will you use the spin tool as part of your build cycle, or will pfth create itself directly? a "real" forth can create itself, propforth does not yet. (Does Tachyon?)

Dave Hein

The pfth kernel is written in C, and uses PropGCC to build it. This is the most efficient way for me to develop it since I'm very familiar with C. It may not be the fastest or most compact implementation, but my main goal is standards and portability. It might be interesting to write a forth that can create itself, but that's way beyond my ability to program in Forth at this point.

Peter Jakacki

prof_braino wrote: »

that is a good idea. propforth is an example of a general purpose tool. tachyon is optimized for bit banging. . i would be interested in seeing another specialized version. Personally i favor the jupiterace-as-forth- terminal model, so i will be looking to make propforth even more generalized. effort to the other extreme provide a useful contrast.

The thing with the Tachyon kernel is that I continually optimize it as I write applications on it. However in doing so I don't want to sacrifice the low-level aspects of it such as bit-banging etc as this a strength of embedded Forth and allows us to do things that would otherwise require assembler which on the Prop means a dedicated cog and a communications interface. Given the microcontroller nature of the Propeller I would never think to try and implement ANS Forth on it for instance. On a PC ANS Forth makes sense but a microcontroller has limited resources and certain strengths and weaknesses which need to be taken into account.

All in all, I probably will not go the path of PropForth with MCS and external processor support. I want to get the most out of the bare naked Prop chip (okay, with eeprom pants on) because when I want a high-end CPU with lots of memory I use one otherwise I try and use the Prop.

LoopyByteloose

Okay, I have been avoiding the inevitable comparison, but I'll jump it.

http://propeller.wikispaces.com/Programming+in+Forth


As a new leaner, I went with PropForth. TachyonForth maybe less conservative and more ambitious in achieving its goals. These attributes are appealing. But I have a hard time keeping up with something that is in earlier stages of development.

PropForth and TachyonForth just happen to be the most active on the Forums.

So, for somebody that is new to Forth, I'd vote for PropForth.
For somebody that really is a quick study of Forth and the Propeller chip, TachyonForth may offer the fast pace that you find fun.

But I have NOT looked at every Forth available.

http://code.google.com/p/propforth/wiki/PropForth
http://forums.parallax.com/showthread.php?141061-TACHYON-A-Fast-and-small-Forth-byte-code-VM-(source-code-available)-Web-pages

There are at least two other Forths that have been mentioned recently == PForth and psft --- but PropForth has gone the distance with a good tutorial in V 5.00 and Tachyon has a long, long thread to keep you interested.

pfth is likely the newest Propeller based Forth (so we are actually waiting for downloads from Dave Hein.) and PForth (is this aka PropellerForth? PropellerForth homepage) may have been one of the eldest (so it gets mentioned but I don't quite know what its status is).

Oh and excuse me - somewhere in the mix I forgot
SpinForth http://code.google.com/p/spinforth/
and
JDForth http://www.jacobsdesign.com.au/software/jdforth/jdforth.php

Apologies if I omitted anyone - this is really an eyeopener - lots of choices.

JDForth wants $$$$, but might really support FAT files on SDcards via a Parallax OBEX object.

"di Silva says" there may be two forgotten and lost Forthers in the fog of early Forth development on the Propeller. WE say thank you to those lost Forthers.