Although I guess you're probably suggesting that Parallax create P2BASIC since people would be hesitant to use a language not fully supported by Parallax?
That's it. Chip likes creating bytecode interpreters -- he's done that for a long time. There are elements in the P2 that support bytecode interpreters which is why Spin2 is so much faster than Spin1. Since the interpreter code is downloaded with the bytecodes, it could be any language. An update of PBASIC makes sense. That said, if the project actually happens, it would be wise to look at other flavors of BASIC for good ideas.
What makes the most sense is to use the existing spin2 bytecode interpreter as the back-end, and just write different front-ends to take spin2, basic, etc, and compile to the spin2 bytecode interpreter.
I’d like to see if python could be compiled to the spin2 bytecode too.
Alas, there never seems to be enough free time these days
What makes the most sense is to use the existing spin2 bytecode interpreter as the back-end, and just write different front-ends to take spin2, basic, etc, and compile to the spin2 bytecode interpreter.
In principle fastspin could output spin2 bytecodes (it already has back-ends for C and assembly output). If I win the lottery, and/or if Parallax comes into a bunch of money and could support this as a project, maybe it could happen...
I’d like to see if python could be compiled to the spin2 bytecode too.
No, alas, it cannot, or at least not in any useful way. Python is a dynamically typed language, which means that it works very differently from statically typed languages like Spin or C. For example, the meaning of a Python expression like "a+b" cannot in general be determined at compile time, it has to be figured out by the interpreter at run time.
There is a restricted subset of Python, RPython, in which figuring out the types is supposed to be possible. I've thought about implementing something like that for the P2, but I'm not sure how useful it would be. I suspect everyone will want full Python (or at least MicroPython).
What makes the most sense is to use the existing spin2 bytecode interpreter as the back-end, and just write different front-ends to take spin2, basic, etc, and compile to the spin2 bytecode interpreter.
Maybe -- but the ability to download an interpreter engine with the bytecodes means you don't have to crowbar one thing into another. To your point, though, PBASIC 2.5 was a big improvement over PBASIC 2.0 (adding things like IF-THE-ELSE and CASE) by using the existing PBASIC bytecodes.
If I win the lottery...
I wanted a Coke so I popped out to the convenience store. I bought a lotto ticket with my Coke. If I win, we'll talk!
What makes the most sense is to use the existing spin2 bytecode interpreter as the back-end, and just write different front-ends to take spin2, basic, etc, and compile to the spin2 bytecode interpreter.
In principle fastspin could output spin2 bytecodes (it already has back-ends for C and assembly output). If I win the lottery, and/or if Parallax comes into a bunch of money and could support this as a project, maybe it could happen...
I’d like to see if python could be compiled to the spin2 bytecode too.
No, alas, it cannot, or at least not in any useful way. Python is a dynamically typed language, which means that it works very differently from statically typed languages like Spin or C. For example, the meaning of a Python expression like "a+b" cannot in general be determined at compile time, it has to be figured out by the interpreter at run time.
There is a restricted subset of Python, RPython, in which figuring out the types is supposed to be possible. I've thought about implementing something like that for the P2, but I'm not sure how useful it would be. I suspect everyone will want full Python (or at least MicroPython).
Python
I am wondering here if python for micros isn't a bit different to python for pcs. Python for pcs can use lots of libraries that are totally irrelevant for python running on a micro. Such things as the support of large databases and maths routines such as pandas and dataframes including analysis of these are not practical on a micro. So, perhaps a more pragmatic approach to limiting the types and a consistent forcing of them might be in order.
IMHO, much of the attraction to python (from the micro perspective) is the language syntax. For this approach, it is just another syntax that could be pre-compiled to a bytecode.
PS I'll put you on my list for if I win the lottery, although it's not that likely as someone informed me you need a ticket to win
What makes the most sense is to use the existing spin2 bytecode interpreter as the back-end, and just write different front-ends to take spin2, basic, etc, and compile to the spin2 bytecode interpreter.
Maybe -- but the ability to download an interpreter engine with the bytecodes means you don't have to crowbar one thing into another. To your point, though, PBASIC 2.5 was a big improvement over PBASIC 2.0 (adding things like IF-THE-ELSE and CASE) by using the existing PBASIC bytecodes.
I am seeing a lot of similarities between a number of competing languages that could use the same (or similar) bytecodes. The syntax of these languages, while seemingly quite different, all have the same basis. Things like subroutines (whatever they are called in the particular language), if/else/elseif/elif statements, case statements, repeat statements, etc, all have an underlying similar format if you remove the begin/end or { } or indentation.
I'm almost of the opinion that a pre-pass could convert spin2, basic, python, and much of C to an intermediate code for compilation to the same bytecode. Fastspin can output to pasm although I would like to see the option (which may come later) to output to use the spin2 interpreter, or even a different dialect of a bytecode interpreter. I say this because I see the benefit of having tight compiled bytecode, and I wish for it to be as compatible as possible to pnut/proptool.
I wanted a Coke so I popped out to the convenience store. I bought a lotto ticket with my Coke. If I win, we'll talk!
It doesn't seem like that would meet your requirements. It would still be a non-Parallax tool that just happened to target Parallax-defined byte code. The compiler still wouldn't be "Official Parallax Software". In fact, I don't see any difference between this and what Eric already has which is a compiler that targets a Parallax-defined hardware instruction set. Of course, I guess you were both kidding...
What makes the most sense is to use the existing spin2 bytecode interpreter as the back-end, and just write different front-ends to take spin2, basic, etc, and compile to the spin2 bytecode interpreter.
In principle fastspin could output spin2 bytecodes (it already has back-ends for C and assembly output). If I win the lottery, and/or if Parallax comes into a bunch of money and could support this as a project, maybe it could happen...
I’d like to see if python could be compiled to the spin2 bytecode too.
No, alas, it cannot, or at least not in any useful way. Python is a dynamically typed language, which means that it works very differently from statically typed languages like Spin or C. For example, the meaning of a Python expression like "a+b" cannot in general be determined at compile time, it has to be figured out by the interpreter at run time.
There is a restricted subset of Python, RPython, in which figuring out the types is supposed to be possible. I've thought about implementing something like that for the P2, but I'm not sure how useful it would be. I suspect everyone will want full Python (or at least MicroPython).
If RPython can use all 8 cogs directly, than this would be the way to go! Python is intended as the beginner language by Parallax, beginners cannot use Python with precompiled code of a second language! If the whatever ?Python cannot use all 8 cogs directly in this language, than it is not clever at all to use the 14$ P2 together with it.
Regarding inline assembler:
C was invented with the goal to have a compiler which is so powerful regarding hardware control, that assembler is not necessary in most cases any more. This is the reason, why C exists.
Making a C bytecode interpreter would be a waste of ressources, when you want to have the sense of C. Of course a full C with floating point support and string support is necessary. When spin was invented very simple basic was state of the art for mc s. Now there are controllers with double precision floating point hardware support. Spin is incomplete in comparison to actual possibilities.
I think it would be good to prove that you can write demanding drivers using a compiler with realworld examples. DMX512, WS2812 and DHT22 are the examples with high fixed clock speeds and no handshake known to me. i2s perhaps and video drivers. It was very impressing for me when I saw a video driver written in PropBasic for P1.
I do not think that Parallax customers want to use Assembler, if the application can be written in a compiled language. At least their number will be very much smaller, if they have to use an inline assembler.
Comments
I’d like to see if python could be compiled to the spin2 bytecode too.
Alas, there never seems to be enough free time these days
Ray
No, alas, it cannot, or at least not in any useful way. Python is a dynamically typed language, which means that it works very differently from statically typed languages like Spin or C. For example, the meaning of a Python expression like "a+b" cannot in general be determined at compile time, it has to be figured out by the interpreter at run time.
There is a restricted subset of Python, RPython, in which figuring out the types is supposed to be possible. I've thought about implementing something like that for the P2, but I'm not sure how useful it would be. I suspect everyone will want full Python (or at least MicroPython).
I wanted a Coke so I popped out to the convenience store. I bought a lotto ticket with my Coke. If I win, we'll talk!
I am wondering here if python for micros isn't a bit different to python for pcs. Python for pcs can use lots of libraries that are totally irrelevant for python running on a micro. Such things as the support of large databases and maths routines such as pandas and dataframes including analysis of these are not practical on a micro. So, perhaps a more pragmatic approach to limiting the types and a consistent forcing of them might be in order.
IMHO, much of the attraction to python (from the micro perspective) is the language syntax. For this approach, it is just another syntax that could be pre-compiled to a bytecode.
PS I'll put you on my list for if I win the lottery, although it's not that likely as someone informed me you need a ticket to win
I'm almost of the opinion that a pre-pass could convert spin2, basic, python, and much of C to an intermediate code for compilation to the same bytecode. Fastspin can output to pasm although I would like to see the option (which may come later) to output to use the spin2 interpreter, or even a different dialect of a bytecode interpreter. I say this because I see the benefit of having tight compiled bytecode, and I wish for it to be as compatible as possible to pnut/proptool.
If RPython can use all 8 cogs directly, than this would be the way to go! Python is intended as the beginner language by Parallax, beginners cannot use Python with precompiled code of a second language! If the whatever ?Python cannot use all 8 cogs directly in this language, than it is not clever at all to use the 14$ P2 together with it.
C was invented with the goal to have a compiler which is so powerful regarding hardware control, that assembler is not necessary in most cases any more. This is the reason, why C exists.
Making a C bytecode interpreter would be a waste of ressources, when you want to have the sense of C. Of course a full C with floating point support and string support is necessary. When spin was invented very simple basic was state of the art for mc s. Now there are controllers with double precision floating point hardware support. Spin is incomplete in comparison to actual possibilities.
I think it would be good to prove that you can write demanding drivers using a compiler with realworld examples. DMX512, WS2812 and DHT22 are the examples with high fixed clock speeds and no handshake known to me. i2s perhaps and video drivers. It was very impressing for me when I saw a video driver written in PropBasic for P1.
I do not think that Parallax customers want to use Assembler, if the application can be written in a compiled language. At least their number will be very much smaller, if they have to use an inline assembler.