Perhaps CP/M is a lousy file system. However it was about the best you could do on an 8 bit machine with 64K max memory. From that perspective it's a minor wonder. Perhaps there is something to learn from that code. All nice Z80 assembler as it is.
...others die from ignorance of their value.
Odd you should say that. I have just been following the Berkley computer science course CS 61A. It presents all the fundamental paradigms of programming using Scheme (a dialect of Lisp) for the examples and exercises. The point of the course is not to teach Scheme but the big CS ideas. What an eye opener. It's about the first time I have looked at a non C/C++/Pascal/etc language. You can do everything in Scheme: Functional programming, object oriented programming, class based inheritance, prototype based inheritance. It has first class functions, closures, the lot. It runs rings around C++ for features of an object oriented language.
For sheer elegance and expressiveness Scheme like languages should be known to all. If only I'd known before. It gives you a whole different perspective on computing.
Saddly Lisp, Scheme etc are being washed away by Java and such, they are dying from ignorance of their value.
ASIDE: Turns out JavaScript has all the goodies of Lisp/Scheme but no one really notice till quite recently, they did not recognize what they were dealing with having never been exposed to it before.
Don't be put off off by the "Functional Programming" title of the first lecture, there is everything in that series.
Forth, I don't know, so far I have yet to find any big ideas in there worth salvaging. Still looking mind.
What does Forth have that C and Unix does not? Romance.....
Ha, what? C has all the romance of history. Like Rome, Venice, the Pyramids or Stone Henge. If romance is what you want have a listen to this: http://www.youtube.com/watch?v=1S1fISh-pag
It's a good idea to focus on future thinking with Forth on this new chip. It's going to be more about the future, and future applications of Forth, in new ways, that no one saw in the past. Exactly the same applies to the Propeller chip. It also seems many have tunnel vision on their fav language. (me included) If you like A, then don't shoot down anyone with B. This is a vast world with much variety and variation with all elements of flavor and color that have importance. Indeed the GA chip has only one language. It could be a matter of time for other support systems to be developed, or this is it. In the mean time, we can grab a Propeller and choose any of 247 of your favorite languages and variations, including several Forth versions.
Things Forth-Related for the Propeller Chip PropFORTH by Sal Sanci PROPELLERFORTH by CLIFFE BIFFLE PROPELLERFORTH JDFORTH FORTH to SPIN Compiler by Carl Jacobs, Not open source SPIN FORTH by SAL SANCI Under General Public License Forth - UNIFORTH Forth 83 Version 2.1.0 TACHYON FORTH by Peter Jakacki COG Forth by Peter Jakacki Tachyon EMIC2 by Brian Riley Tachyon EMIC2 2 by Brian Riley Tachyon Ping))) by Brian Riley PROPFORTH 2.7 by Sal Sanci PROPFORTH 3.2 by Sal Sanci PROPFORTH 4.0 by Sal Sanci PROPFORTH 4.5 by Sal Sanci PROPFORTH 5.0 by Sal Sanci pfth ANS Forth Interpreter for the Prop by Dave Hein Tiny FORTH Text Editor by Ron Sutcliffe
@Humanoido
It seems your lists are a bit deceptive. At this point we simpily have two Forths that recently affirmed they will go on to produce something for Propeller 2. The others are more historic and may not provide as much usefulness.
PropForth and TacyonForth.
Much of the mention of version numbers or the early efforts of Sal Sanci and Peter Jakacki are work that has been left behind as efforts have evolved. Brian Riley tends to be a contributor to added features in Tackyon, Dr. Braino and others contribute to PropForth. So Sal Sanci and Peter Jakacki are the true leaders in Forth on the Propeller.
For me personally, the GA144 and ArrayForth is merely a means to take a good look at what Charles Moore thinks is most important to Forth in 2013. Both Sal and Peter have modified Forth in substantial ways to optimize it on the Propeller.... for better or worse? i dunno?
@Heater
I suppose that I am blinded by my own curiosity about Forth. As you point out above, there are other excellent study models of ignored languages in Computer Science. This doesn't surprise me as there is a tremendous amount of commercial hype and rampant ambition that has overshadowed calmer, more informed voices in computing.
At least I am willing to clearly admit my curiosities and biases, other claim they are more experienced, better informed, and the final authority.
Mainly my attraction to Forth is sustained by it being interactive, which is immediately gratifying to me. C may forever by Lord and King of the computer world, but it is nice to poke around with code and to see immediate results rather than write, compile, load, test, and try and again. This is not new information, I keep repeating it.
~~~~~~~~~~~~~~
I have recently been spending a lot of time on Charlie Moore's blogs at the ArrayForth site. And awful lot is about living in the high Sierra mountains, with ramblings about the Ga144 and earlier chips. My impressions are that these entries are getting fewer and fewer... but I enjoy reading them as I do learn something about Forth as much as I see a guy that just loves the great outdoors.
If you need Forth for a Project right away, PropForth and TacyonForth on the Propeller are very viable.
Mainly my attraction to Forth is sustained by it being interactive,...
Oh, man, you are going to love Scheme. Sadly it needs a too much of a run time to run on the Prop.
Oh, don't forget Perl, Python, JavaScript, Bash and many others are interactive as well. Of course all too big for the Prop as well. Which brings us back to BASIC perhaps, as well as Forth.
For sheer elegance and expressiveness Scheme like languages should be known to all. If only I'd known before. It gives you a whole different perspective on computing.
Saddly Lisp, Scheme etc are being washed away by Java and such, they are dying from ignorance of their value.
Mainly my attraction to Forth is sustained by it being interactive, which is immediately gratifying to me. C may forever by Lord and King of the computer world, but it is nice to poke around with code and to see immediate results rather than write, compile, load, test, and try and again. This is not new information, I keep repeating it.
This is Forth's biggest advantage in my view (not that there aren't other possible advantages): It jibes with how the software development process -- which is in the end an iterative one, no matter how much we think/wish/want otherwise -- actually works.
PS - Interesting discussion of the merits of Forth and Lisp; they may not be quite as different as they first appear: http://c2.com/cgi/wiki?ForthVsLisp
...Ha, what? C has all the romance of history. Like Rome, Venice, the Pyramids or Stone Henge. If romance is what you want have a listen to this: http://www.youtube.com/watch?v=1S1fISh-pag
Ugh. I can't throw up fast enough listening to that
The interactive aspect of Forth may be its biggest advantage, but it's weak in almost every other area. I've programmed in C, Forth, Spin, and a few other high level languages, and Forth is missing many important features that are in other languages. Features that I find important are data structures, objects, local variables, and portability. Some of these features have been implemented in Forth in various ways, but the lack of acceptance of a standard Forth is one of the biggest problems with Forth. The Forth language doesn't even have a standard library that a programmer can link to.
When I need interactively, I can program the functions I need in C, and then try things in an interactive manner at runtime. So Forth's interactive feature is really not as valuable as some people claim.
Features that I find important are data structures, objects, local variables, and portability. Some of these features have been implemented in Forth in various ways, but the lack of acceptance of a standard Forth is one of the biggest problems with Forth. The Forth language doesn't even have a standard library that a programmer can link to.
I guess that's why Forth is such a love-it-or-hate-it thing for many people. Forth can be pretty much anything you want; only you're left to your own devices to figure out what and how. Some don't like that at all, some like it very much. (Although, you can have a bit more structure and support if you ante up - http://www.forth.com/embedded/swiftx-embedded-systems-3.html .)
When I need interactively, I can program the functions I need in C, and then try things in an interactive manner at runtime. So Forth's interactive feature is really not as valuable as some people claim.
Yes, one can, but it's never quite as easy or natural at it is with Forth or some other interpretive language. But yeah, does the rest measure up -- in Forth's case? -- seem a fair enough question that many answer in the negative. (Myself, I'm still riding the fence.)
at the command line and get a nice result. In Scheme I might write:
( + 1 2 3 4)
In Python it's:
1 + 2 + 3 + 4
All with the same satisfying result. Note that Scheme is much nicer here.
However, when it comes to making more complex multi-line functions you find that one typo or logic error and in all cases boom! you have to define the whole thing again.
How much easier it is to write your function in Spin, or even C, hit F10 and have it download and run. If it fails just go and edit what you have and hit F10 again.
Taking a break from all the software debate, I have suddenly realized that not only is the 1.8 volt power requirement of the Ga144 a great big pain in the neck, but I see that I overlooked the fact that the Propeller 2 has dodged the problem by having a 1.8 volt core with optional 1.8 or 3.3 volt i/o.
All roads seem to lead back to Parallax as being easier to learn and deploy.
BTW, Forth tends to be weak on floating point maths. But the trade off is that you can just about tweak anything you want rather directly.
But the real payoff of using Forth is that you become recognized as a misantrhopic uber-greek that makes computers do mysterious things in mysterious ways with unreadable code.
But oh my God, seems some people have the idea of combining features from Forth and Lisp in a new language. "Joy" was it. Great, take the elegance of both (Or ilegibility depending how you look at it) and mangle them together into some hideous monster.
I think my brain would collapse under the strain. I might call a halt to learning YAFL (work it out) and retreat to nothing but C. Like this guy: http://www.youtube.com/watch?v=i2fhNVQPb5I
I think my brain would collapse under the strain. I might call a halt to learning YAFL (work it out) and retreat to nothing but C. Like this guy: http://www.youtube.com/watch?v=i2fhNVQPb5I
Okay, that is funny. Makes some pretty good points too, in a rather wry way.
Heater: You should get an ARM board and load Armpit Scheme on it. In addition to the many things you seem already to like about Scheme, you might find yourself singing a different tune about the advantages of having a truly interactive environment running on a piece of hardware.
In fact, I will take my own suggestion and do this myself sometime soon!
I had a look at ARMPIT and I was allready thinking along those lines. In my case though the ARM would have to be a Raspberry Pi board or similar running Linux as I have a pile of those around. At that point though we are not on the metal but running Linux so actually any Scheme system would do. There seem to be many of them to choose from.
However, aside from the YAFL problem I also have a severe case of YAFP syndrome. I promised myself no more new projects until the old ones were eiher completed, archived properly or deleted totally. Even that is a project in itself:)
In the meantime I'm sure I will be playing with Scheme interactively on my PC. I already have "Simply Scheme" by Brian Harvey to be getting on with.
KC_Rob,
However, aside from the YAFL problem I also have a severe case of YAFP syndrome. I promised myself no more new projects until the old ones were eiher completed, archived properly or deleted totally. Even that is a project in itself:)
Yes, I know the YAFP syndrome all too well (except in my case maybe it should be called YAFD, since as often as not they are distractions from what I should be working on, more so than actual projects). Nonetheless, I probably will pick up an ARM board sometime and give Armpit Scheme a workout; dev boards can be had cheap enough, and as yet I'm not too heavily burdened with ARM hardware.
In the mean time there is this wonderful thing to while away odd moments http://www.biwascheme.org/
A Scheme system written in JavaScript usable on WEB pages or server side under Node.js.
Thus combining my two current obsessions with the third, Scheme.
I have to get on with my plans to have all this interact with my Propellers or I'll become permanently off topic for this forum:)
.....
BTW, Forth tends to be weak on floating point maths. ...
No, that's the chip. Any chip that supports float in hardware can have float in hardware support in forth. Chips that don't have float in hardware need float in software, and it will be slow. In either case, it pays to understand the math to the point that one can figure out what specifically needs to be done, and why.
It is the Monday after Chinese New Years and there was a little green card in my mail box saying that the Post Office attempted delivery of my GA144. So now I have to seek out where it is.
The question of how to deploy floating point has been a persistent debate in Forth.
Prof. Braino seems to think that the microprocessor should provide floating point ability in hardware, not the Forth. That seems to be more of a point of view issue as C has long provided a floating point library. Most microcontrollers provide binary add, subtract, multiply, and divide.. so software takes up the slack. Some have math coprocessors, others have added maths ability.
So unlike C that provides a Floating point library, one generally has to install a math coprocessor or create a floating point library specific to the given processors. Yes, it would seem to be Forth is missing something that C has in portable code.
The GA144 does have good examples of 36 bit maths, but in signed and unsigned integer. And it has the carry bit that is required to go even farther.. 72bit or 144 bit maths.
Floating point tends to be a expectation from the evolution of the electric calculator with its display to 12 places... a human interface issue. It is most useful in conversion to units that the user and general public commonly understand. One can always do the conversions of data and units at the tail end of a process with a spreadsheet in a desktop computer or in a user interface in C. After all, that is where the human sees the results.
Here is an excerpt that supports what I am trying to say. A lot of traditionalist do not provide floating point for specialized Forths for specific microcontrollers.... too slow.
"12. Floating point arithmetic
Although Forth at one time eschewed floating point arithmetic (because in the era before math co-processors integer arithmetic was 3x faster), in recent years a standard set of word names has been agreed upon. This permits the exchange of programs that will operate correctly on any computer, as well as the development of a Scientific Subroutine Library in Forth (FSL). Although the ANS Standard does not require a separate stack for floating point numbers, most programmers who use Forth for numer- ical analysis employ a separate floating point stack; and most of the routines in the FSL assume such. We shall do so here as well.
The floating point operators have the following names and perform the actions indicated in the accompanying stack comments: F@ ( adr --) ( f: -- x)
F! ( adr --) ( f: x --)
F+ ( f: x y -- x+y) F- ( f: x y -- x-y)
F* ( f: x y -- x*y)
F/ ( f: x y -- x/y)
FEXP ( f: x -- e^x)
FLN ( f: x -- ln[x])
FSQRT ( f: x -- x^0.5)
Additional operators, functions, trigonometric functions, etc. can be found in the FLOATING and FLOATING EXT wordsets. (See dpANS6— available in HTML, PostScript and MS Word formats. The HTML version can be accessed from this homepage.) "... A Beginner's Guide to Forth by J.V. Noble.
Well, the GA144 should be at my local post office for me to pick up today or tomorrow. I had to call yesterday and request they stop home delivery attempts and shift to a will call.
In the meantime, I visited my local electronic shops to try to get some 1.8 volt logic and a 1.8 volt SPI Flash Ram. There is nothing available for 1.8 Volt locally. I will have to import anything I add to the GA144 besides the initial reset circuit and a MOSfet RS-232 interface.
The delay in delivery has been very worthwhile as I have actually read and reread the literature that is available many times and it does appear that I can have the Schmartboard boot via an RS232 port and the ArrayForth will allow me to explore quite a bit. But without an SPI Flash or other means of storage, I am tied to the IDE until that is resolved. That may not be bad, as it will make me learn more about the IDE.
This project does not merely require learning Forth. It is something like the following:
a. Learn Forth as presented in "Starting Forth"
b. Learn ColorForth
c. Learn ArrayForth as a sub-set of ColorForth for the IDE to Ga144
d. Learn either eForth or polyForth or both as installed interpreters on the GA144
e. Learn to adapt the core of eForth to ANSforth
After e., one has a running Forth interpreter in the Ga144. You only get polyForth if you buy the $450USD kit. eForth is free, but you will earn it in learning to create and install an eForth boot ROM.
One thing I have run into is that it appears the i/o is not a 1 to 1 relationship. The nodes might be able to actually simultaneously send to 3 or even 4 adjacent nodes at the same time.
I am in a bit of a muddle as this matrix has both parallel and serial processor capability. Parallel processing is well recognized as enhancing through put, but I can't quite see how serial processing does much. There are certainly 144 processors, but 22 are already robbed from the parallel processing by being i/o, and more may be shut out by their positions in the matrix.
So the 'big number' of 144 becomes something far less. It is more a question of how much parallel does the task need. I am feeling that I'd be lucky to get 50%.
My gut feeling is that I'd be much happier to get a true eForth working on a Propeller 1 and/or Propeller 2. After all, that would bypass a lot of steps and lead to full ANSforth potential. Plus, the 3.3V i/o makes life a lot simpler.
Well, the GA144 should be at my local post office for me to pick up today or tomorrow. I had to call yesterday and request they stop home delivery attempts and shift to a will call.
I am in a bit of a muddle as this matrix has both parallel and serial processor capability. Parallel processing is well recognized as enhancing through put, but I can't quite see how serial processing does much. There are certainly 144 processors, but 22 are already robbed from the parallel processing by being i/o, and more may be shut out by their positions in the matrix.
So the 'big number' of 144 becomes something far less. It is more a question of how much parallel does the task need. I am feeling that I'd be lucky to get 50%.
We're going crazy, waiting for your chip! Go out there right now and pick it up!
How will you solder the chip, which has no legs and is in QFN chip form factor, to the Schmartboard? I guess you have special soldering melt wash equipment.
Run both parallel and serial because they both have their uses depending on the application. For example, parallel is good for updating all Propeller chips at the same time or loading in the same program to all chips. Serial can stream from specific chips, update specific chips, provide data to specific chips and communicate from specific chips to chips, where the entire collective would not interested.
It's very worrisome and a concern that the GA chip is already going down in the number of usable true parallel processors. The designer should have taken this into consideration. Let's hope one can find other use-advantages in the unusual design or in a newer version chip. So if it goes down to 50% usable, that's only 72. I have a GPU AMD board that's ten times more and each processor is full state. The greatest flexibility of course comes from wiring up a bunch of cpu chips. I mean if you take 144 props, that's 1,152 fully usable parallel risc processors.
It will be highly interesting to see what you find and discover. I'm wondering now if you can reach those "other" processors with code, and get all thinking at the same time. Can Forth do it? If so, it could be used as a pure thought processing chip along with Propellers. The Props can provide all the I/O. Ten of these would be a good start but we really need to convince the designer to go with 1000x144 to get to the next level. Have you come across any information for programming the chip at a lower level without Forth?
It seems your lists are a bit deceptive. At this point we simpily have two Forths...
There's nothing deceptive about the list of languages and their versions for the Propeller chip. Everything is stated at face value.
Without conditions (Forths that recently affirmed they will go on to produce something for Propeller 2), we see more than two Forths and we include important developers like Dave Hein and others.
Unique versions of a single language often fit specific applications and fit smaller memory sizes and can be very useful.
Various language code projects are academically useful.
Various versions can show different coding techniques for use, reference, and study.
Different versions may also support different devices.
Retro languages are useful even if they are not being supported today.
We never know when someone will pick up an existing language base and carry the torch, and create new versions.
It's important to provide a convenient Propeller chip list or repository source of languages for applications as needed.
Clearly Sal and Peter have made great language contributions of a positive productive nature for the Propeller chip.
Maybe you have no use for a program language version - however, others find it highly useful.
One may be pinned down to only one language with another chip, however the Propeller may be far more versatile in language options.
@Humanoido
It seems your lists are a bit deceptive. At this point we simpily have two Forths that recently affirmed they will go on to produce something for Propeller 2. The others are more historic and may not provide as much usefulness.
PropForth and TacyonForth.
Actually, Dave Hein's pfth is already running on the P2. I ported it myself. :-)
However, I guess I don't know that Dave intends to support it on P2. I haven't been following the Forth threads very carefully.
Actually, Dave Hein's pfth is already running on the P2. I ported it myself. :-)
However, I guess I don't know that Dave intends to support it on P2. I haven't been following the Forth threads very carefully.
Thanks for the port. The P2, which is not even out yet, already has at least five languages that run on it.
The lists of Propeller programing languages do not clearly reflect actively supported languages, they are more historic than actual current status. That would require much more maintenance to keep current. It is a bit of a nuisance for new users to have to sort out for themselves what is currently useful from what once was.
There is a very good reason that the British have their beloved 'short list'. Long lists are rather daunting and confounding... a bit of a waste of time. Consider that www.distrowatch.com for Linux provides a rating based on the rate of downloads to indicate what is most active and most used.
I am happy to hear that pfth has already been migrated over to the Propeller 2. It is an indicator of how easy it will be for all of us to transfer our Propeller 1 knowledge to the Propeller 2.
I did pick up the Ga144. OMG, this is tiny and I intend to attempt to solder it according to Schmartboard proceedures ... the right flux and a soldering iron with a tip of 0.4mm or less diameter at 750 degrees F.
There really is no point in supporting all the i/o until I have a good RS232 boot port active and confirrn the chip is in good working order. ArrayForth provides the interface and test code. Beside, I have to import all the level shifters and support chips and the shipping costs are going to likely double the cost and create delays. At this point, if I really like the GA144, I might just opt for the GreenArray's development board to go that far as the construction of an elaborate Schmartboard solution seems of dubious merit.
I do have to confess. I didn't just buy one GA144, I bought two. So if the first attempt is more educational than successful, I have a way to move ahead.
I started looking at seriously creating my own version of eForth for the Propeller and settling for that to be a really adequate Forth solution. I am being forces into sizes that are minuscule and voltages that that are also minuscule. Using the GA144 might require a good scope for adequate support as signals of 666Mhz are supposedly possible.
Oops, no I did not. And the GA144 is already soldered to the Schmartboard via their generalized procedure with one difference.
Rather than solder one side at a time, I first soldered opposing diagonal corners in order to secure the chip from shifting in any manner. I used a bottle of liquid flux that is water soluble, a brand new tip for my 30 watt cheapo soldering iron, and held the board in a machinist vise that is intending for holding work on a drill press (nice and heavy and secure without having to bolt to a bench). I did NOT add any solder to the top of the board as the slots have enough provided by Schmartboard. I did add solder to the bottom side ground hole after flooding first with liquid flux to get a good ground.
Use a very brightly lit work area.
Optically, I have a pair of stereo optics that are 10x and maybe 20x in the higher mode, a few magnifying glasses, and a 20x jeweler's loupe. The GA144 seems adequately soldered. I waited until after 4 passes on the top to solder the ground through the hole in the bottom. I now have to do some continuity testing - adjacent inputs for possible solder bridges, all the ground lines to confirm a complete ground, all the voltage lines to confirm they are complete, and certainly the reset line and the boot RS232 i/o. That will likely take longer than the initial soldering, but I feel it is a must do in order to not waste time later with mysterious and potentially disastrous problems.
Only after all that is done will I complete assembly of the power bus, attached the by-pass capacitors, attach appropriate pull-downs and pull-ups to boot i/o's that need to be ignored, and construct a daughter board with reset and Rs232 interface. I do have a 1.8 volt power supply that I purchased from Schmartboard.
The Schmartboard is interesting as this board actually has slots milled into the board to hold solder and to enhance positioning of the little feet that most board have. But the GA144 does not have these. So I relied on extremely careful verification of position before I started soldering. The device was already taped with a yellow piece of narrow tape running diagonally to the board and the position happened to be 100%. But I would not rely on that... must verify. We will just have to see how the testing and further construction pan out.
If something is really wrong, I have a second kit. But I'd much rather get this one right the first time. Soldering by pushing the solder in troughs is a bit tricky. The iron should be very hot, lots of flux fluid should be used, and one needs to acquire a feel for not pushing too hard. The iron tip should just slide, not dig in. And I found my cheapo soldering tip would wobble as it is held in with two opposing screws. One might prefer a better iron to eliminate the wobble. I did consider buying a different size iron for this project, but choices vary ... 150watt (likely a disaster of too much heat), 40 watt, 30 watt, 20 watt, 15 watt. The specs said I should have 450 degrees F, but I have no idea what the temperature was. When it seemed too cold, I just let the iron sit for 5 minutes to get really hot again.
OMG!!! lucky I caught this. It seems the normal VOM might put more voltage across the pins than is acceptable. I will have to DIY a meter and a 1.5V cell. And I should be very careful not to reverse polarity.
I don't usually test soldering with chips installed on a board, but there is no other way to do so with this one. I happen to have a 10ma meter, so the DIP continuity meter should be fine. Another alternative might just be an LED that works at 1.8 volts or less.
Comments
Perhaps CP/M is a lousy file system. However it was about the best you could do on an 8 bit machine with 64K max memory. From that perspective it's a minor wonder. Perhaps there is something to learn from that code. All nice Z80 assembler as it is. Odd you should say that. I have just been following the Berkley computer science course CS 61A. It presents all the fundamental paradigms of programming using Scheme (a dialect of Lisp) for the examples and exercises. The point of the course is not to teach Scheme but the big CS ideas. What an eye opener. It's about the first time I have looked at a non C/C++/Pascal/etc language. You can do everything in Scheme: Functional programming, object oriented programming, class based inheritance, prototype based inheritance. It has first class functions, closures, the lot. It runs rings around C++ for features of an object oriented language.
For sheer elegance and expressiveness Scheme like languages should be known to all. If only I'd known before. It gives you a whole different perspective on computing.
Saddly Lisp, Scheme etc are being washed away by Java and such, they are dying from ignorance of their value.
ASIDE: Turns out JavaScript has all the goodies of Lisp/Scheme but no one really notice till quite recently, they did not recognize what they were dealing with having never been exposed to it before.
I serously recommend the Berkley CS61A course to anyone who wants to program, it's all on YouTube and the lecturer Brian Harvey is just great. http://www.youtube.com/watch?v=zmYqShvVDh4&list=PLDCCF73E09DB127FD
Don't be put off off by the "Functional Programming" title of the first lecture, there is everything in that series.
Forth, I don't know, so far I have yet to find any big ideas in there worth salvaging. Still looking mind.
Ha, what? C has all the romance of history. Like Rome, Venice, the Pyramids or Stone Henge. If romance is what you want have a listen to this: http://www.youtube.com/watch?v=1S1fISh-pag
Things Forth-Related for the Propeller Chip
PropFORTH by Sal Sanci
PROPELLERFORTH by CLIFFE BIFFLE
PROPELLERFORTH
JDFORTH FORTH to SPIN Compiler by Carl Jacobs, Not open source
SPIN FORTH by SAL SANCI Under General Public License
Forth - UNIFORTH
Forth 83 Version 2.1.0
TACHYON FORTH by Peter Jakacki
COG Forth by Peter Jakacki
Tachyon EMIC2 by Brian Riley
Tachyon EMIC2 2 by Brian Riley
Tachyon Ping))) by Brian Riley
PROPFORTH 2.7 by Sal Sanci
PROPFORTH 3.2 by Sal Sanci
PROPFORTH 4.0 by Sal Sanci
PROPFORTH 4.5 by Sal Sanci
PROPFORTH 5.0 by Sal Sanci
pfth ANS Forth Interpreter for the Prop by Dave Hein
Tiny FORTH Text Editor by Ron Sutcliffe
For links and more information
http://humanoidolabs.blogspot.com/2012/03/ultimate-list-of-big-brain-languages.html
It seems your lists are a bit deceptive. At this point we simpily have two Forths that recently affirmed they will go on to produce something for Propeller 2. The others are more historic and may not provide as much usefulness.
PropForth and TacyonForth.
Much of the mention of version numbers or the early efforts of Sal Sanci and Peter Jakacki are work that has been left behind as efforts have evolved. Brian Riley tends to be a contributor to added features in Tackyon, Dr. Braino and others contribute to PropForth. So Sal Sanci and Peter Jakacki are the true leaders in Forth on the Propeller.
For me personally, the GA144 and ArrayForth is merely a means to take a good look at what Charles Moore thinks is most important to Forth in 2013. Both Sal and Peter have modified Forth in substantial ways to optimize it on the Propeller.... for better or worse? i dunno?
@Heater
I suppose that I am blinded by my own curiosity about Forth. As you point out above, there are other excellent study models of ignored languages in Computer Science. This doesn't surprise me as there is a tremendous amount of commercial hype and rampant ambition that has overshadowed calmer, more informed voices in computing.
At least I am willing to clearly admit my curiosities and biases, other claim they are more experienced, better informed, and the final authority.
Mainly my attraction to Forth is sustained by it being interactive, which is immediately gratifying to me. C may forever by Lord and King of the computer world, but it is nice to poke around with code and to see immediate results rather than write, compile, load, test, and try and again. This is not new information, I keep repeating it.
~~~~~~~~~~~~~~
I have recently been spending a lot of time on Charlie Moore's blogs at the ArrayForth site. And awful lot is about living in the high Sierra mountains, with ramblings about the Ga144 and earlier chips. My impressions are that these entries are getting fewer and fewer... but I enjoy reading them as I do learn something about Forth as much as I see a guy that just loves the great outdoors.
If you need Forth for a Project right away, PropForth and TacyonForth on the Propeller are very viable.
Oh, don't forget Perl, Python, JavaScript, Bash and many others are interactive as well. Of course all too big for the Prop as well. Which brings us back to BASIC perhaps, as well as Forth.
PS - Interesting discussion of the merits of Forth and Lisp; they may not be quite as different as they first appear: http://c2.com/cgi/wiki?ForthVsLisp
Ugh. I can't throw up fast enough listening to that
This is entertainment: http://www.youtube.com/watch?v=_VJ8aaCgYN0
When I need interactively, I can program the functions I need in C, and then try things in an interactive manner at runtime. So Forth's interactive feature is really not as valuable as some people claim.
Yes, one can, but it's never quite as easy or natural at it is with Forth or some other interpretive language. But yeah, does the rest measure up -- in Forth's case? -- seem a fair enough question that many answer in the negative. (Myself, I'm still riding the fence.)
In Forth I might write:
1 2 3 4 + + + .
at the command line and get a nice result. In Scheme I might write:
( + 1 2 3 4)
In Python it's:
1 + 2 + 3 + 4
All with the same satisfying result. Note that Scheme is much nicer here.
However, when it comes to making more complex multi-line functions you find that one typo or logic error and in all cases boom! you have to define the whole thing again.
How much easier it is to write your function in Spin, or even C, hit F10 and have it download and run. If it fails just go and edit what you have and hit F10 again.
Yes, the C song is kind of pukey. Let's stick to historic C with all the majesty of Stone Henge.
I know that vid, brilliant, I also like this one which I have linked to somewhere here before http://www.youtube.com/watch?v=FJ7QsEytQq4
Not really, not more than most other languages I am familiar with.
Since I started genning up on Scheme and Lisp like languages I have come to realize with those you really can make them pretty much anything you want.
All roads seem to lead back to Parallax as being easier to learn and deploy.
BTW, Forth tends to be weak on floating point maths. But the trade off is that you can just about tweak anything you want rather directly.
But the real payoff of using Forth is that you become recognized as a misantrhopic uber-greek that makes computers do mysterious things in mysterious ways with unreadable code.
Some interesting discussion in those links.
But oh my God, seems some people have the idea of combining features from Forth and Lisp in a new language. "Joy" was it. Great, take the elegance of both (Or ilegibility depending how you look at it) and mangle them together into some hideous monster.
I think my brain would collapse under the strain. I might call a halt to learning YAFL (work it out) and retreat to nothing but C. Like this guy: http://www.youtube.com/watch?v=i2fhNVQPb5I
In fact, I will take my own suggestion and do this myself sometime soon!
I had a look at ARMPIT and I was allready thinking along those lines. In my case though the ARM would have to be a Raspberry Pi board or similar running Linux as I have a pile of those around. At that point though we are not on the metal but running Linux so actually any Scheme system would do. There seem to be many of them to choose from.
However, aside from the YAFL problem I also have a severe case of YAFP syndrome. I promised myself no more new projects until the old ones were eiher completed, archived properly or deleted totally. Even that is a project in itself:)
In the meantime I'm sure I will be playing with Scheme interactively on my PC. I already have "Simply Scheme" by Brian Harvey to be getting on with.
In the mean time there is this wonderful thing to while away odd moments http://www.biwascheme.org/
A Scheme system written in JavaScript usable on WEB pages or server side under Node.js.
Thus combining my two current obsessions with the third, Scheme.
I have to get on with my plans to have all this interact with my Propellers or I'll become permanently off topic for this forum:)
P.S. For Forth heads there are many Forths on the WEB, like this one: http://solidcoding.blogspot.fi/2008/12/wforth-javascript-forth-interpreter.html
No, that's the chip. Any chip that supports float in hardware can have float in hardware support in forth. Chips that don't have float in hardware need float in software, and it will be slow. In either case, it pays to understand the math to the point that one can figure out what specifically needs to be done, and why.
The question of how to deploy floating point has been a persistent debate in Forth.
Prof. Braino seems to think that the microprocessor should provide floating point ability in hardware, not the Forth. That seems to be more of a point of view issue as C has long provided a floating point library. Most microcontrollers provide binary add, subtract, multiply, and divide.. so software takes up the slack. Some have math coprocessors, others have added maths ability.
So unlike C that provides a Floating point library, one generally has to install a math coprocessor or create a floating point library specific to the given processors. Yes, it would seem to be Forth is missing something that C has in portable code.
The GA144 does have good examples of 36 bit maths, but in signed and unsigned integer. And it has the carry bit that is required to go even farther.. 72bit or 144 bit maths.
Floating point tends to be a expectation from the evolution of the electric calculator with its display to 12 places... a human interface issue. It is most useful in conversion to units that the user and general public commonly understand. One can always do the conversions of data and units at the tail end of a process with a spreadsheet in a desktop computer or in a user interface in C. After all, that is where the human sees the results.
Here is an excerpt that supports what I am trying to say. A lot of traditionalist do not provide floating point for specialized Forths for specific microcontrollers.... too slow.
"12. Floating point arithmetic
Although Forth at one time eschewed floating point arithmetic (because in the era before math co-processors integer arithmetic was 3x faster), in recent years a standard set of word names has been agreed upon. This permits the exchange of programs that will operate correctly on any computer, as well as the development of a Scientific Subroutine Library in Forth (FSL). Although the ANS Standard does not require a separate stack for floating point numbers, most programmers who use Forth for numer- ical analysis employ a separate floating point stack; and most of the routines in the FSL assume such. We shall do so here as well.
The floating point operators have the following names and perform the actions indicated in the accompanying stack comments:
F@ ( adr --) ( f: -- x)
F! ( adr --) ( f: x --)
F+ ( f: x y -- x+y)
F- ( f: x y -- x-y)
F* ( f: x y -- x*y)
F/ ( f: x y -- x/y)
FEXP ( f: x -- e^x)
FLN ( f: x -- ln[x])
FSQRT ( f: x -- x^0.5)
Additional operators, functions, trigonometric functions, etc. can be found in the FLOATING and FLOATING EXT wordsets. (See dpANS6— available in HTML, PostScript and MS Word formats. The HTML version can be accessed from this homepage.) "... A Beginner's Guide to Forth by J.V. Noble.
In the meantime, I visited my local electronic shops to try to get some 1.8 volt logic and a 1.8 volt SPI Flash Ram. There is nothing available for 1.8 Volt locally. I will have to import anything I add to the GA144 besides the initial reset circuit and a MOSfet RS-232 interface.
The delay in delivery has been very worthwhile as I have actually read and reread the literature that is available many times and it does appear that I can have the Schmartboard boot via an RS232 port and the ArrayForth will allow me to explore quite a bit. But without an SPI Flash or other means of storage, I am tied to the IDE until that is resolved. That may not be bad, as it will make me learn more about the IDE.
This project does not merely require learning Forth. It is something like the following:
a. Learn Forth as presented in "Starting Forth"
b. Learn ColorForth
c. Learn ArrayForth as a sub-set of ColorForth for the IDE to Ga144
d. Learn either eForth or polyForth or both as installed interpreters on the GA144
e. Learn to adapt the core of eForth to ANSforth
After e., one has a running Forth interpreter in the Ga144. You only get polyForth if you buy the $450USD kit. eForth is free, but you will earn it in learning to create and install an eForth boot ROM.
One thing I have run into is that it appears the i/o is not a 1 to 1 relationship. The nodes might be able to actually simultaneously send to 3 or even 4 adjacent nodes at the same time.
I am in a bit of a muddle as this matrix has both parallel and serial processor capability. Parallel processing is well recognized as enhancing through put, but I can't quite see how serial processing does much. There are certainly 144 processors, but 22 are already robbed from the parallel processing by being i/o, and more may be shut out by their positions in the matrix.
So the 'big number' of 144 becomes something far less. It is more a question of how much parallel does the task need. I am feeling that I'd be lucky to get 50%.
My gut feeling is that I'd be much happier to get a true eForth working on a Propeller 1 and/or Propeller 2. After all, that would bypass a lot of steps and lead to full ANSforth potential. Plus, the 3.3V i/o makes life a lot simpler.
We're going crazy, waiting for your chip! Go out there right now and pick it up!
How will you solder the chip, which has no legs and is in QFN chip form factor, to the Schmartboard? I guess you have special soldering melt wash equipment.
Run both parallel and serial because they both have their uses depending on the application. For example, parallel is good for updating all Propeller chips at the same time or loading in the same program to all chips. Serial can stream from specific chips, update specific chips, provide data to specific chips and communicate from specific chips to chips, where the entire collective would not interested.
It's very worrisome and a concern that the GA chip is already going down in the number of usable true parallel processors. The designer should have taken this into consideration. Let's hope one can find other use-advantages in the unusual design or in a newer version chip. So if it goes down to 50% usable, that's only 72. I have a GPU AMD board that's ten times more and each processor is full state. The greatest flexibility of course comes from wiring up a bunch of cpu chips. I mean if you take 144 props, that's 1,152 fully usable parallel risc processors.
It will be highly interesting to see what you find and discover. I'm wondering now if you can reach those "other" processors with code, and get all thinking at the same time. Can Forth do it? If so, it could be used as a pure thought processing chip along with Propellers. The Props can provide all the I/O. Ten of these would be a good start but we really need to convince the designer to go with 1000x144 to get to the next level. Have you come across any information for programming the chip at a lower level without Forth?
There's nothing deceptive about the list of languages and their versions for the Propeller chip. Everything is stated at face value.
Without conditions (Forths that recently affirmed they will go on to produce something for Propeller 2), we see more than two Forths and we include important developers like Dave Hein and others.
Unique versions of a single language often fit specific applications and fit smaller memory sizes and can be very useful.
Various language code projects are academically useful.
Various versions can show different coding techniques for use, reference, and study.
Different versions may also support different devices.
Retro languages are useful even if they are not being supported today.
We never know when someone will pick up an existing language base and carry the torch, and create new versions.
It's important to provide a convenient Propeller chip list or repository source of languages for applications as needed.
Clearly Sal and Peter have made great language contributions of a positive productive nature for the Propeller chip.
Maybe you have no use for a program language version - however, others find it highly useful.
One may be pinned down to only one language with another chip, however the Propeller may be far more versatile in language options.
http://humanoidolabs.blogspot.com/2012/03/ultimate-list-of-big-brain-languages.html
However, I guess I don't know that Dave intends to support it on P2. I haven't been following the Forth threads very carefully.
There is a very good reason that the British have their beloved 'short list'. Long lists are rather daunting and confounding... a bit of a waste of time. Consider that www.distrowatch.com for Linux provides a rating based on the rate of downloads to indicate what is most active and most used.
I am happy to hear that pfth has already been migrated over to the Propeller 2. It is an indicator of how easy it will be for all of us to transfer our Propeller 1 knowledge to the Propeller 2.
I did pick up the Ga144. OMG, this is tiny and I intend to attempt to solder it according to Schmartboard proceedures ... the right flux and a soldering iron with a tip of 0.4mm or less diameter at 750 degrees F.
There really is no point in supporting all the i/o until I have a good RS232 boot port active and confirrn the chip is in good working order. ArrayForth provides the interface and test code. Beside, I have to import all the level shifters and support chips and the shipping costs are going to likely double the cost and create delays. At this point, if I really like the GA144, I might just opt for the GreenArray's development board to go that far as the construction of an elaborate Schmartboard solution seems of dubious merit.
I do have to confess. I didn't just buy one GA144, I bought two. So if the first attempt is more educational than successful, I have a way to move ahead.
I started looking at seriously creating my own version of eForth for the Propeller and settling for that to be a really adequate Forth solution. I am being forces into sizes that are minuscule and voltages that that are also minuscule. Using the GA144 might require a good scope for adequate support as signals of 666Mhz are supposedly possible.
http://www.greenarraychips.com/home/documents/greg/AN005-110926-SCHMART.pdf
Rather than solder one side at a time, I first soldered opposing diagonal corners in order to secure the chip from shifting in any manner. I used a bottle of liquid flux that is water soluble, a brand new tip for my 30 watt cheapo soldering iron, and held the board in a machinist vise that is intending for holding work on a drill press (nice and heavy and secure without having to bolt to a bench). I did NOT add any solder to the top of the board as the slots have enough provided by Schmartboard. I did add solder to the bottom side ground hole after flooding first with liquid flux to get a good ground.
Use a very brightly lit work area.
Optically, I have a pair of stereo optics that are 10x and maybe 20x in the higher mode, a few magnifying glasses, and a 20x jeweler's loupe. The GA144 seems adequately soldered. I waited until after 4 passes on the top to solder the ground through the hole in the bottom. I now have to do some continuity testing - adjacent inputs for possible solder bridges, all the ground lines to confirm a complete ground, all the voltage lines to confirm they are complete, and certainly the reset line and the boot RS232 i/o. That will likely take longer than the initial soldering, but I feel it is a must do in order to not waste time later with mysterious and potentially disastrous problems.
Only after all that is done will I complete assembly of the power bus, attached the by-pass capacitors, attach appropriate pull-downs and pull-ups to boot i/o's that need to be ignored, and construct a daughter board with reset and Rs232 interface. I do have a 1.8 volt power supply that I purchased from Schmartboard.
The Schmartboard is interesting as this board actually has slots milled into the board to hold solder and to enhance positioning of the little feet that most board have. But the GA144 does not have these. So I relied on extremely careful verification of position before I started soldering. The device was already taped with a yellow piece of narrow tape running diagonally to the board and the position happened to be 100%. But I would not rely on that... must verify. We will just have to see how the testing and further construction pan out.
If something is really wrong, I have a second kit. But I'd much rather get this one right the first time. Soldering by pushing the solder in troughs is a bit tricky. The iron should be very hot, lots of flux fluid should be used, and one needs to acquire a feel for not pushing too hard. The iron tip should just slide, not dig in. And I found my cheapo soldering tip would wobble as it is held in with two opposing screws. One might prefer a better iron to eliminate the wobble. I did consider buying a different size iron for this project, but choices vary ... 150watt (likely a disaster of too much heat), 40 watt, 30 watt, 20 watt, 15 watt. The specs said I should have 450 degrees F, but I have no idea what the temperature was. When it seemed too cold, I just let the iron sit for 5 minutes to get really hot again.
I don't usually test soldering with chips installed on a board, but there is no other way to do so with this one. I happen to have a 10ma meter, so the DIP continuity meter should be fine. Another alternative might just be an LED that works at 1.8 volts or less.