jamma said...
Bray's apparently inspired CuteCom, which is cross platform and thus might appeal to you more.
I already have a favorite terminal emulator on Mac/Linux, but it's a pain to chown my serial port back and forth between my actual OS and the VM -- so I do most of my console work within Windows. Thanks for the links!
Chris Double said...
For those asking for quick intros to Forth, Thinking Forth is also a good free resource
Thinking Forth is pretty hardcore. I'd start with Starting Forth, which I think I've linked before, but I'll link again: www.amresearch.com/starting_forth/
I'm having trouble figuring out how to address the Propeller Demo Board under OS X. I've used Kermit to communicate with a serial Board of Education. When I plug in the Parallax USB-Serial adaptor a new device shows up in /dev and I can select it. But when I plug in the Demo Board there is no new device. Am I missing a driver?
I'm looking forward to playing with Forth on the Propeller. Back in the 80s I used Forth to write a commercial MIDI voice librarian under DOS.
Cliff L. Biffle said...
I already have a favorite terminal emulator on Mac/Linux
Which one is that?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ OS-X: because making Unix user-friendly was easier than debugging Windows
SSteve said...
I'm having trouble figuring out how to address the Propeller Demo Board under OS X. I've used Kermit to communicate with a serial Board of Education. When I plug in the Parallax USB-Serial adaptor a new device shows up in /dev and I can select it. But when I plug in the Demo Board there is no new device. Am I missing a driver?
This is not even remotely the right thread for such a question! But I'll give it a shot:
Double-check that you've got the latest FTDI USB-Serial driver. The Parallax USB-Serial Adapter should use the same driver, but it's worth checking. (There's a link to it off Parallax's product page.)
The driver itself is finicky; you might try rebooting (yeah, I know, it sucks) and then plugging in the Prop board first and seeing if it gets a node in /dev. (Oh, and make sure you have the power on. I keep forgetting that myself.)
Finally, it would definitely be worth checking to see if the Demo Board appears on any other machines, Macs or otherwise. There's always the possibility that your cable, board, or power supply is wonky.
As for terminal emulators, I'm a console kinda guy; I like minicom a lot. I'm sure there's a very nice Mac-native one out there, but in my day job I tend to be on Linux, and it's nice to retain the muscle memory on both systems.
Cliff L. Biffle said...
This is not even remotely the right thread for such a question!
Yeah, after re-reading my post it does look unrelated to the thread, doesn't it? But what I'm trying to do is use a terminal emulator with the Prop Demo Board in order to use PropellerForth, so it's at least tangentially related.
I'll try your suggestions and see if I can get something to show up in /dev. Thanks!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ OS-X: because making Unix user-friendly was easier than debugging Windows
Is this project still ongoing? ie forth on propellor?
As a british guy who remembers a home computer running forth - the jupiter ace the idea of running a full forth system on a propellor sounds cool but is this still in development?
I'm not aware of further work done by Cliff on his Forth. The most recent Forth work that I've seen is JDForth which is a Forth compiler that compiles into Spin.
There is Prop Forth , by Sal sanci. This is an interactive Forth Project. Multi-threaded and with a large Dictionary. Originally is was called SpinForth. Search Google for Spin Forth and you will be re-directed to the PropForth site. Developement continues. Prop Forth is not an ANSI forth but it is well documented
Prop forth comes with VT100 and EEprom support and Web supoort
JBForth, allows you·to run ·spin alongside Forth.·Passing data between spin and JBforth is a snack.·The professional version is a complete package·and is fast. The downside is that it is not Intereactive.
CB Forth is close to a tiny ANSI forth but the I/O is very flakey.·See the Cliff Hacks·web site for the latest version.
Not sure if Peter Jackie has done any thing·for the Prop, he's the only other forther that I know of. ·
There is little interest in Forth, which is unfortunate. . I have been working on my own tiny ANSI Forth Project based around the HX512 Xmem card and it is coming along, albeit rather slowly.
Ron
Post Edited (Ron Sutcliffe) : 11/24/2009 11:46:13 AM GMT
Ever since reading about the propellor I have been trying to work out a reason to buy one as I am not an electronics guy and this forth project looks like its reason enough! Maybe I will progress and open up a forest mims book and play with 555's etc.
Either way cool stuff to have a complete system on the Propellor
PropForth is Salsanci's latest version of SpinForth. Its is now case sensative.
TCP/IP stack for Propforth was the latest work in progress. ( a couple of months ago)
Are any of you guys following the thread about Leon's Prop/XMOS hybrid? I'm wondering if there is any interest in implementing something like Jeff Fox' F* on that. A parallel processing language based on Forth and distributed shared memory. In his case he just added one word to the Forth wordset, although what I'm thinking of would ugly that up quite a bit. I don't have any application for it myself, but it seems like such a perfect fit. Also there are other multiProp implementations that might benefit from this.
Have you had a really had a good look at PropForth by Salsanci ?
There is extensive documentation.
If you don't like it you can always modify and recompile it. You would be stuck with then same core words if you are going to rebuild it using spinmaker and were to recompile it on the Prop.
PropForth provides for inline asm (PASM), an EEprom file system and it is multi threading using a time slicer. The P and R stacks reside in each active forth cog, this could limit the number of actve threads in a single cogbut there are seven cogs available to forth, one is used for I/O. I have considered moving the dictionary out of hub to my HX512 ram card, but considered it would be too slow.
I don't see Leon's pet chip being any more suited to Forth than the Prop. Chuck Moore's S40 chip is based on 18 bit core (3 cores or one cog). J fox and many other have Forth on a Chip. Dare I say that I had considered getting an X just to see how compact the compiled code was with XC against ICCP.
XMOS isn't my pet chip, I use whatever gets the job in hand done as cheaply and easily as possible.
I don't see why the XMOS chips are unsuited to Forth, it would run just as well as any other 32-bit Forth implementation on conventional processors. Exploiting the parallelism will require some work.
I've got some S40 chips (over £60 GBP each) but haven't done anything with them, partly because of the bust-up between Chuck Moore and Intellasys. How about a Propeller-S40 hybrid?
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
My thought was initially, you wouldn't be running Forth on the XMOS (I don't know if there are any implementations), but that it would be handling shared memory functions (address translation and locks on critical data). When tasks got moved to the XMOS chip, I'm thinking that they would probably get coded in XC. If someone wrote a Forth implementation for the XMOS chip, it would really be helpful if it was source compatible with that on the Prop. But that's a lot more work than I'm considering now.
And I agree with Leon about the suitability of the XMOS chip to run Forth. I worked a little on register optimization in Forth 20 years ago (the last time I did any serious programming in Forth) and it's possible to get pretty much any cpu to run Forth efficiently.
I remember someone porting Forth to one of my transputer modules around 1985. It wasn't very efficient when I tried it; I don't think it was implemented properly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Around that time I would think most Forth implementations were indirect threaded interpreters, which aren't very efficient. But native code compilers were popping up and I got involved in optimizing register allocation. I like to think of myself as the co-inventor of the virtual stack technique, but the other co-inventor was quite a bit ahead of me (when I read his paper I stopped my own work on this). I drifted away from the Forth world and assumed that the VST would become the standard method of optimizing Forth, but years later I dropped into the Forth Newsgroup and found that while optimization was a hot topic, the technique had been all but forgotten (one commercial vendor said they used something "very much like it").
My memory of the transputer was that it had a 4 element hardware stack you HAD to use (all alu ops used it) and didn't have good stack manipulation ops, so it wouldn't have been my dream target cpu. Once you filled the stack, you had to shuffle stuff around to push anything else on it and it was pretty inefficient. The best solution which occured to me was to do a scan of each basic block to determine how deep the stack would get at maximum and adjust code generation so you would just fill the hardware stack at that depth, but I never tried to code it, I was just looking at different cpu's to see how generally applicable the technique would be.
Well yes, I haven't really fleshed this out. You would have a software parameter stack (and of course return stack too), but for most efficient execution, you want to use the hardware stack. If you just use the hardware stack naively, at some point you're threatened with overflow, and because on the transputer you don't have direct access to the lowest item on the hardware stack, you have to unload everything on the stack to get to it. If you look at a basic block and determine the maximum stack depth, you can use a mix of software stack and hardware stack operations to optimize performance.
Of course, I'm going into this detail because it's something I personally worked on. My guess is that if your implementor had used a naive native code compiler instead of an indirect interpreter, you would have seen a big increase in performance. Maybe an order of magnitude. But if he then employed the virtual stack technique, there's still a lot of improvement to be had.
I did not suggest than Xmos was less suitable than Prop. Quite frankly I don't know. I do know that Forth is ideally suited to microcontollers generally and can be implemeted on most in some form or another.
For me Forth is the ultimate low level language, but its comes down to what we get comfortable with.
The thing about distributed shared memory is that you just add a couple words (Jeff Fox just added one word) and you have extended memory and synchronization of multiple chips and extended I/O all at once. This seems in harmony with the philosophy of Forth. You have this new address space and bulk memory and I/O locations and mailboxes to other chips appear in this space. For my part, I'm just curious to see what it would all look like, never having seen an actual implementation. It seems like a good idea and Leon's board seems like good hardware to try it on. If I didn't already have 2 projects in the hopper, I might already be working on it. But then, I don't actually have an application for it, mundane MCU's are sufficient for my needs.
Leon, your post about Lisp is interesting. There is a public domain Smalltalk, Squeak, supported by Disney, that implements a windows GUI and debuggers and stuff, you just have to compile a virtual machine in C. But it's so darn big, it will probably be a while before it gets any interest from microcontroller people. I've never used Smalltalk seriously, but it is pretty fun as languages go.
The nice thing about Lisp is that it basically consists of a very small number of primitive operations, and the whole language can be based on those, although it won't be very efficient. Also, programming in Lisp is programming in machine language - that of a Lisp machine.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Comments
I already have a favorite terminal emulator on Mac/Linux, but it's a pain to chown my serial port back and forth between my actual OS and the VM -- so I do most of my console work within Windows. Thanks for the links!
Thinking Forth is pretty hardcore. I'd start with Starting Forth, which I think I've linked before, but I'll link again:
www.amresearch.com/starting_forth/
I'm looking forward to playing with Forth on the Propeller. Back in the 80s I used Forth to write a commercial MIDI voice librarian under DOS.
Which one is that?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows
links:
My band's website
Our album on the iTunes Music Store
This is not even remotely the right thread for such a question!
Double-check that you've got the latest FTDI USB-Serial driver. The Parallax USB-Serial Adapter should use the same driver, but it's worth checking. (There's a link to it off Parallax's product page.)
The driver itself is finicky; you might try rebooting (yeah, I know, it sucks) and then plugging in the Prop board first and seeing if it gets a node in /dev. (Oh, and make sure you have the power on. I keep forgetting that myself.)
Finally, it would definitely be worth checking to see if the Demo Board appears on any other machines, Macs or otherwise. There's always the possibility that your cable, board, or power supply is wonky.
As for terminal emulators, I'm a console kinda guy; I like minicom a lot.
I'll try your suggestions and see if I can get something to show up in /dev. Thanks!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows
links:
My band's website
Our album on the iTunes Music Store
As a british guy who remembers a home computer running forth - the jupiter ace the idea of running a full forth system on a propellor sounds cool but is this still in development?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
www.jacobsdesign.com.au/software/jdforth/jdforth.php
Prop forth comes with VT100 and EEprom support and Web supoort
JBForth, allows you·to run ·spin alongside Forth.·Passing data between spin and JBforth is a snack.·The professional version is a complete package·and is fast. The downside is that it is not Intereactive.
CB Forth is close to a tiny ANSI forth but the I/O is very flakey.·See the Cliff Hacks·web site for the latest version.
Not sure if Peter Jackie has done any thing·for the Prop, he's the only other forther that I know of.
·
There is little interest in Forth, which is unfortunate. . I have been working on my own tiny ANSI Forth Project based around the HX512 Xmem card and it is coming along, albeit rather slowly.
Ron
Post Edited (Ron Sutcliffe) : 11/24/2009 11:46:13 AM GMT
Ever since reading about the propellor I have been trying to work out a reason to buy one as I am not an electronics guy and this forth project looks like its reason enough! Maybe I will progress and open up a forest mims book and play with 555's etc.
Either way cool stuff to have a complete system on the Propellor
I think this is his latest public work on propellerforth.
Post Edited (Fred Hawkins) : 11/20/2009 3:22:02 AM GMT
his code.google downloads (last entry Jan 2008): http://code.google.com/p/spinforth/downloads/list
Of all of the propeller implementations of forth, I like this one best. Salsanci's source is well commented and useful.
PropForth is Salsanci's latest version of SpinForth. Its is now case sensative.
TCP/IP stack for Propforth was the latest work in progress. ( a couple of months ago)
http://code.google.com/p/propforth/wiki/GettingStarted
PropForth V2.5· 9/10/2009 is the latest version
Ron
Post Edited (Ron Sutcliffe) : 11/20/2009 10:32:41 AM GMT
-phar
There is extensive documentation.
If you don't like it you can always modify and recompile it. You would be stuck with then same core words if you are going to rebuild it using spinmaker and were to recompile it on the Prop.
PropForth provides for inline asm (PASM), an EEprom file system and it is multi threading using a time slicer. The P and R stacks reside in each active forth cog, this could limit the number of actve threads in a single cogbut there are seven cogs available to forth, one is used for I/O. I have considered moving the dictionary out of hub to my HX512 ram card, but considered it would be too slow.
I don't see Leon's pet chip being any more suited to Forth than the Prop. Chuck Moore's S40 chip is based on 18 bit core (3 cores or one cog). J fox and many other have Forth on a Chip. Dare I say that I had considered getting an X just to see how compact the compiled code was with XC against ICCP.
Cheers
I don't see why the XMOS chips are unsuited to Forth, it would run just as well as any other 32-bit Forth implementation on conventional processors. Exploiting the parallelism will require some work.
I've got some S40 chips (over £60 GBP each) but haven't done anything with them, partly because of the bust-up between Chuck Moore and Intellasys. How about a Propeller-S40 hybrid?
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Post Edited (Leon) : 11/23/2009 3:52:16 PM GMT
And I agree with Leon about the suitability of the XMOS chip to run Forth. I worked a little on register optimization in Forth 20 years ago (the last time I did any serious programming in Forth) and it's possible to get pretty much any cpu to run Forth efficiently.
-phar
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
My memory of the transputer was that it had a 4 element hardware stack you HAD to use (all alu ops used it) and didn't have good stack manipulation ops, so it wouldn't have been my dream target cpu. Once you filled the stack, you had to shuffle stuff around to push anything else on it and it was pretty inefficient. The best solution which occured to me was to do a scan of each basic block to determine how deep the stack would get at maximum and adjust code generation so you would just fill the hardware stack at that depth, but I never tried to code it, I was just looking at different cpu's to see how generally applicable the technique would be.
-phar
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Of course, I'm going into this detail because it's something I personally worked on. My guess is that if your implementor had used a naive native code compiler instead of an indirect interpreter, you would have seen a big increase in performance. Maybe an order of magnitude. But if he then employed the virtual stack technique, there's still a lot of improvement to be had.
-phar
For me Forth is the ultimate low level language, but its comes down to what we get comfortable with.
Ron
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
-phar
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM