The Super8 had a stack pointer (SP), program counter (PC), and threaded instruction pointer (IP). Each threaded procedure (i.e. Forth "word") began with machine code, which was typically an ENTER instruction, but didn't have to be -- and wasn't for atomic operations.
The ENTER instruction was used to begin a sequence of threaded code. IP was pushed onto the stack, then set to PC, which pointed to the next word after ENTER. Then PC was set to the contents of memory at IP. Finally IP was incremented to point to the next word in memory. The threaded instructions following ENTER were just addresses pointing to other machine-language routines.
The EXIT instruction was the reverse of ENTER and used to switch back from threaded code to machine-language instructions. IP got popped off the stack, then PC was loaded from the contents of IP and IP was incremented. To use it, you typically had a threaded word defined with EXIT as its only instruction.
The NEXT instruction was used to go to the next address in the threaded code list. PC was loaded from the memory at IP, then IP was incremented to point to the next address in the list.
Loopy, for me Forth is a way to learn about stack-based languages, and languages that can compile themselves, and add to themselves. I've use pfth under spinix to build simple scripts and run them. From my perspective, Forth is best used as a scripting language. I think more complex applications are better done in other languages that have better development support.
With that said, I can understand that Forth seems perfectly logical to some people, and they can't imagine programming in any other language. That's cool. I think most people are wired to program in languages like C, Basic and Spin, which is why I think it's better to suggest that approach for newbies. At some point, a programmer should try a variety of languages. There's something to learn from every language.
Ah... I see. Peter J. and I may be wired backwards.
Doug, I think you missed the mark on "mark". Your example is for marking the dictionary, and then clearing all the defined words after the mark. The rest of us were talking about accessing variables on the stack.
Yes, I noticed that about missing the mark but I figured there would be a Doh moment eventually.
This is funny. I consistently forget the purpose of mark and forget-to-mark. In the context of forth on a teeny microcontroller, these are things I would usually NOT want to do. In fact, they would indicate that I have lost control of the stack. Doing things that require removing an arbitrary number of elements off the stack are not things that I would do in an application on a microcontroller in forth. But thats just me, and I have limited experience.
What are some things that do need mark and forget to mark, that are elegantly done on a small stack machine? Are there contexts where it is simply not possible to kep track of the stack?
Peter, I explored Tachyon alongside a really old Apple 2 forth, just for grins.
I think your kernel is brilliant and you've done a fine job maximizing it for P1. Additionally, you've posted up enough sample code for people to try various things and learn much like they would in SPIN, PASM, C, etc...
And it's fast! Kind of, "Really?" fast. That was unexpected, even though you made that point clear many times here. Experiencing it was cool.
I found it possible to make the two Forths work in very similar ways by writing the words needed. And that right there was a notable realization. Code reuse on Forth is notable in that it depends on the vocabulary present on both the source and target Forths. In C or SPIN, PASM, whatever, we don't change the language to make something work, though we may well abuse, hack and so forth. (kidding)
I also found my mindset a long ways from Forth. Working with it changed how I think of things a little, and having that happen is worth the experience. Right now on P2, some of us are writing bits of code and asking Chip for an instruction here and there so that code is optimal. A person working in Forth thinks this way a lot, and the new "instruction", which really is a word in Forth, can be defined using the existing ones, or one can write some PASM and add to the kernel for max speed, or to get at some hardware feature or other.
So an analogous sort of thing would be a CPU with a microcode that one can define. In that scenario, reusing assembly language programs would require one to have a similar microcode definition, or write "trap" or "exception" or "break" type instructions to simulate what is missing before the program could be used elsewhere. Forth appears like this to me. The same could be said for SPIN. Adding a word or two to SPIN, linked in at the language level, not as a function at the byte code level, and doing it just so would make the program sing.
Those things aren't done with CPU's (well there is probably one somewhere), nor things like SPIN, because that complicates code bodies and their reuse and it increases the number of things somebody needs to know in order to reuse.
My other realization then was to really get the most use out of a Forth, one must understand the kernel, how it offers up the core things, words defined, and then the code to be used or written makes complete sense down to the assembly language level. Arguably machine language, depending on how one chooses to hack around and make it work for them. This is true for other languages and environments, but it's more static.
These things mean Forths are born on CPUs, their authors get the language core running, optimize things for whatever CPU and device they are on, then they drag in their core words, write a few, and then either reuse older code, or author programs using words they know because they have defined them, and that Forth ends up being just the right tool for the intended end purpose. Honestly, that is very cool and unlike C or other compiled languages that require a more complex bootstrapping process.
Notably, C on the Propeller offers a fair number of things that get us access to the chip and reusing that C code elsewhere becomes difficult if the target varies significantly from the source. None of that is true for the most part on programs that are more generic and stick to the core language elements. Forth helped me to understand some of how that all works.
Forth itself doesn't appear to be or do much. As intended. It's the words and how that Forth was bootstrapped into the environment that makes it powerful. Arguably, C without libraries and such isn't much either. And it's how those libraries were created and the whole thing bootstrapped into the environment that makes it powerful.
I really like how Heater has shown us some of the interactive nature of Javascript, and I really like how you have shown us the interactive nature of Tachyon Forth too. Both offer the possibility of having the chip actually doing something while the developer works right there in the mess building the rest or just more, whatever makes sense at the time.
When I got started on this stuff, a system monitor was used for that purpose, and I really like how we can be working on the P2, using that monitor and or whatever else we've built on it, able to build more, and or "the rest" while things are running nicely. Someday, maybe sooner than we think, we will be able to "squirt" (Chip's term for just stuffing code into a P2 for launch by the monitor) a Forth into the P2 and have it running alongside some PASM or SPIN we've written, perhaps to connect things together, or debug, or tinker with how things really work.
Anyway, those are some impressions I came away with. I enjoy your ongoing efforts to build your Forth into something really powerful for the P1, and that you share code and explain how and why it works. I think it's great, and I see that it's potent and that you are getting stuff done in the house you built to get stuff done.
One last impression: If I were to hack SPIN, or write some odd custom libraries for C, or do any number of things off the beaten path of whatever environment I'm using, the sharing of that code would trigger others to learn and do what I did, or modify to suit. Generally speaking, that's a bad idea in most environments because people want to spend time learning about their task, not meta-learning about some pieces that appear to help with their task. Forth is so small and basic, one just ends up doing what makes the best sense right out of the gate, with that Forth evolving into a seriously powerful tool for the job.
I think that is a barrier to many people because it represents a foreign way of thinking. That was my exact experience. And that's not a bad thing, just a very different thing than most people are used to. I also think when say 100 developers are exposed to Forth, particularly an optimized one like Tachyon is now, a few of them will go all the way down the rabbit hole and reach mastery and they will do so for the same reasons you built it in the first place, and that's good.
Many of them will see that rabbit hole, and just not choose to go all the way down and that's just preferences and modes of thinking differences, no worries on any of it. For those that do, they will enjoy considerable skill very useful in the ways detailed here in this thread, and that too is a very good thing.
And that dynamic is why we have "language as religion wars" type discussions! Not my intent here, just sharing what I learned and thought while using Tachyon, which I really enjoyed doing.
It will be very interesting to see how you evolve Tachyon once you've got P2 chips to do it on.
In the context of forth on a teeny microcontroller, these are things I would usually NOT want to do. In fact, they would indicate that I have lost control of the stack.
Losing control of the stack and not needing total control over the stack are two ways to express the same thing. "Losing control" connotes something negative. I would contend that mark and cleartomark are more positive.
These two operators allow a Forth word to push a bunch of stuff on the stack and leave it there without having to worry about cleaning up as you go along. Then when the word has completed, the stack can be cleared to the state it had at entry and the results, if any, pushed on. Maintaining a clean stack at every point in one's program entails a lot of sturm und drang that gets in the way of simply getting things done. It would be like telling your party guests to wash their cocktail glasses before every refill and immediately sweep up any crumbs that might fall on the floor, rather than you just cleaning things up after they've left. Of course, that may be some people's style. I tend to avoid such parties.
Peter, I explored Tachyon alongside a really old Apple 2 forth, just for grins.
I think your kernel is brilliant and you've done a fine job maximizing it for P1. Additionally, you've posted up enough sample code for people to try various things and learn much like they would in SPIN, PASM, C, etc...
And it's fast! Kind of, "Really?" fast. That was unexpected, even though you made that point clear many times here. Experiencing it was cool.
.
.
.
Nice write up. People seem to always jump on Peter's threads. I can't understand the animosity couched in "engineering debated". I have been showing people at my maker's space Tachyon who can now blink lights....and can just never grap all the contorsions of the "meta" syntax required of other languages. You gurus take if for granted: compiler, editor, download, run... Have any of you spoken with retirees who are trying to make a small project and learn a little, not become a software engineer with C, Spin... I have and do two times a week and Tachyon / Forth allows me to get them going. It makes them smile because THEY made the lights blink with one line and not some convoluted (to them) compile, download, run sequence.
So all the haters please leave the FORTHers alone, were busy smiling and making others smile too. GET OUT OF HERE, your input is not welcome or wanted, there I said it.
"They made it blink", means everything at the early stage.
There is a core difference between developing ON as opposed to FOR. Developing ON a device connects us to it in basic, core ways. A basic or forth or any other thing capable of delivering this experience is well worth doing.
I remember the feeling I got on the Apple 2 the first time I went into the monitor, asked it for the mini assembler and got a short assembly language program to run. It was like that feeling I got in Basic, but deeper. "Now we are talking!" Is the best way to explain it.
Some time later, on an Atari machine, I read the data sheet for the PIA chip. POKED a few numbers in and watched a light come on. Pressing carriage return made the link. Of course, that evolves into all sorts of fun, and for me, it ended up keying my HF transmitter to send Morse I had typed in.
Das Blinken light is where it all starts. Tachyon is fine for this and newbies will still just type it in...
Compile 'n run today is often so fast, people get connected that way too. But they don't get that ON experience, just a great FOR experience.
As best I recalled your 'non-trival' calculation application was Fast-Fourier Transforms... simply an application that might best be optimized in assembler on any machine. Admittedly, Forth does not readily embrace precision floating point. FFT almost cries out for a dedicated math co-processor.
Sorry I missed you post.
I maintain that that FFT is trivial. Forget that it is an FFT. Forget all the complexity of the mathematics behind it. Sure that is a bit heavy. Never mind what it does at all. Just look at as a piece of code. What we have is three nested loops and some simple arithmetic on arrays in the middle. There is nothing in there that you would not find in many other programs. Multiply, add, shift, array look up etc.
The whole point of that FFT is that it does not need floating point. Within it's limits, precision and sample size, it works well enough and faster than it would with floating point done in software.
As for "best optimized in assembler". I'm not sure. That assembler version was tweaked with optimizations suggested by forum members but then it turns out the naive version compiled from C works almost as fast!
Still living in hope of making a Forth version of that FFT.
I do believe that the interactivity offered by Forth is of value. Back in the day a lot of kids got attracted to programming because they found that when they turned on their Spectrums or C64s to play games it was inviting them to type in some very simple BASIC which immediately did something. BINGO there was the hook to further investigation.
Aside: When I say "kids" I also include my father who was retired at the time. At nearly 70 years old he bought himself a TRS80, having never seen a computer before, and learned to program in BASIC. He was a bit wacky for his generation!
So all the haters please leave the FORTHers alone, were busy smiling and making others smile too. GET OUT OF HERE, your input is not welcome or wanted, there I said it.
D.P, I haven't seen anything hateful posted about Forth in this thread. There have been many common sense things posted here. People that label themselves as Forthers should realize that Forth is not the best solution in all cases. There are many situations where Forth is the best solution, but there are many other cases where Spin, C, C++, Java, PASM or some other language is a better fit. Anyone that limits themselves to Forth is just missing out on the benefits that other languages provide.
Losing control of the stack and not needing total control over the stack are two ways to express the same thing. "Losing control" connotes something negative. I would contend that mark and cleartomark are more positive.
These two operators allow a Forth word to push a bunch of stuff on the stack and leave it there without having to worry about cleaning up as you go along. Then when the word has completed, the stack can be cleared to the state it had at entry and the results, if any, pushed on. Maintaining a clean stack at every point in one's program entails a lot of sturm und drang that gets in the way of simply getting things done. It would be like telling your party guests to wash their cocktail glasses before every refill and immediately sweep up any crumbs that might fall on the floor, rather than you just cleaning things up after they've left. Of course, that may be some people's style. I tend to avoid such parties.
-Phil
there is a feature in Tachyon that can be used in a similar way
it is
ITEMS ( n1 n2 n3 n4 ... nm m -- ) \ pushes m top items from stack into local working registers
and the stack is clear
So if you use this on entry in your function/word the stack is free
and with
ITEM@ ( n -- value ) \ you can pick the value from the n-th working register
in addition there is
( *** LOCAL VARIABLES *** )
{ Saving stack parameters to local variables can simplify the stack manipulation required
A specified number of parameters are removed and copied to the local variables area but first the
existing local variables are pushed up so that they are saved and can be restored with a RELEASE
Example of using LOCALs:
pri (RECT)
X4 X3 X2 HLINE
X4 X3 X1 1- + X2 1- HLINE
X4 X2 + 1- X3 X1 VLINE
X4 X3 X1 VLINE
;
\ Draw a rectangle
pub RECT ( x1 y1 width height -- )
( X4 X3 X2 X1 )
4 LOCAL (RECT) 4 RELEASE
}
This is essentially a kind of stack frame, that you use just when it is helpful
BTW: studying the TACHYON kernel implementation is a great way to learn PASM.
I started with the Prop with very little SPIN, some PASM and then TACHYON.
Reading the kernel words and how they work was very enlightening to me.
And it is quite easy to extend TACHYON with loadable little PASM snippets.
But you have to edit the kernel file, which is wrapped in a little SPIN.
You can even use the PASM word to execute single PASM instructions (that need to be specified in binary ...) so you need to know what you do ... or you learn it ;-)
PASM ( val pasm -- result pasm )
one of my backgrounds is in AI ( LISP, PROLOG, SMALLTALK ) so being able to extend the language itself is a thing I love.
LISP is actually similar in some respect to FORTH but the syntax there is PREFIX instead of POSTFIX with FORTH.
And each WORD is called SYMBOL there and has an associated 'meaning' = the functions definition or the variables value.
Hi Peter,
in reading this code here again it just jumps on me ( you probably thought about this already)
( *** LOCAL VARIABLES *** )
{ Saving stack parameters to local variables can simplify the stack manipulation required
A specified number of parameters are removed and copied to the local variables area but first the
existing local variables are pushed up so that they are saved and can be restored with a RELEASE
Example of using LOCALs:
pri (RECT)
X4 X3 X2 HLINE
X4 X3 X1 1- + X2 1- HLINE
X4 X2 + 1- X3 X1 VLINE
X4 X3 X1 VLINE
;
\ Draw a rectangle
pub RECT ( x1 y1 width height -- )
( X4 X3 X2 X1 )
4 LOCAL (RECT) 4 RELEASE
}
if we change the stack comment say to
pub RECT ( x1 y1 width height == )
this could indicate to a more intelligent compiler to automatically insert the
n local .... n release
and in between the arguments can be accessed like local variables Xi from stack frame.
And since the compiler is written in FORTH itself we can just adapt and extend it.
So we had extended our private language as we like.
I could do this in LISP but conventional languages like C ... hmm ???
D.P, I haven't seen anything hateful posted about Forth in this thread. There have been many common sense things posted here. People that label themselves as Forthers should realize that Forth is not the best solution in all cases. There are many situations where Forth is the best solution, but there are many other cases where Spin, C, C++, Java, PASM or some other language is a better fit. Anyone that limits themselves to Forth is just missing out on the benefits that other languages provide.
It is a two-way street.
People that adamantly avoid Forth are missing some rather interesting and useful resources
Frankly, I suggest that newcomers focus on languages that work well on microcontrollers if they are here (involved with this forum), not ones that work well on micro-computers. There is a big difference between micro-controllers and micro-computers.. try to comprehend the difference and why. The comparative smallness is an advantage to demonstration where the real power of computing is focused.
I doubt that the Propeller will have a full-function Python anytime soon. The Propeller is a micro-controller and there is a very real subset of languages that work well with it. If you want an elaborate GUI, or a GByte file system handling a multitude of files, or you want a multi-user system; that's what a convention PC does well. Linux will provide you with a vast array of programming lanaguage -- both the newest and some of the oldest for free on your PC.
I suspect that Peter J. is referring to the community of users that just want to cut and paste without much thought when he refers to 'sealed' compiled code. It is a phase that a lot of new users go through, some even grow through it and start envisioning their own code rather than searching the web for piece to borrow.
Anything that gets you empowered to more deeply envision your software projects and to more deeply understand the physical resources of your micro-controller are a good thing. But approaches that relable programs to 'sketching', configuration to 'wiring', and users to 'artist'; tend to attract some rather superficial learners. The same thing goes for creating the smallest, cheapest microcomputer possible. Yes, it is interesting to do these things and they do get a lot of attention; but we end up with a huge crowd of people shouting 'What's next?' rather than learning skills that can be passed on to others.
If you mission is to learn computing and to mentor others along the way; it helps to be open minded to real possiblities, not just free suport and low prices and more exotic goodies.
Forth on the Propeller is excellent for some things. On the other hand, Charles Moore's Color Forth on his GA144 actually seems to be embarrasingly off in the weeds. I just can't seem to grasp the utility of it.. not enough i/o access, too many parallel processors buried in a grid format, and some other features that are just hard to unravel.
The 8 cogs with shared i/o and shared hub ram do wonderful things with Forth.. lot of surprises on how powerful the Propeller 1 can be. Add an SDcard and it is a whole tiny system that is capable of carrying its own docuemntation along with it.
...if we change the stack comment say to....this could indicate to a more intelligent compiler to automatically...
Perhaps I'm misunderstanding what you have said there but it seems to imply that comments in the Forth language can have meaning to the compiler.
That is to say that comments can be part of the code that is compiled not just random ramblings of the programmer inserted here and there.
Perhaps I'm misunderstanding what you have said there but it seems to imply that comments in the Forth language can have meaning to the compiler.
That is to say that comments can be part of the code that is compiled not just random ramblings of the programmer inserted here and there.
If so, I think it's totally insane !
Am I missing a point here?
But this is what Forth is, Forth is the compiler, the language, the environment, the operating system which is why trying to compare it with a language that compiles on a PC factory is like trying to compare atoms and oranges. Forth becomes what you make it just like a few basic ingredients can become a beautiful dish or in the wrong hands just an unpalatable mess. The comment thing has been discussed before as a means to create in-system help comments but also to inform the routine how to handle the stack and whether to treat them as local variables or perhaps even just to mark the stack. Yeah, totally insane huh?!
Yep, totally insane. If compilers were to compile the comments in my code it would be a horrible disaster:)
More seriously, once you have the compiler comprehending the comments then they are not really comments any more but become part of the language syntax. You now need some other place to comment the code in your comments !
That will be open sourced so we may well see Python on the Propeller much sooner than you thought.
Frankly, I suggest that newcomers focus on languages that work well on microcontrollers...
Languages that work well on micro-controllers now includes Python and Javascript along with the old favorites. The line between micro-controllers and micro-computers is getting fuzzier every day.
Here in Parallaxia we are stuck in a bit of a time warp in that respect due to the serious limitations on memory space and raw speed of the Propeller.
@ Heater
Well, the British will do anything for Monty Python, and the Raspberry Pi......
And so... will that Python on a microcontroller be interpreted? Or will you just end up loading binaries? I see it saying, "No set-up, no compiling, and no soldering"..... More shall soon be revealed.
It certainly do seem that Micro Python for the Propeller is available, I just have to subscribe at 1,000 Pounds sterling and pay all the startup codes.......... arh...!
I believe it was Leonardo Da Vinci that claimed that small spaces discipline the mind. The limitations in size demonstrate the simple power of a small set of programing lexicon and the limitations of speed are no limitations at all in mechanical control. You just need more of both and a big fat hard disk to 'process data'. In many ways, small microcontroller have better education outcomes for new users.. as demonstrated by the BasicStamp2.
You claim the lines are blurring, but I strongly select that your vision of the difference between the two is what has been blurred. It is still about deterministic control versus generalized data processing.
I like Python, but it just becomes a distraction for me on a microcontroller. Users won't learn how to exploit smallness is an efficient manner; they will just hang on to expecting Python to do it all. On the other hand, Forth is allowing to investigate all of the Propeller's PASM instructions in a context where I can learn PASM by using it.
I keep coming back to this point because I started with Forth with the desire to use it to help me to learn how to do more in PASM than the bare bones. And it is certainly empowering me to do so. I just retain the point of view that some aspects of learning about digital devices are better learned on a Propeller without an OS, and others are better learned in Linux with a full featured OS capable of massive support.
Confusing the two... blurring the lines... just muddles the novice as they don't know quite what to use.
Your Micro-Python claims the following...
Full implementation of the Python 3 grammar (but not yet all of Python's standard libraries).
My coment was about the full=function Python.. without missing standard libraries.
~~~~~~~~~~~~~~~~
Aside from all the debate, I do extremely like the Micro Python board with the micro-SDcard slot on-board. Parallax has created the MINI-Propeller that just uses 19 of the Propeller's I/O.
If Parallax were to make a MINI+SDcard Propeller, it would be a very handy up-grade. After all, there are unused i/o pins available.
@ Heater
Well, the British will do anything for Monty Python, and the Raspberry Pi......
And so... will that Python on a microcontroller be interpreted? Or will you just end up loading binaries? I see it saying, "No set-up, no compiling, and no soldering"..... More shall soon be revealed.
It certainly do seem that Micro Python for the Propeller is available, I just have to subscribe at 1,000 Pounds sterling and pay all the startup codes.......... arh...!
I believe it was Leonardo Da Vinci that claimed that small spaces discipline the mind. The limitations in size demonstrate the simple power of a small set of programing lexicon and the limitations of speed are no limitations at all in mechanical control. You just need more of both and a big fat hard disk to 'process data'. In many ways, small microcontroller have better education outcomes for new users.. as demonstrated by the BasicStamp2.
You claim the lines are blurring, but I strongly select that your vision of the difference between the two is what has been blurred. It is still about deterministic control versus generalized data processing.
I like Python, but it just becomes a distraction for me on a microcontroller. Users won't learn how to exploit smallness is an efficient manner; they will just hang on to expecting Python to do it all. On the other hand, Forth is allowing to investigate all of the Propeller's PASM instructions in a context where I can learn PASM by using it.
I keep coming back to this point because I started with Forth with the desire to use it to help me to learn how to do more in PASM than the bare bones. And it is certainly empowering me to do so. I just retain the point of view that some aspects of learning about digital devices are better learned on a Propeller without an OS, and others are better learned in Linux with a full featured OS capable of massive support.
Confusing the two... blurring the lines... just muddles the novice as they don't know quite what to use.
Your Micro-Python claims the following...
Full implementation of the Python 3 grammar (but not yet all of Python's standard libraries).
My coment was about the full=function Python.. without missing standard libraries.
~~~~~~~~~~~~~~~~
Aside from all the debate, I do extremely like the Micro Python board with the micro-SDcard slot on-board. Parallax has created the MINI-Propeller that just uses 19 of the Propeller's I/O.
If Parallax were to make a MINI+SDcard Propeller, it would be a very handy up-grade. After all, there are unused i/o pins available.
BTW, if the STM32F405 with DSP and floating-point for the micro Python is a "microcontroller" then what does that make the 8-bit AVRs on the Arduino? pico-controllers?
At risk of being way off topic for this thread I have to answer your concerns:
...will that Python on a microcontroller be interpreted?...
The entire Micro Python system lives in the micro-controller. All you need is to talk to it via a terminal. No external compilers etc required, no loading binaries, just like Forth system. Type in your code and it runs.
It certainly do seem that Micro Python for the Propeller is available, I just have to subscribe at 1,000 Pounds sterling and pay all the startup codes.......... arh...!
No you don't. That's not what it says. Micro Python is promised to be open sourced when it's creator has finished it and shipped out all the boards to the Kickstarter backers. Perhaps in January. The same deal as the Espruino Javascript project, not that they are in anyway related. When the code is released then it's down to some Propeller heads to "do the impossible" and get it running on the Prop. Yes, yes, I know, unlike Forth it will require a huge gob of external RAM.
Leonardo Da Vinci that claimed that small spaces discipline the mind.
And Stalin is credited with saying "Quantity has a quality all its own".
You just need more of both and a big fat hard disk to 'process data'.
Do you mean me when you say "you"? I'm with you and Leonardo much of the time. Else why would I be tinkering with Propellers in the first place?
In many ways, small microcontroller have better education outcomes for new users.. as demonstrated by the BasicStamp2.
That is a non-sequiter. The basic stamp is programmed in BASIC. It might as well be running on a machine with 4GB or RAM and a terabyte hard drive. The small physical size, low power consumption, and useful I/O is what makes it. These tiny new MCU's running Java, JavaScript, C#, Python, etc are the modern day equivalent.
You claim the lines are blurring, but I strongly select that your vision of the difference between the two is what has been blurred. It is still about deterministic control versus generalized data processing.
What I meant by "blurring" is quite simple. Deterministic control has nothing to do with it. Back in the day, a microprocessor was just a CPU. You needed ROM chips, RAM chips, I/O chips and God knows what else to get it running. Then came the "micro-controllers" where all those separate chips were subsumed into one device that could operate by itself. Both microprocessor systems and micro-controllers were capable of deterministic real-time control. Micro-controllers were very limited in memory space compared to microprocessor systems of course.
Today we have micro-controllers that are absolutely tiny physically, sip very little power, have tons of I/O and cost almost nothing but have on board memory and other resources (Floating Point) far in excess of the first IMB PC or the 8 bitters that preceded it.
That's what I call "blurring the lines" between microprocessor systems and micro-controllers.
I like Python, but it just becomes a distraction for me on a microcontroller.
Just like BASIC on a BASIC STAMP then?
Your Micro-Python claims the following...
Full implementation of the Python 3 grammar (but not yet all of Python's
standard libraries).
My coment was about the full=function Python.. without missing standard
libraries.
Who cares? The language is there, the support for all the things you may want to do in hardware is there. Obviously a gigabyte of supporting libs is not and they would not do you any good anyway as you don't have the space. BASIC, SPIN, FORTH etc don't have any libs so what are you quibbling about?
The point of all this JS or Python on an MCU is exactly the same as it was for the BASIC STAMP or Forth. Exactly the same as the Propeller and Spin. Give people an opportunity to use the available technology in a simple way so they don't have to worry about a billion implementation details. Not to be the smallest or fastest way to get things done.
BTW, if the STM32F405 with DSP and floating-point for the micro Python is a "microcontroller" then what does that make the 8-bit AVRs on the Arduino? pico-controllers?
Good question. I did say "blurring the lines" didn't I.
@Heater
I am beginning to suspect you are a tout in deep cover as a Propeller user from OpenAVR.
The MicroPython does offer to port it to another microcontroller for 1000 pounds, and they will develop any library feasible for 300 pounds. Sounds like there are several cavaets to being entirely open-source and complete. And this Python could [a] never arrive at being complete, or become a very expensive Propeller platform. The developers are restricting themselves to silicon that has builting UARTs and build in ADCs, and so on. More has to be done to cobble it into a Propeller.
But at least it seems that it can control a PWM servo....
I still hold to the opinion that the limited size and resources of a micro-controller are an educational asset. Maybe they just promote more rational deployment of resources.
Why would anyone run a BasicStamp2 emulation on an Intel PC with a TByte harddisk? You miss (or ignore) the whole point of small software on small systems being the heartbeat of microcontollers.
Yep, totally insane. If compilers were to compile the comments in my code it would be a horrible disaster:)
More seriously, once you have the compiler comprehending the comments then they are not really comments any more but become part of the language syntax. You now need some other place to comment the code in your comments !
The stack comments in FORTH follow a defined format ( in1 in2 -- out1 ) where the parameters that a word takes from the stack get humanly readable descriptive names and the results pushed back on the stack as well.
FORTH does not need this, maybe the programmer does not need this as well - until he comes back some time later und wants to understand what his code does.
And for others who want to reuse some code stack comments are a must.
This is not the humanly readable text that explains only to a human, what the program is expected to do.
If you have a look at C for example, there most of the lines, the complete .h file and all the declarations, are actually formal comments to tell the compiler how to do the job.
The actual code, that does the logic or numeric task is only a small part of the programmer's work.
Since FORTH like some other interpreted languages (LISP, Prolog, Smalltalk, Java-Bean-Shell to name a few ...) provides mechanisms for introspection it is possible
to extend the language so code and structured comments can be examined and put to use.
But for a lean resource preserving system this is the icing on the cake and not really required.
@Peter: I am working on using the stack comment to implement stack frames.
this is a challenge which helps deepen my insight into the TF kernel
and I have some ideas that I hope I can realize.
I want to build it on the locals construct and have a few special words do the job
A data point on FORTH ease of use versus C. I've made slow forward progress on my recent fixed point inverse kinematics project. Meanwhile I was able to bang out a Java version with a GUI in a few hours. However it would be completely unfair to blame my slow progress on FORTH. All of my problems have been with the need to create a fixed point trig package and convert ratios that would produce radians to brads. I keep finding places where I botched things, but I would have had exactly the same problems had I tried this in C.
Indeed FORTH might help a bit with fixed point math because I can decompose functions and interactively test their output. Below is my set_position function decomposed into three functions which I can then interactively test to see what output they produce.
\ calculates shoulder to waist distance using pythagoras' theorum.
\ ( x y -- )
: pythagoras
\ Save the Cartesian space coordinates.
y ! x !
x @ square
y @ square
+
dup s_w !
isqrt s_w_sqrt !
;
\ calculates shoulder angle using IK via fixed point trig.
\ ( -- brad13 )
: ikshoulder
\ s_w angle to centerline
y @ x @ atan2 \ a1 is on the stack.
\ s_w angle to humerus
\ compute (_humerus_sq - ulna_sq + s_w) / (2 * humerus * s_w_sqrt)
\ note that the mysterious bit shifts are to convert to fixed point.
humerus_sq @ ulna_sq @ - s_w @ +
16 lshift
2 humerus @ * s_w_sqrt @ *
/
\ use arccos to get a2 on the stack
15 lshift
clamp acos
\ shoulder angle = a1 + a2
+
;
\ calculates elbow angle using IK via fixed point trig.
\ ( -- brad13 )
: ikelbow
\ elbow angle
\ compute ( humerus_sq + ulna_sq - s_w ) / ( 2 * humerus * ulna )
\ note the mysterious bit shifts convert to fixed point.
humerus_sq @ ulna_sq @ + s_w @ -
16 lshift
2 humerus @ * ulna @ *
/
15 lshift
clamp acos
;
\ SetPosition : Arm positioning routine utilizing inverse kinematics. Since
\ the arm is resting on a surface Z can only be positive. Servo movement
\ constraints prevent y from being negative, But X can be a signed value.
\ Note: This must be called before any of the move routines to initialize
\ arm state!
\ x - the side to side displacement.
\ y - the distance out from the base center.
\ ( x y -- )
: set_position
\ Save the Cartesian space coordinates and calculate s_w and s_w_sqrt
pythagoras
\ compute the shoulder angle
ikshoulder set_shoulder
\ Set the elbow
ikelbow set_elbow
;
That will be open sourced so we may well see Python on the Propeller much sooner than you thought.
Languages that work well on micro-controllers now includes Python and Javascript along with the old favorites. The line between micro-controllers and micro-computers is getting fuzzier every day.
Here in Parallaxia we are stuck in a bit of a time warp in that respect due to the serious limitations on memory space and raw speed of the Propeller.
I have to second Heater here. There are now Pythons, Javascripts, and Schemes that run on microcontrollers and further are becoming more usable for real work every day. The rapid evolution of more capable hardware means the long-term trend in microcontroller programming will likely be toward more REPL-type languages and environments. And I for one welcome it.
The rapid evolution of more capable hardware means the long-term trend in microcontroller programming will likely be toward more REPL-type languages and environments. And I for one welcome it.
Typo? You meant to say "more PERL-type languages," right? (At least that's how my dyslexic brain first read it.)
As I was going about my business updating documentation on my Tachyon Forth and source code I was also exercising a lot of the functions that I have built in, testing and timing them. The thought occurred to me, "where would I be if I wasn't using this stuff?". ...
Hmmm, I know I should be quite, but every once in a while I can't help but stand up on my little soapbox and say something, even a little something. I know I'm not missing out.
You're entitled to your soapbox, Peter. I've played with Tachyon Forth and it is quite impressive. Certainly it's something that can be used to get *real* work done. (Based on my experiences it's noticeably faster than Spin.) Additionally, Forth support on the Propeller is in general impressive. I've done more "experimenting" with Forth than I ever have, simply because it's so easy to do on the Propeller.
I've never found RPN or the stack to be an obstacle to using Forth. One can do small tasks in Forth without too much of a learning curve. But when I think of doing all my work - ie, an entire uC application - in Forth, I do find some merit to what Dave says about the lack of readily available libraries and code standardization/portability. It can be a bit daunting to consider having to build so many things more or less from scratch that one usually takes for granted - in, say, Spin, C, or Pascal. I have no doubt that this isn't much of a hurdle for an experienced Forth developer (often someone who is using SwiftX or MPE anyway). On the other hand, as I see the code base for Tachyon, PropForth, and pfth grow, I realize that, with Forth on the Prop at any rate, soon this may not be such an obstacle for me.
Comments
The ENTER instruction was used to begin a sequence of threaded code. IP was pushed onto the stack, then set to PC, which pointed to the next word after ENTER. Then PC was set to the contents of memory at IP. Finally IP was incremented to point to the next word in memory. The threaded instructions following ENTER were just addresses pointing to other machine-language routines.
The EXIT instruction was the reverse of ENTER and used to switch back from threaded code to machine-language instructions. IP got popped off the stack, then PC was loaded from the contents of IP and IP was incremented. To use it, you typically had a threaded word defined with EXIT as its only instruction.
The NEXT instruction was used to go to the next address in the threaded code list. PC was loaded from the memory at IP, then IP was incremented to point to the next address in the list.
-Phil
Ah... I see. Peter J. and I may be wired backwards.
This is funny. I consistently forget the purpose of mark and forget-to-mark. In the context of forth on a teeny microcontroller, these are things I would usually NOT want to do. In fact, they would indicate that I have lost control of the stack. Doing things that require removing an arbitrary number of elements off the stack are not things that I would do in an application on a microcontroller in forth. But thats just me, and I have limited experience.
What are some things that do need mark and forget to mark, that are elegantly done on a small stack machine? Are there contexts where it is simply not possible to kep track of the stack?
I think your kernel is brilliant and you've done a fine job maximizing it for P1. Additionally, you've posted up enough sample code for people to try various things and learn much like they would in SPIN, PASM, C, etc...
And it's fast! Kind of, "Really?" fast. That was unexpected, even though you made that point clear many times here. Experiencing it was cool.
I found it possible to make the two Forths work in very similar ways by writing the words needed. And that right there was a notable realization. Code reuse on Forth is notable in that it depends on the vocabulary present on both the source and target Forths. In C or SPIN, PASM, whatever, we don't change the language to make something work, though we may well abuse, hack and so forth. (kidding)
I also found my mindset a long ways from Forth. Working with it changed how I think of things a little, and having that happen is worth the experience. Right now on P2, some of us are writing bits of code and asking Chip for an instruction here and there so that code is optimal. A person working in Forth thinks this way a lot, and the new "instruction", which really is a word in Forth, can be defined using the existing ones, or one can write some PASM and add to the kernel for max speed, or to get at some hardware feature or other.
So an analogous sort of thing would be a CPU with a microcode that one can define. In that scenario, reusing assembly language programs would require one to have a similar microcode definition, or write "trap" or "exception" or "break" type instructions to simulate what is missing before the program could be used elsewhere. Forth appears like this to me. The same could be said for SPIN. Adding a word or two to SPIN, linked in at the language level, not as a function at the byte code level, and doing it just so would make the program sing.
Those things aren't done with CPU's (well there is probably one somewhere), nor things like SPIN, because that complicates code bodies and their reuse and it increases the number of things somebody needs to know in order to reuse.
My other realization then was to really get the most use out of a Forth, one must understand the kernel, how it offers up the core things, words defined, and then the code to be used or written makes complete sense down to the assembly language level. Arguably machine language, depending on how one chooses to hack around and make it work for them. This is true for other languages and environments, but it's more static.
These things mean Forths are born on CPUs, their authors get the language core running, optimize things for whatever CPU and device they are on, then they drag in their core words, write a few, and then either reuse older code, or author programs using words they know because they have defined them, and that Forth ends up being just the right tool for the intended end purpose. Honestly, that is very cool and unlike C or other compiled languages that require a more complex bootstrapping process.
Notably, C on the Propeller offers a fair number of things that get us access to the chip and reusing that C code elsewhere becomes difficult if the target varies significantly from the source. None of that is true for the most part on programs that are more generic and stick to the core language elements. Forth helped me to understand some of how that all works.
Forth itself doesn't appear to be or do much. As intended. It's the words and how that Forth was bootstrapped into the environment that makes it powerful. Arguably, C without libraries and such isn't much either. And it's how those libraries were created and the whole thing bootstrapped into the environment that makes it powerful.
I really like how Heater has shown us some of the interactive nature of Javascript, and I really like how you have shown us the interactive nature of Tachyon Forth too. Both offer the possibility of having the chip actually doing something while the developer works right there in the mess building the rest or just more, whatever makes sense at the time.
When I got started on this stuff, a system monitor was used for that purpose, and I really like how we can be working on the P2, using that monitor and or whatever else we've built on it, able to build more, and or "the rest" while things are running nicely. Someday, maybe sooner than we think, we will be able to "squirt" (Chip's term for just stuffing code into a P2 for launch by the monitor) a Forth into the P2 and have it running alongside some PASM or SPIN we've written, perhaps to connect things together, or debug, or tinker with how things really work.
Anyway, those are some impressions I came away with. I enjoy your ongoing efforts to build your Forth into something really powerful for the P1, and that you share code and explain how and why it works. I think it's great, and I see that it's potent and that you are getting stuff done in the house you built to get stuff done.
One last impression: If I were to hack SPIN, or write some odd custom libraries for C, or do any number of things off the beaten path of whatever environment I'm using, the sharing of that code would trigger others to learn and do what I did, or modify to suit. Generally speaking, that's a bad idea in most environments because people want to spend time learning about their task, not meta-learning about some pieces that appear to help with their task. Forth is so small and basic, one just ends up doing what makes the best sense right out of the gate, with that Forth evolving into a seriously powerful tool for the job.
I think that is a barrier to many people because it represents a foreign way of thinking. That was my exact experience. And that's not a bad thing, just a very different thing than most people are used to. I also think when say 100 developers are exposed to Forth, particularly an optimized one like Tachyon is now, a few of them will go all the way down the rabbit hole and reach mastery and they will do so for the same reasons you built it in the first place, and that's good.
Many of them will see that rabbit hole, and just not choose to go all the way down and that's just preferences and modes of thinking differences, no worries on any of it. For those that do, they will enjoy considerable skill very useful in the ways detailed here in this thread, and that too is a very good thing.
And that dynamic is why we have "language as religion wars" type discussions! Not my intent here, just sharing what I learned and thought while using Tachyon, which I really enjoyed doing.
It will be very interesting to see how you evolve Tachyon once you've got P2 chips to do it on.
These two operators allow a Forth word to push a bunch of stuff on the stack and leave it there without having to worry about cleaning up as you go along. Then when the word has completed, the stack can be cleared to the state it had at entry and the results, if any, pushed on. Maintaining a clean stack at every point in one's program entails a lot of sturm und drang that gets in the way of simply getting things done. It would be like telling your party guests to wash their cocktail glasses before every refill and immediately sweep up any crumbs that might fall on the floor, rather than you just cleaning things up after they've left. Of course, that may be some people's style. I tend to avoid such parties.
-Phil
Nice write up. People seem to always jump on Peter's threads. I can't understand the animosity couched in "engineering debated". I have been showing people at my maker's space Tachyon who can now blink lights....and can just never grap all the contorsions of the "meta" syntax required of other languages. You gurus take if for granted: compiler, editor, download, run... Have any of you spoken with retirees who are trying to make a small project and learn a little, not become a software engineer with C, Spin... I have and do two times a week and Tachyon / Forth allows me to get them going. It makes them smile because THEY made the lights blink with one line and not some convoluted (to them) compile, download, run sequence.
So all the haters please leave the FORTHers alone, were busy smiling and making others smile too. GET OUT OF HERE, your input is not welcome or wanted, there I said it.
There is a core difference between developing ON as opposed to FOR. Developing ON a device connects us to it in basic, core ways. A basic or forth or any other thing capable of delivering this experience is well worth doing.
I remember the feeling I got on the Apple 2 the first time I went into the monitor, asked it for the mini assembler and got a short assembly language program to run. It was like that feeling I got in Basic, but deeper. "Now we are talking!" Is the best way to explain it.
Some time later, on an Atari machine, I read the data sheet for the PIA chip. POKED a few numbers in and watched a light come on. Pressing carriage return made the link. Of course, that evolves into all sorts of fun, and for me, it ended up keying my HF transmitter to send Morse I had typed in.
Das Blinken light is where it all starts. Tachyon is fine for this and newbies will still just type it in...
Compile 'n run today is often so fast, people get connected that way too. But they don't get that ON experience, just a great FOR experience.
I maintain that that FFT is trivial. Forget that it is an FFT. Forget all the complexity of the mathematics behind it. Sure that is a bit heavy. Never mind what it does at all. Just look at as a piece of code. What we have is three nested loops and some simple arithmetic on arrays in the middle. There is nothing in there that you would not find in many other programs. Multiply, add, shift, array look up etc.
The whole point of that FFT is that it does not need floating point. Within it's limits, precision and sample size, it works well enough and faster than it would with floating point done in software.
As for "best optimized in assembler". I'm not sure. That assembler version was tweaked with optimizations suggested by forum members but then it turns out the naive version compiled from C works almost as fast!
Still living in hope of making a Forth version of that FFT.
I do believe that the interactivity offered by Forth is of value. Back in the day a lot of kids got attracted to programming because they found that when they turned on their Spectrums or C64s to play games it was inviting them to type in some very simple BASIC which immediately did something. BINGO there was the hook to further investigation.
Aside: When I say "kids" I also include my father who was retired at the time. At nearly 70 years old he bought himself a TRS80, having never seen a computer before, and learned to program in BASIC. He was a bit wacky for his generation!
So people complaining about a programming language should be considered a good sign.
it is
ITEMS ( n1 n2 n3 n4 ... nm m -- ) \ pushes m top items from stack into local working registers
and the stack is clear
So if you use this on entry in your function/word the stack is free
and with
ITEM@ ( n -- value ) \ you can pick the value from the n-th working register
in addition there is
( *** LOCAL VARIABLES *** ) { Saving stack parameters to local variables can simplify the stack manipulation required A specified number of parameters are removed and copied to the local variables area but first the existing local variables are pushed up so that they are saved and can be restored with a RELEASE Example of using LOCALs: pri (RECT) X4 X3 X2 HLINE X4 X3 X1 1- + X2 1- HLINE X4 X2 + 1- X3 X1 VLINE X4 X3 X1 VLINE ; \ Draw a rectangle pub RECT ( x1 y1 width height -- ) ( X4 X3 X2 X1 ) 4 LOCAL (RECT) 4 RELEASE }This is essentially a kind of stack frame, that you use just when it is helpfulBTW: studying the TACHYON kernel implementation is a great way to learn PASM.
I started with the Prop with very little SPIN, some PASM and then TACHYON.
Reading the kernel words and how they work was very enlightening to me.
And it is quite easy to extend TACHYON with loadable little PASM snippets.
But you have to edit the kernel file, which is wrapped in a little SPIN.
You can even use the PASM word to execute single PASM instructions (that need to be specified in binary ...) so you need to know what you do ... or you learn it ;-)
PASM ( val pasm -- result pasm )
one of my backgrounds is in AI ( LISP, PROLOG, SMALLTALK ) so being able to extend the language itself is a thing I love.
LISP is actually similar in some respect to FORTH but the syntax there is PREFIX instead of POSTFIX with FORTH.
And each WORD is called SYMBOL there and has an associated 'meaning' = the functions definition or the variables value.
in reading this code here again it just jumps on me ( you probably thought about this already)
( *** LOCAL VARIABLES *** ) { Saving stack parameters to local variables can simplify the stack manipulation required A specified number of parameters are removed and copied to the local variables area but first the existing local variables are pushed up so that they are saved and can be restored with a RELEASE Example of using LOCALs: pri (RECT) X4 X3 X2 HLINE X4 X3 X1 1- + X2 1- HLINE X4 X2 + 1- X3 X1 VLINE X4 X3 X1 VLINE ; \ Draw a rectangle pub RECT ( x1 y1 width height -- ) ( X4 X3 X2 X1 ) 4 LOCAL (RECT) 4 RELEASE }if we change the stack comment say tothis could indicate to a more intelligent compiler to automatically insert the
n local .... n release
and in between the arguments can be accessed like local variables Xi from stack frame.
And since the compiler is written in FORTH itself we can just adapt and extend it.
So we had extended our private language as we like.
I could do this in LISP but conventional languages like C ... hmm ???
It is a two-way street.
People that adamantly avoid Forth are missing some rather interesting and useful resources
Frankly, I suggest that newcomers focus on languages that work well on microcontrollers if they are here (involved with this forum), not ones that work well on micro-computers. There is a big difference between micro-controllers and micro-computers.. try to comprehend the difference and why. The comparative smallness is an advantage to demonstration where the real power of computing is focused.
I doubt that the Propeller will have a full-function Python anytime soon. The Propeller is a micro-controller and there is a very real subset of languages that work well with it. If you want an elaborate GUI, or a GByte file system handling a multitude of files, or you want a multi-user system; that's what a convention PC does well. Linux will provide you with a vast array of programming lanaguage -- both the newest and some of the oldest for free on your PC.
I suspect that Peter J. is referring to the community of users that just want to cut and paste without much thought when he refers to 'sealed' compiled code. It is a phase that a lot of new users go through, some even grow through it and start envisioning their own code rather than searching the web for piece to borrow.
Anything that gets you empowered to more deeply envision your software projects and to more deeply understand the physical resources of your micro-controller are a good thing. But approaches that relable programs to 'sketching', configuration to 'wiring', and users to 'artist'; tend to attract some rather superficial learners. The same thing goes for creating the smallest, cheapest microcomputer possible. Yes, it is interesting to do these things and they do get a lot of attention; but we end up with a huge crowd of people shouting 'What's next?' rather than learning skills that can be passed on to others.
If you mission is to learn computing and to mentor others along the way; it helps to be open minded to real possiblities, not just free suport and low prices and more exotic goodies.
Forth on the Propeller is excellent for some things. On the other hand, Charles Moore's Color Forth on his GA144 actually seems to be embarrasingly off in the weeds. I just can't seem to grasp the utility of it.. not enough i/o access, too many parallel processors buried in a grid format, and some other features that are just hard to unravel.
The 8 cogs with shared i/o and shared hub ram do wonderful things with Forth.. lot of surprises on how powerful the Propeller 1 can be. Add an SDcard and it is a whole tiny system that is capable of carrying its own docuemntation along with it.
That is to say that comments can be part of the code that is compiled not just random ramblings of the programmer inserted here and there.
If so, I think it's totally insane !
Am I missing a point here?
But this is what Forth is, Forth is the compiler, the language, the environment, the operating system which is why trying to compare it with a language that compiles on a PC factory is like trying to compare atoms and oranges. Forth becomes what you make it just like a few basic ingredients can become a beautiful dish or in the wrong hands just an unpalatable mess. The comment thing has been discussed before as a means to create in-system help comments but also to inform the routine how to handle the stack and whether to treat them as local variables or perhaps even just to mark the stack. Yeah, totally insane huh?!
More seriously, once you have the compiler comprehending the comments then they are not really comments any more but become part of the language syntax. You now need some other place to comment the code in your comments !
http://www.kickstarter.com/projects/214379695/micro-python-python-for-microcontrollers
That will be open sourced so we may well see Python on the Propeller much sooner than you thought. Languages that work well on micro-controllers now includes Python and Javascript along with the old favorites. The line between micro-controllers and micro-computers is getting fuzzier every day.
Here in Parallaxia we are stuck in a bit of a time warp in that respect due to the serious limitations on memory space and raw speed of the Propeller.
Well, the British will do anything for Monty Python, and the Raspberry Pi......
And so... will that Python on a microcontroller be interpreted? Or will you just end up loading binaries? I see it saying, "No set-up, no compiling, and no soldering"..... More shall soon be revealed.
It certainly do seem that Micro Python for the Propeller is available, I just have to subscribe at 1,000 Pounds sterling and pay all the startup codes.......... arh...!
I believe it was Leonardo Da Vinci that claimed that small spaces discipline the mind. The limitations in size demonstrate the simple power of a small set of programing lexicon and the limitations of speed are no limitations at all in mechanical control. You just need more of both and a big fat hard disk to 'process data'. In many ways, small microcontroller have better education outcomes for new users.. as demonstrated by the BasicStamp2.
http://www.lifequoteslib.com/authors/leonardo_da_vinci.html
You claim the lines are blurring, but I strongly select that your vision of the difference between the two is what has been blurred. It is still about deterministic control versus generalized data processing.
I like Python, but it just becomes a distraction for me on a microcontroller. Users won't learn how to exploit smallness is an efficient manner; they will just hang on to expecting Python to do it all. On the other hand, Forth is allowing to investigate all of the Propeller's PASM instructions in a context where I can learn PASM by using it.
I keep coming back to this point because I started with Forth with the desire to use it to help me to learn how to do more in PASM than the bare bones. And it is certainly empowering me to do so. I just retain the point of view that some aspects of learning about digital devices are better learned on a Propeller without an OS, and others are better learned in Linux with a full featured OS capable of massive support.
Confusing the two... blurring the lines... just muddles the novice as they don't know quite what to use.
Your Micro-Python claims the following...
Full implementation of the Python 3 grammar (but not yet all of Python's standard libraries).
My coment was about the full=function Python.. without missing standard libraries.
~~~~~~~~~~~~~~~~
Aside from all the debate, I do extremely like the Micro Python board with the micro-SDcard slot on-board. Parallax has created the MINI-Propeller that just uses 19 of the Propeller's I/O.
If Parallax were to make a MINI+SDcard Propeller, it would be a very handy up-grade. After all, there are unused i/o pins available.
Quite some time ago i did a module https://docs.google.com/document/d/1RFw-QqlgUH0kM0_6QR5j6a-IwOdAosBEu5HyC5BqIa0/pub
There are also variations of this including the PuppySolo which is featured on Tubular's OSH boards.
BTW, if the STM32F405 with DSP and floating-point for the micro Python is a "microcontroller" then what does that make the 8-bit AVRs on the Arduino? pico-controllers?
At risk of being way off topic for this thread I have to answer your concerns: The entire Micro Python system lives in the micro-controller. All you need is to talk to it via a terminal. No external compilers etc required, no loading binaries, just like Forth system. Type in your code and it runs. No you don't. That's not what it says. Micro Python is promised to be open sourced when it's creator has finished it and shipped out all the boards to the Kickstarter backers. Perhaps in January. The same deal as the Espruino Javascript project, not that they are in anyway related. When the code is released then it's down to some Propeller heads to "do the impossible" and get it running on the Prop. Yes, yes, I know, unlike Forth it will require a huge gob of external RAM. And Stalin is credited with saying "Quantity has a quality all its own". Do you mean me when you say "you"? I'm with you and Leonardo much of the time. Else why would I be tinkering with Propellers in the first place? That is a non-sequiter. The basic stamp is programmed in BASIC. It might as well be running on a machine with 4GB or RAM and a terabyte hard drive. The small physical size, low power consumption, and useful I/O is what makes it. These tiny new MCU's running Java, JavaScript, C#, Python, etc are the modern day equivalent. What I meant by "blurring" is quite simple. Deterministic control has nothing to do with it. Back in the day, a microprocessor was just a CPU. You needed ROM chips, RAM chips, I/O chips and God knows what else to get it running. Then came the "micro-controllers" where all those separate chips were subsumed into one device that could operate by itself. Both microprocessor systems and micro-controllers were capable of deterministic real-time control. Micro-controllers were very limited in memory space compared to microprocessor systems of course.
Today we have micro-controllers that are absolutely tiny physically, sip very little power, have tons of I/O and cost almost nothing but have on board memory and other resources (Floating Point) far in excess of the first IMB PC or the 8 bitters that preceded it.
That's what I call "blurring the lines" between microprocessor systems and micro-controllers. Just like BASIC on a BASIC STAMP then? Who cares? The language is there, the support for all the things you may want to do in hardware is there. Obviously a gigabyte of supporting libs is not and they would not do you any good anyway as you don't have the space. BASIC, SPIN, FORTH etc don't have any libs so what are you quibbling about?
The point of all this JS or Python on an MCU is exactly the same as it was for the BASIC STAMP or Forth. Exactly the same as the Propeller and Spin. Give people an opportunity to use the available technology in a simple way so they don't have to worry about a billion implementation details. Not to be the smallest or fastest way to get things done.
It all sounds like a good idea to me.
I am beginning to suspect you are a tout in deep cover as a Propeller user from OpenAVR.
The MicroPython does offer to port it to another microcontroller for 1000 pounds, and they will develop any library feasible for 300 pounds. Sounds like there are several cavaets to being entirely open-source and complete. And this Python could [a] never arrive at being complete, or become a very expensive Propeller platform. The developers are restricting themselves to silicon that has builting UARTs and build in ADCs, and so on. More has to be done to cobble it into a Propeller.
But at least it seems that it can control a PWM servo....
I still hold to the opinion that the limited size and resources of a micro-controller are an educational asset. Maybe they just promote more rational deployment of resources.
Why would anyone run a BasicStamp2 emulation on an Intel PC with a TByte harddisk? You miss (or ignore) the whole point of small software on small systems being the heartbeat of microcontollers.
FORTH does not need this, maybe the programmer does not need this as well - until he comes back some time later und wants to understand what his code does.
And for others who want to reuse some code stack comments are a must.
This is not the humanly readable text that explains only to a human, what the program is expected to do.
If you have a look at C for example, there most of the lines, the complete .h file and all the declarations, are actually formal comments to tell the compiler how to do the job.
The actual code, that does the logic or numeric task is only a small part of the programmer's work.
Since FORTH like some other interpreted languages (LISP, Prolog, Smalltalk, Java-Bean-Shell to name a few ...) provides mechanisms for introspection it is possible
to extend the language so code and structured comments can be examined and put to use.
But for a lean resource preserving system this is the icing on the cake and not really required.
this is a challenge which helps deepen my insight into the TF kernel
and I have some ideas that I hope I can realize.
I want to build it on the locals construct and have a few special words do the job
would be written as
Indeed FORTH might help a bit with fixed point math because I can decompose functions and interactively test their output. Below is my set_position function decomposed into three functions which I can then interactively test to see what output they produce.
\ calculates shoulder to waist distance using pythagoras' theorum. \ ( x y -- ) : pythagoras \ Save the Cartesian space coordinates. y ! x ! x @ square y @ square + dup s_w ! isqrt s_w_sqrt ! ; \ calculates shoulder angle using IK via fixed point trig. \ ( -- brad13 ) : ikshoulder \ s_w angle to centerline y @ x @ atan2 \ a1 is on the stack. \ s_w angle to humerus \ compute (_humerus_sq - ulna_sq + s_w) / (2 * humerus * s_w_sqrt) \ note that the mysterious bit shifts are to convert to fixed point. humerus_sq @ ulna_sq @ - s_w @ + 16 lshift 2 humerus @ * s_w_sqrt @ * / \ use arccos to get a2 on the stack 15 lshift clamp acos \ shoulder angle = a1 + a2 + ; \ calculates elbow angle using IK via fixed point trig. \ ( -- brad13 ) : ikelbow \ elbow angle \ compute ( humerus_sq + ulna_sq - s_w ) / ( 2 * humerus * ulna ) \ note the mysterious bit shifts convert to fixed point. humerus_sq @ ulna_sq @ + s_w @ - 16 lshift 2 humerus @ * ulna @ * / 15 lshift clamp acos ; \ SetPosition : Arm positioning routine utilizing inverse kinematics. Since \ the arm is resting on a surface Z can only be positive. Servo movement \ constraints prevent y from being negative, But X can be a signed value. \ Note: This must be called before any of the move routines to initialize \ arm state! \ x - the side to side displacement. \ y - the distance out from the base center. \ ( x y -- ) : set_position \ Save the Cartesian space coordinates and calculate s_w and s_w_sqrt pythagoras \ compute the shoulder angle ikshoulder set_shoulder \ Set the elbow ikelbow set_elbow ;-Phil
I've never found RPN or the stack to be an obstacle to using Forth. One can do small tasks in Forth without too much of a learning curve. But when I think of doing all my work - ie, an entire uC application - in Forth, I do find some merit to what Dave says about the lack of readily available libraries and code standardization/portability. It can be a bit daunting to consider having to build so many things more or less from scratch that one usually takes for granted - in, say, Spin, C, or Pascal. I have no doubt that this isn't much of a hurdle for an experienced Forth developer (often someone who is using SwiftX or MPE anyway). On the other hand, as I see the code base for Tachyon, PropForth, and pfth grow, I realize that, with Forth on the Prop at any rate, soon this may not be such an obstacle for me.