So what did you decide? Are you going to do this? Your Tachyon system is pretty fast and capable. I can't wait to see what you do with Python or Basic!
Oh, you remember my foolish impetuous post! Curse the permanence of posting on the net! As Teddy once said "It's hard to fail, but it is worse never to have tried to succeed" and tie that in with Bobby saying "Only those who dare to fail greatly can ever achieve greatly" and that's about where I am, daring to fail greatly while trying to succeed. Anyway, the trying bit is the fun part of it and I think that I could cook up a mean Basic with Tachyon anyway which will lay the groundwork for tackling Python. But when I tackle Python I won't be happy if it's slow, so my aim is to make it a Practical Propeller Python, one that you could build working apps with. Don't expect anything too soon although once I can run a few Basic test programs I will release it bit by bit.
With all due respect, I think you'd end up helping out a lot more people with a TBasic than a PyProp.
I believe you could shrinky-dink Python down to a micro-sized version, using the SD as a RAM disk cache.
However ultimately I expect performance would be so slow with the VM running on a VM idea, that you wouldn't be able to do much beyond simple LED flashing etc. Unless someone wanted to go Python dev on a PC, cross-compile and D/L to the Prop.
A tokenized or better, compiled Basic would have a significantly greater amount of real program space and far less overhead impacting performance.
Just because some people asked about Python doesn't mean much at all. Parallax had the Dart(?) for Java years ago right? How did that work out when Java was the rage?
A Basic on top of Forth is something of a genius idea though, because when the performance isn't there, you drop down to inline Forth maybe?
Thats gotta be easier for the average or beginner than dropping into PASM.
I think PyProp would yield little for your valuable time besides costly bragging right, compared to a TBasic that I and maybe some others would be willing to part with some $$ for.
I thought Peter's idea was to have either Basic or Python compile down to Tachyon byte codes so there wouldn't really be a VM on top of a VM. The compiled code would run natively on the Tacyhon VM. Anyway, if you just want a byte code compiled basic that runs on a PASM VM on the Propeller, I have one already. It's called ebasic3. I even started working on a C-like language called "notc" that also compiles to the same PASM VM. The problem is that the compiler barely fits on an unexpanded P1. It would be a little better with a >64K EEPROM. The advantage that TacyhonBasic will have is that its compiler can be written in Tachyon Forth which has a much higher code density than C.
I thought Peter's idea was to have either Basic or Python compile down to Tachyon byte codes so there wouldn't really be a VM on top of a VM. The compiled code would run natively on the Tacyhon VM.
That makes the most sense, use the proven, and highly tuned tVM as the engine, but feed it from almost any language. That is what .NET CLR does.
Anyway, if you just want a byte code compiled basic that runs on a PASM VM on the Propeller, I have one already. It's called ebasic3. I even started working on a C-like language called "notc" that also compiles to the same PASM VM. The problem is that the compiler barely fits on an unexpanded P1....
- but does the compiler really have to fit in the P1 ?
Users will always have a host holding their source code, and editor, so a host-based compiler makes more sense - it avoids trying to squeeze the compiler into the target.
The ideal system to me would be one that instead, improves on Debug, and
* Allows optional Source-Code-Stepping, so the Prop VM feeds back PC & data info.
* Allows optional native PASM support (like inline code does in C) ( debug of that would be harder...?)
Is Forth or PASM easier? What an interesting question!
Forth can be absolutely delightful - some of the best fun I've ever had programming. But I still don't trust either Forth or my abilities. There are times when a big program becomes hidebound and there seems to be no practical way to add "just one more thing." OTOH, PASM is far less constrained. As a result anything is possible. And easy.
PASM is the most simple assembly language I have ever seen.
I would agree PASM is relatively simple, but that does not always mean easy to use.
Support for Macros and Conditional Assembly are still patchy, ( in gas, but not Parallax PASM?) and the Prop core itself does not create 'clear' assembler when self-modifying code is used.
The Prop ASM level tools coould benefit from a "clarity-pass cleanup"..
- but does the compiler really have to fit in the P1 ?
Not for me but some people like to program on the target and I'll admit that I like to use interactive languages as well. I wrote xbasic, which has a PC-based compiler and a PASM VM to run the generated byte code on the Propeller. Someone suggested that they wanted something that ran on the Propeller itself so I took the xbasic VM and make a simple compiler that could generate code for it and fit on the Propeller. It actually fits in hub memory compiled with PropGCC in CMM mode but there isn't enough space left for SD card access. I'd need to use XMM mode for that.
*sigh* I can rephrase that, for those who need it
"The Prop core requirement for self-modifying code, does not create 'clear' assembler "
But a lot of useful PASM programs don't use self-modifying code explicitly. If you mostly have code in COG memory and data in hub memory then you don't need it very often. Of course, CALL and RET use it implicitly but that is largely invisible to the programmer.
Not for me but some people like to program on the target and I'll admit that I like to use interactive languages as well.
Of course interactive is nice, which is why I suggested instead improving the debug/IDE side, so you can get a lot more interactive than one-line-editing & target hosted languages.
The target does what it does best - runs the VM and a tiny debug stub, and the host has all the IDE/Tools/Build/revision/Syntax highlighted editing with hints...
Of course interactive is nice, which is why I suggested instead improving the debug/IDE side, so you can get a lot more interactive than one-line-editing & target hosted languages.
The target does what it does best - runs the VM and a tiny debug stub, and the host has all the IDE/Tools/Build/revision/Syntax highlighted editing with hints...
Good idea and maybe I can switch to Python syntax in a desperate attempt to get back on topic! :-)
Ummm... this has nothing to do with Ken's original question. Sorry about that. If anyone wants to discuss this we can move it to another thread.
I think the general python question relates to easy to learn languages, so is not strictly limited to python, and
Ken said this in #68
"We're not about to undertake another toolchain for Propeller, other than PropBASIC integration into Propeller IDE ":
which raises the question of how does (or can?) your xbasic work with this new Basic-aware Propeller IDE ?
Another angle to python requests, is it has a host-version - what are the host-version choices for Basic ?
FreeBasic appeals to me, from what I have seen. What others are there ?
A Prop-targeted language should closely follow a Host-based version for best teaching.
( Plus Peter is talking about both python and basic VM designs, and much of the python-query means "compatible with" not strictly run-python-wholly-inside-prop.... )
That "compatible with" is the angle the BBC are taking.
Many Prop developers have never experienced any other form of development other than one based upon a PC with a Spin or C compiler etc. That might seem the natural method to many in that you edit, compile, and download to the target yet I enjoy not being tied to any IDE or compiler and I am free to use my smartphone or tablet to communicate with the Prop over USB or Bluetooth or the network. The most that I need on the tablet is an editor and yet it is also possible to implement a terminal based screen editor that accesses the source files directly on the Prop.
I think something like this is where we need to be heading rather than being 20th century PC-centric dinosaurs (to the kids that is). Of course I can do all the above now in Forth but because Forth does not have any strict syntax or strict anything for that matter it is not the most suitable language to teach I must conclude. If Python despite it's seeming inefficiencies (which may be partly to do with implementation) is favored for teaching then so be it and if we can implement a Python for the Propeller that is neither slow or tied to a PC but one that kids can interact with from their iPads then Parallax has gained access to that generation. <---- This I believe is the focus, let's not lose sight of that in our discussions as technically there are always better ways of doing things but we live in the real world after all.
Talking about the real world it's funny because many kids are spending a lot of time in virtual worlds and the ultimate would be to have a virtual world where they can design and program Propellers and run them in this sim
Many Prop developers have never experienced any other form of development other than one based upon a PC with a Spin or C compiler etc. That might seem the natural method to many in that you edit, compile, and download to the target yet I enjoy not being tied to any IDE or compiler and I am free to use my smartphone or tablet to communicate with the Prop over USB or Bluetooth or the network. The most that I need on the tablet is an editor and yet it is also possible to implement a terminal based screen editor that accesses the source files directly on the Prop.
I think something like this is where we need to be heading rather than being 20th century PC-centric dinosaurs (to the kids that is). Of course I can do all the above now in Forth but because Forth does not have any strict syntax or strict anything for that matter it is not the most suitable language to teach I must conclude. If Python despite it's seeming inefficiencies (which may be partly to do with implementation) is favored for teaching then so be it and if we can implement a Python for the Propeller that is neither slow or tied to a PC but one that kids can interact with from their iPads then Parallax has gained access to that generation. <---- This I believe is the focus, let's not lose sight of that in our discussions as technically there are always better ways of doing things but we live in the real world after all.
Talking about the real world it's funny because many kids are spending a lot of time in virtual worlds and the ultimate would be to have a virtual world where they can design and program Propellers and run them in this sim
Can we start another thread to talk about the Tacyhon VM and how it might be applied to other languages than Forth. It seems to me that you started a thread about that some time ago but I can't seem to find it. In particular, I'm interested in how your virtual memory system works.
Many Prop developers have never experienced any other form of development other than one based upon a PC with a Spin or C compiler etc. That might seem the natural method to many in that you edit, compile, and download to the target yet I enjoy not being tied to any IDE or compiler and I am free to use my smartphone or tablet to communicate with the Prop over USB or Bluetooth or the network. The most that I need on the tablet is an editor and yet it is also possible to implement a terminal based screen editor that accesses the source files directly on the Prop.
I think something like this is where we need to be heading rather than being 20th century PC-centric dinosaurs (to the kids that is).
I'm not quite following ?
I can load Compiler tools fine onto my small and cheap HP Stream 7 tablet, and they compile & download fine.
However, for serious code development, that cheap tablet needs a Keyboard and mouse added, and voila, the tablet has just morphed into a 'PC'. Raspberry Pi offerings, run a Full OS, and keyboard / Mouse / Screen, so they are also morphed to a 'PC'.
When I develop, I expect to be able to open PDFs and cut and paste between PDF and Source code.
Sometimes also open emails.
Target hosting on parts as small as a Prop, is a shrinking niche, and one that will always fall short.
Cheap tablets are actually making that ever less viable.
Smarter to fix one of the Prop's large blind-spots, which is lack of decent debug [Source Step, Break Points, symbol watch], and make that drive the interactive
mentioned above.
When I develop, I expect to be able to open PDFs and cut and paste between PDF and Source code.
That hardly ever works -- especially with indent-sensitive code like Spin or Python. In my class handouts that include code listings, I always provide a text file for the code on the class website, since cutting and pasting from the handout PDFs is nearly always a disaster.
Open terminal on whatever computer you are working on, and then open whatever it is you want to copy from, and then paste it into the terminal, done, next.
I'm not quite following ?
I can load Compiler tools fine onto my small and cheap HP Stream 7 tablet, and they compile & download fine.
However, for serious code development, that cheap tablet needs a Keyboard and mouse added, and voila, the tablet has just morphed into a 'PC'. Raspberry Pi offerings, run a Full OS, and keyboard / Mouse / Screen, so they are also morphed to a 'PC'.
When I develop, I expect to be able to open PDFs and cut and paste between PDF and Source code.
Sometimes also open emails.
Target hosting on parts as small as a Prop, is a shrinking niche, and one that will always fall short.
Cheap tablets are actually making that ever less viable.
Smarter to fix one of the Prop's large blind-spots, which is lack of decent debug [Source Step, Break Points, symbol watch], and make that drive the interactive
mentioned above.
True, the HP tablet works fine, but it is still an Intel CPU based Windows PC. The point about "PC centric" is more about the tools that only run on PCs, and more correctly only on Windows.
As for all this stuff about a lack of decent debug I don't buy it. While you are locked into this PC centric compile,download,run way of doing things you are in need of some interaction with the target which might be expressed as a debugger. So instead of interacting with the language/target you end up interacting with the debugger. When I use Tachyon on the Prop I get immediate results and I can build on that. Many times all I need to do to "debug" is to type a one-liner or pass parameters to a function manually. I am target hosting now on a part as small as the Prop, it's a growing niche, having small embedded real-time microcontrollers capable of interactive development.
.. So instead of interacting with the language/target you end up interacting with the debugger.
?? Err, yes, that is exactly the point of the debugger
It gives you a picture of the target, and what the target isactually doing, not what you hoped it might be doing.
When doing embedded design, there is no substitute for the real hardware as a final test vehicle.
There are also some impressive simulators, that are very responsive learning vehicles too, and are good for getting fundamental SW flows solved, and the total overview they give, helps students picture what is actually going on at the bit-level. That level of GUI is not possible on type-a-command target hosted interface.
Those are the tools most MCUs have, and it is common for MCU developers to use more than one vendor's parts.
I'll admit to talking from a position of ignorance here. However when I look at Forth from Peter's thread it looks somewhat higher level than assembler.
Odd yes, but less need for forcing the kids into hex, binary etc, as we were discussing earlier. Again, its just an option, as the inclusion of inline PASM would too.
I'm still tinkering with Python for work scripts, and like it. However the majority of its usefulness is all the functions and methods and available code. Little of that is likely to be available or of use on a small-ish uC. Overall, it seems like we're doing the same thing with Python as was done with Java last decade. Though Python is definately worthy in this case.
I fail to see the need to in essence cripple Python just to get it too run natively on the Prop, and not use a pad or pc to use the full benefit of its memory/power to x-compile to the Prop. But it might be a neat trick, and Peter can definately pull it off.
Target hosting on parts as small as a Prop, is a shrinking niche,...
On the other hand we recently got JavaScript self-hosted on an MCU. A project that has met it's funding goal four or five times over on two incarnations on Kickstater.
Then there is the MicroPython on similar MCU again surpassing it's funding goal by a factor of six.
Seems there are a lot of people out there who are really into this self hosting idea.
Debuggers: Has anyone actually ever found a bug with a debugger? Was the debugger really needed to find that bug?
Well of course I have but in general my experience with debuggers and in circuit emulators is that by the time a bug is hard enough to find that one needs a debugger then the debugger just gets in the way and hides the bug!
On the other hand we recently got JavaScript self-hosted on an MCU. A project that has met it's funding goal four or five times over on two incarnations on Kickstater.
Then there is the MicroPython on similar MCU again surpassing it's funding goal by a factor of six.
Yup and those MCUs are nowhere near the Prop, which just reinforces my case.
They are also not hosting editors, PDF readers or browsers, just running small subset script engines, and BASIC was 'self-hosted' that way on much simpler micros, ~30 years ago.
Comments
Oh, you remember my foolish impetuous post! Curse the permanence of posting on the net! As Teddy once said "It's hard to fail, but it is worse never to have tried to succeed" and tie that in with Bobby saying "Only those who dare to fail greatly can ever achieve greatly" and that's about where I am, daring to fail greatly while trying to succeed. Anyway, the trying bit is the fun part of it and I think that I could cook up a mean Basic with Tachyon anyway which will lay the groundwork for tackling Python. But when I tackle Python I won't be happy if it's slow, so my aim is to make it a Practical Propeller Python, one that you could build working apps with. Don't expect anything too soon although once I can run a few Basic test programs I will release it bit by bit.
I believe you could shrinky-dink Python down to a micro-sized version, using the SD as a RAM disk cache.
However ultimately I expect performance would be so slow with the VM running on a VM idea, that you wouldn't be able to do much beyond simple LED flashing etc. Unless someone wanted to go Python dev on a PC, cross-compile and D/L to the Prop.
A tokenized or better, compiled Basic would have a significantly greater amount of real program space and far less overhead impacting performance.
Just because some people asked about Python doesn't mean much at all. Parallax had the Dart(?) for Java years ago right? How did that work out when Java was the rage?
A Basic on top of Forth is something of a genius idea though, because when the performance isn't there, you drop down to inline Forth maybe?
Thats gotta be easier for the average or beginner than dropping into PASM.
I think PyProp would yield little for your valuable time besides costly bragging right, compared to a TBasic that I and maybe some others would be willing to part with some $$ for.
It is your time however.
In the case of PASM now, as implemented on P1? Maybe. It's debatable for sure.
In the case of PASM as we last saw discussed being implemented on P2? No way.
PASM is the most simple assembly language I have ever seen. And very easy to use when presented as it is in Spin DAT blocks.
I am famous for bashing on Forth. But that is not my point here.
- but does the compiler really have to fit in the P1 ?
Users will always have a host holding their source code, and editor, so a host-based compiler makes more sense - it avoids trying to squeeze the compiler into the target.
The ideal system to me would be one that instead, improves on Debug, and
* Allows optional Source-Code-Stepping, so the Prop VM feeds back PC & data info.
* Allows optional native PASM support (like inline code does in C) ( debug of that would be harder...?)
Forth can be absolutely delightful - some of the best fun I've ever had programming. But I still don't trust either Forth or my abilities. There are times when a big program becomes hidebound and there seems to be no practical way to add "just one more thing." OTOH, PASM is far less constrained. As a result anything is possible. And easy.
I would agree PASM is relatively simple, but that does not always mean easy to use.
Support for Macros and Conditional Assembly are still patchy, ( in gas, but not Parallax PASM?) and the Prop core itself does not create 'clear' assembler when self-modifying code is used.
The Prop ASM level tools coould benefit from a "clarity-pass cleanup"..
Here is a link to xbasic: https://github.com/dbetz/xbasic
The ebasic3 code is in the propgcc repository under the demos directory.
Ummm... this has nothing to do with Ken's original question. Sorry about that. If anyone wants to discuss this we can move it to another thread.
"The Prop core requirement for self-modifying code, does not create 'clear' assembler "
Of course interactive is nice, which is why I suggested instead improving the debug/IDE side, so you can get a lot more interactive than one-line-editing & target hosted languages.
The target does what it does best - runs the VM and a tiny debug stub, and the host has all the IDE/Tools/Build/revision/Syntax highlighted editing with hints...
I think the general python question relates to easy to learn languages, so is not strictly limited to python, and
Ken said this in #68
"We're not about to undertake another toolchain for Propeller, other than PropBASIC integration into Propeller IDE ":
which raises the question of how does (or can?) your xbasic work with this new Basic-aware Propeller IDE ?
Another angle to python requests, is it has a host-version - what are the host-version choices for Basic ?
FreeBasic appeals to me, from what I have seen. What others are there ?
A Prop-targeted language should closely follow a Host-based version for best teaching.
( Plus Peter is talking about both python and basic VM designs, and much of the python-query means "compatible with" not strictly run-python-wholly-inside-prop.... )
That "compatible with" is the angle the BBC are taking.
Personally, the self modify in P1 is pretty clear. It is self modify itself that can be unclear.
However, the very simple nature of the Prop is also due to a lack of complexity too.
In P2, we muddied that all up quite a bit, and one simple got traded for a different kind of simple.
...though the higher math functions were brilliant. Hope we get those in some awesome form.
Clear is kind of arbitrary.
I think something like this is where we need to be heading rather than being 20th century PC-centric dinosaurs (to the kids that is). Of course I can do all the above now in Forth but because Forth does not have any strict syntax or strict anything for that matter it is not the most suitable language to teach I must conclude. If Python despite it's seeming inefficiencies (which may be partly to do with implementation) is favored for teaching then so be it and if we can implement a Python for the Propeller that is neither slow or tied to a PC but one that kids can interact with from their iPads then Parallax has gained access to that generation. <---- This I believe is the focus, let's not lose sight of that in our discussions as technically there are always better ways of doing things but we live in the real world after all.
Talking about the real world it's funny because many kids are spending a lot of time in virtual worlds and the ultimate would be to have a virtual world where they can design and program Propellers and run them in this sim
I can load Compiler tools fine onto my small and cheap HP Stream 7 tablet, and they compile & download fine.
However, for serious code development, that cheap tablet needs a Keyboard and mouse added, and voila, the tablet has just morphed into a 'PC'. Raspberry Pi offerings, run a Full OS, and keyboard / Mouse / Screen, so they are also morphed to a 'PC'.
When I develop, I expect to be able to open PDFs and cut and paste between PDF and Source code.
Sometimes also open emails.
Target hosting on parts as small as a Prop, is a shrinking niche, and one that will always fall short.
Cheap tablets are actually making that ever less viable.
Smarter to fix one of the Prop's large blind-spots, which is lack of decent debug [Source Step, Break Points, symbol watch], and make that drive the interactive
mentioned above.
-Phil
Open terminal on whatever computer you are working on, and then open whatever it is you want to copy from, and then paste it into the terminal, done, next.
Totally agreed on PDF copy paste. Hate it.
True, the HP tablet works fine, but it is still an Intel CPU based Windows PC. The point about "PC centric" is more about the tools that only run on PCs, and more correctly only on Windows.
As for all this stuff about a lack of decent debug I don't buy it. While you are locked into this PC centric compile,download,run way of doing things you are in need of some interaction with the target which might be expressed as a debugger. So instead of interacting with the language/target you end up interacting with the debugger. When I use Tachyon on the Prop I get immediate results and I can build on that. Many times all I need to do to "debug" is to type a one-liner or pass parameters to a function manually. I am target hosting now on a part as small as the Prop, it's a growing niche, having small embedded real-time microcontrollers capable of interactive development.
It gives you a picture of the target, and what the target isactually doing, not what you hoped it might be doing.
When doing embedded design, there is no substitute for the real hardware as a final test vehicle.
There are also some impressive simulators, that are very responsive learning vehicles too, and are good for getting fundamental SW flows solved, and the total overview they give, helps students picture what is actually going on at the bit-level. That level of GUI is not possible on type-a-command target hosted interface.
Those are the tools most MCUs have, and it is common for MCU developers to use more than one vendor's parts.
Odd yes, but less need for forcing the kids into hex, binary etc, as we were discussing earlier. Again, its just an option, as the inclusion of inline PASM would too.
I'm still tinkering with Python for work scripts, and like it. However the majority of its usefulness is all the functions and methods and available code. Little of that is likely to be available or of use on a small-ish uC. Overall, it seems like we're doing the same thing with Python as was done with Java last decade. Though Python is definately worthy in this case.
I fail to see the need to in essence cripple Python just to get it too run natively on the Prop, and not use a pad or pc to use the full benefit of its memory/power to x-compile to the Prop. But it might be a neat trick, and Peter can definately pull it off.
Then there is the MicroPython on similar MCU again surpassing it's funding goal by a factor of six.
Seems there are a lot of people out there who are really into this self hosting idea.
Debuggers: Has anyone actually ever found a bug with a debugger? Was the debugger really needed to find that bug?
Well of course I have but in general my experience with debuggers and in circuit emulators is that by the time a bug is hard enough to find that one needs a debugger then the debugger just gets in the way and hides the bug!
Even printf is a debugger, just a very primitive one.
That's kind of stretching the point though.
They are also not hosting editors, PDF readers or browsers, just running small subset script engines, and BASIC was 'self-hosted' that way on much simpler micros, ~30 years ago.