Get the most out of your Propeller chip now!
Peter Jakacki
Posts: 10,193
I'm doing some floating point input and output number conversion support at the moment but having a look at how far Tachyon has come now, even I am amazed. Not only is it very fast and compact, not requiring any special memory enhancement etc but it is also has such a very wide suite of functions that really propels the Propeller to somewhere where it has not been before. Once I polish up the interface on V3 then there's a whole world of functionality at your fingertips, literally. Just say "do" and it does. Who woulda thunk it.
In the last few days I have added the ability to incorporate OBEX ROMS, the PASM part of an object into EEPROM or SD card and invoke it by name at runtime. The floating point ROM will probably be standard and now I also have LMM support especially after I update the assembler. Having a 4-port serial ROM is great too but there are many more ROMs yet to be incorporated or simply added via the assembler that runs in Tachyon itself.
But perhaps the problem is it doesn't do it the same way as other tools do, but if it were done the same way then I'm very sure it wouldn't do what it does either. So the point is if you want the functionality come on-board and try it, it's fun, and just as you went out on a limb and learnt about the Prop, as different a CPU from any other CPU that others just wouldn't try it and turned their noses up at it, but you did, so try Tachyon I say. Even a little bit of positive feedback or suggestions spurs me on just as it has the last couple of days and then we have even more features. Don't give up on the P1, just try another tool with it. Got a larger EEPROM or SD card? Man! you can have the whole kit and caboodle right there.
btw, I'm not trying to detract from other tools, but I get a little excited when I can do so much with this one already, and I'm not talking about how good a "language" is, I'm talking about how effective and fun a tool is.
In the last few days I have added the ability to incorporate OBEX ROMS, the PASM part of an object into EEPROM or SD card and invoke it by name at runtime. The floating point ROM will probably be standard and now I also have LMM support especially after I update the assembler. Having a 4-port serial ROM is great too but there are many more ROMs yet to be incorporated or simply added via the assembler that runs in Tachyon itself.
But perhaps the problem is it doesn't do it the same way as other tools do, but if it were done the same way then I'm very sure it wouldn't do what it does either. So the point is if you want the functionality come on-board and try it, it's fun, and just as you went out on a limb and learnt about the Prop, as different a CPU from any other CPU that others just wouldn't try it and turned their noses up at it, but you did, so try Tachyon I say. Even a little bit of positive feedback or suggestions spurs me on just as it has the last couple of days and then we have even more features. Don't give up on the P1, just try another tool with it. Got a larger EEPROM or SD card? Man! you can have the whole kit and caboodle right there.
btw, I'm not trying to detract from other tools, but I get a little excited when I can do so much with this one already, and I'm not talking about how good a "language" is, I'm talking about how effective and fun a tool is.
Comments
Cheers from Texas, mate!
Long time since I've been to Dallas, a lot has changed for sure but living on-site never improves. Then again last time I was in Dallas I was wowing a bunch of engineers with lots of Forth stuff, doing the impossible with as little as possible while downing buds and getting ma necktie cut at the Trail Dust etc etc.
I love getting a new board made up and being able to immediately interact with it bringing various parts of it to life, that's a lot of fun there that I just don't get when I work through a compiler on a PC, even with Spin. So, you will have lots of fun and even more fun once you start thinking Forth, or more correctly, just stop comparing it with what you've been taught, if you can
This needs repeating:
"Forth is a programming environment for creating application-oriented
languages." Leo Brodie
HERE is the tool I'm using to check the results from the F32 ROM. Look forward to the Float-IO so my brain doesn't pop. Really nice work.
Now, this needs repeating. Anyone can help with documentation but where they can really help is just by saying "help". That is directing attention to a specific problem so holes in the documentation can be identified and sometimes there are things to fix up in Tachyon too. When you teach a bunch of students you get to see their assignments, their work, to look over their shoulder, but very rarely do I even get a glimpse of what anyone is trying to do in Tachyon. That leaves me in the dark in respects to where that "student is coming from" and as we know teaching is not just about knowing but also knowing what the student knows so adjustments can be made to both the way we teach and also what we teach. I'm glad to help, but don't be embarrassed as that is one sure impediment to learning and I don't get to learn about what I need to teach.
Hi Heater,
Language in this context does not mean 'programming language' like C/Pascal/... with pages of BNF to describe the syntax.
It is more like natural languages.
You speak english - yes - compiled or interpreted??
See, this is not relevant at this level.
In FORTH everything is just a WORD seperated by a SPACE (usually). So EVERY sequence of characters seperated by space is a WORD. Even , . ; : ++ >> <hi> >right <left ... /// are all just words. IF THEN etc of course as well.
Now - since there is nothing more to do at the syntax level we can focus on the WORDs themselves.
So the syntax for english, spanish, french is basically the same - and very similat to FORTH.
That's why btw. there is a Forth-DICTIONARY, where all words are listed.
So the term 'application-oriented languages' just means to build an application specific vocabulary.
Peter gives many examples for this in his code and examples.
A nice one is the VGA-driver.
He defines a PAPER, a PEN, some colors RED, GREEN, BLUE ..., maybe some pen styles FAT THIN NORMAL
then you can say:
RED PAPER THIN GREEN PEN
and this is the new application specific language you then use to 'talk' about the things you want to do.
So in this respect Forth is more like a natural language than a defined conputerlanguage, most readers here think of first.
That much of the workings of Forth I do understand to some level. Which is why I never understood "Forth is a programming environment for creating application-oriented
languages." To my mind I don't care how many words you add to a Forth dictionary or what symbols they are allowed to contain, you are still working in the Forth language, there is no new language magically coming out of this.
Of course one could say the same about C or whatever, add as many new functions and classes as you like for your application, you are still working in C, C++, Java, C# whatever it is.
I'm also not comfortable with the supposed similarity with natural languages. A language like English has a very complex syntax/grammar, nothing like Forth. By contrast Finnish has a very different structure.
The magic thing about Forth, to me at least, is that it seems to have the minimum syntax required to be a high level programming language.
I agree. It has the feel of programming in assembly with a macros for constructs like: if, while, for, etc. While you create new macros as you go, you're still programming in the same language.
I'm not knocking FORTH as I actually quite like it. It and Lisp are probably my two favorite programming languages. Although I don't use either of them on a daily basis.
Read Peter's code examples. Stop looking at the syntax and read the words, other languages force you to read the syntax and interpret the language syntax into meaning. In forth/tachyon the words themselves are the meaning of the application and its actions. Never try to program in Forth, try to make the words in Forth that the application requires to perform the actions.
Really it is a very hard thing to do and people are inherently lazy so they won't take the time to struggle, I won't blame them. Forth is a struggle until it is not, then it's simple. But if forces you to leave your safe space of procedural programming completely in order to be effective.
Read the code Heater. Better just keep looking at all the stuff that P1 can do at the same time with Tachyon loaded up full tilt and be amazed. Hat tip to Peter for the ROMs as of late, opens up all of OBEX asm code.
Interpreted and multithreaded don't alter a language's programming paradigm. Programming paradigms include: declarative, functional, imperative (including procedural), and symbolic. In imperative programming you describe how the computer will accomplish a task and Forth falls into that family.
You guys are just being picky, you are both smart enough to realize the major differences, I'm gonna just leave it at this an go back to working on my projects using the new F32 ROM. F32 hat tip lonesock et al.
" leading to a programming style that's a bit less procedural than typical C functions"
The key is some people will never overcome the "bit less" part because it is not C.
All the kings OBEX objects cannot put together what is native in Tachyon on the P1 fully loaded and that is do to using FORTH, not C, not Ada, not Pascal, not Basic and OMG not Java. And now there is gobs of memory for a poor Forth/Tachyon programmer like me to waste. Speaking of wasting, those Saturated vapor pressure equations are waiting for me and the F32 ROM, I was loath to translate those to fixed point, if I even could!
One last note, I use CSS, HTML/5, Jquery, javascript, JUI, Backbone, Marionette, CodeIgnitor, C# and manage a large SAP installation professionally, I know extreme differences when I see them.
FORTH/Tachyon is extremely different.
dp
Yep, being picky.
If we all use the same terminology the we stand a chance of understanding what is said. It's confusing when people or groups of people use terminology in different ways. We I have to find out what each group means when it uses a particular term to understand what they are talking about.
Sorry for the "pick", thanks for the clarification.
When I first evaluated Forth for use in POS terminals I was designing at the time I wrote this simple bit of code a bit like this:
I sure didn't end up writing my software that way but it convinced me that I had a very powerful tool that could be repurposed to suit the application. In this example it no longer looked like Forth, I found what Leo Brodie meant by "Forth is a programming environment for creating application-oriented languages". In my simple example I now had an application-oriented language although the internals were still Forth, the application was also still Forth and was code in that I could combine it this way:
Thereafter I could just enter SPECIAL rather than item by item or I could also define: and simply say 3 SPECIALS.
I found the cheese and it all makes sense to me. I like cheese.
Only we are having a quibble over the statement that Forth is not a procedural programming language. Which it clearly is.
Peter is right, academics can invent whatever classifications they like and then debate what belongs where.
On the other hand, us normal people get confused when common terminology is used in uncommon ways.
That's all.
I've posted whole projects that were implemented commercially a while back. However how it is done in Forth or Tachyon isn't much different to how we do it in any other language. But typically the "main" startup function has to be turnkey and so checks for factory/cold/warm boot, sets defaults, inits modules and devices, launches tasks, and normally sits in a loop although in Forth we leave the console available. But bear in mind that we have the AUTORUN word so I can specify the turnkey word at boot and of course there is the BACKUP word.
I was a little confused by your question because I thought the answer was obvious but I just got to thinking that many people have been exposed to evaluation or toy versions of Forth, you know, the ones that somebody writes just to say they have Forth running, but the real purpose of writing a Forth is normally to get a board running an application. So there is a lot more to it than just having the language basics and it doesn't matter how standard the implementation is, it is of no use unless it can get the board and application running. Tachyon was not written as an exercise in writing a Forth, I had to "forth" myself to do it just so I could write applications more effectively that were also more efficient.
When I find that link to an older project I will paste it back in here.
EDIT: couldn't find the link but here is a project page of a controller I did for a friend of a friend in a very early version of Tachyon and the VGA was run off a simple RS485 network to another Prop with a keypad. The newer versions of Tachyon would do all this so much better again
UPDATED LINK TO A BETTER VERSION
There's nothing wrong with Forth, it is quite unique in many ways, and I like the language. However, it is clearly a general purpose imperative languages, so I felt that need to clarify that point.
As I have said before Peter, I am truly amazed at what you have achieved!
hehe, yes, the stack. But that is a matter of how we factor things and very rarely do I need to worry about where the parameter is. That is also why I refuse to implement the traditional PICK and ROLL words which just encourage more of this deep stack manipulation practices.
As for optimization, Tachyon doesn't have to do any as Tachyon itself is already optimized for the Propeller. Also with library support this is what C is after all, pretty much an assembler, but the libraries make C see. Rather than have all-purpose libraries the philosophy in Forth is to just implement what you need and "extend" the language. As you have probably seen the language is very extended indeed so these could be viewed as the "libraries built-in" and available at runtime.
I've definitely used that, and it's a specific case of a more general benefit of Forth.
In C a function call involves a prologue of pushing arguments onto the stack, making the call, pushing the return, and finally the epilogueof popping the arguments. It's a bit of a production which makes function calls more expensive than inline code. Although many modern C compilers will use register linkage if a function is small and doesn't call another function.
In Forth you are always working with the stack, so there's much less of a penalty when calling another function (word in Forth semantics), particularly when that function consumes the input arguments as this saves the cost of the function epilogue. This does encourage breaking code into smaller chunks and reusing those chunks, hence the smaller size.