If I were king, that's what I would do with the money.
I despair.
Back in the early 1980's the microprocessor hit the world. In the form of those 8 bit C64's. Sinclair Spectrums and many others.
Soon there was a big push that all kids should learn about this new fangled computer technology and programming. Everyone could see it was the way of the future.
There were school education initiatives, there was the BBC Micro pushed into all schools. All kind or projects going on. No idea if this happened in the sates or not. Everyone was going to be up to speed with this new technology.
Since then I have seen MS and Apple pushing all kind of their products into schools as part of this educational plan or that. At enormous cost. And to no effect.
This is over three decades. And then. Eben Upton notices that kids trying to get into university have no idea about anything to do with computing or programming at all.
So he introduces the Raspberry Pi to fix that situation.
It seems to me that you could probably implement a full expression parser without giving up the efficiency of your current code generator. Just allocate a few COG locations for temporary variables and allocate them as needed to hold the results of nested subexpressions. Since you don't support recursion or even function calls as operands in an expression, you don't really need a dynamic stack. Just use the array of temporary COG locations as if it were a stack and allocate space for temporaries at compile time.
It seems to me that you could probably implement a full expression parser without giving up the efficiency of your current code generator. Just allocate a few COG locations for temporary variables and allocate them as needed to hold the results of nested subexpressions. Since you don't support recursion or even function calls as operands in an expression, you don't really need a dynamic stack. Just use the array of temporary COG locations as if it were a stack and allocate space for temporaries at compile time.
Yes, that's fairly common in smallest MCUs , and the tools can also track which registers are used in functions, to allow re-use of scratch local in non-nested calls. Some simple directives can give additional control for Debug, and cases where indirect calls may fool the tools.
It has been a few days since this thread got started, Bean, which way are you trending? Will you keep PropBASIC alive and well, or are you leaning more towards some kind of new compiler?
Ray,
For sure the current version will be supported, simply because that is what I use for my companies development.
Instead of a full expression evaluation, I may support strict left to right evaluation (only in assignment lines).
As for the P2, I was hoping it would be similar to the P1 instruction set, but it doesn't look that way. I'm not complaining, I think the P2 is going to be great, it's just going to require more than just a couple tweaks to the code. So that may not happen anytime soon.
The documentation, looking at the actual size of the pdf file, I think it is what, 100 pages or so. Maybe if you got rid of a lot of the white space, the size, could be reduced too maybe 20 pages or less.
Ray
Actually it fits into 17 pages duplex printed. I've attached a de-whitespaced reference version I use in an attempt to keep my desk just a bit less full of paper. Bean: If this isn't OK, please let me know. I do understand it's your IP.
As for the P2, I was hoping it would be similar to the P1 instruction set, but it doesn't look that way. I'm not complaining, I think the P2 is going to be great, it's just going to require more than just a couple tweaks to the code. So that may not happen anytime soon.
Polished P2 support will take a while, but it should be possible to use a P1 related subset of P2 opcodes, to get something 'that works', that can be used to shake out problems in the rest of the tool flows, and be used to test P2 FPGA image on things like smart pins ?
In-line code can access all P2 PASM opcodes ?
I am not sure where to put this, but I was reading a post by Brett Weir, and he had a couple of links:
github.com/parallaxinc
developer.parallax
So I checked it out and PropBASIC is in there, if Bean is aware, maybe a brief on how you are involved, with regards to PropBASIC, would be in order. It now looks like there might be a specific place to get the latest binaries for PropBASIC? One other addition, maybe a central place for contributed PropBASIC libraries?
It looks like things are going in the right direction, but a PropBASIC IDE is still an issue, not sure if it is a significant issue, but an IDE that has a current PropBASIC binary, should be a plus, I would think.
Seems that Bean has transferred ownership of PropBASIC to Parallax.
If that is the case, maybe an official notice from Parallax would be in order? So, now who do I start badgering, Brett Weir, or will their be somebody else running the show?
Hi Bean,
perhaps you remember me. I have always been a real fan of PropBasic as a compiler and a way to make programs with LMM and fast cog memory tasks. Avoiding to be forced to use pasm.
I don't think, that I would use an interpreter.
But this is YOUR fun and work, so you have to decide, which way ist the most interesting for you, I think.
Comments
Back in the early 1980's the microprocessor hit the world. In the form of those 8 bit C64's. Sinclair Spectrums and many others.
Soon there was a big push that all kids should learn about this new fangled computer technology and programming. Everyone could see it was the way of the future.
There were school education initiatives, there was the BBC Micro pushed into all schools. All kind or projects going on. No idea if this happened in the sates or not. Everyone was going to be up to speed with this new technology.
Since then I have seen MS and Apple pushing all kind of their products into schools as part of this educational plan or that. At enormous cost. And to no effect.
This is over three decades. And then. Eben Upton notices that kids trying to get into university have no idea about anything to do with computing or programming at all.
So he introduces the Raspberry Pi to fix that situation.
Where did it all go wrong?
It seems to me that you could probably implement a full expression parser without giving up the efficiency of your current code generator. Just allocate a few COG locations for temporary variables and allocate them as needed to hold the results of nested subexpressions. Since you don't support recursion or even function calls as operands in an expression, you don't really need a dynamic stack. Just use the array of temporary COG locations as if it were a stack and allocate space for temporaries at compile time.
Yes, that's fairly common in smallest MCUs , and the tools can also track which registers are used in functions, to allow re-use of scratch local in non-nested calls. Some simple directives can give additional control for Debug, and cases where indirect calls may fool the tools.
It's great to see more forum heavyweights, evaluating this compiler.
What is the concensus thus far?
Ray
LOL...Hey I resemble that remark and have been harping on about this product for like 5 years now.
Ray
For sure the current version will be supported, simply because that is what I use for my companies development.
Instead of a full expression evaluation, I may support strict left to right evaluation (only in assignment lines).
As for the P2, I was hoping it would be similar to the P1 instruction set, but it doesn't look that way. I'm not complaining, I think the P2 is going to be great, it's just going to require more than just a couple tweaks to the code. So that may not happen anytime soon.
Bean
That statement alone is reassuring for me.
I was going to PM this but it might be of interest to others; Do you offer a PropBASIC programming service as part of your business?
Actually it fits into 17 pages duplex printed. I've attached a de-whitespaced reference version I use in an attempt to keep my desk just a bit less full of paper. Bean: If this isn't OK, please let me know. I do understand it's your IP.
Polished P2 support will take a while, but it should be possible to use a P1 related subset of P2 opcodes, to get something 'that works', that can be used to shake out problems in the rest of the tool flows, and be used to test P2 FPGA image on things like smart pins ?
In-line code can access all P2 PASM opcodes ?
github.com/parallaxinc
developer.parallax
So I checked it out and PropBASIC is in there, if Bean is aware, maybe a brief on how you are involved, with regards to PropBASIC, would be in order. It now looks like there might be a specific place to get the latest binaries for PropBASIC? One other addition, maybe a central place for contributed PropBASIC libraries?
It looks like things are going in the right direction, but a PropBASIC IDE is still an issue, not sure if it is a significant issue, but an IDE that has a current PropBASIC binary, should be a plus, I would think.
Ray
It's a bit odd that he gets no attribution on github
Ray
"issues" can be bugs or feature requests for discussion or whatever.
I already raised 2 issues
perhaps you remember me. I have always been a real fan of PropBasic as a compiler and a way to make programs with LMM and fast cog memory tasks. Avoiding to be forced to use pasm.
I don't think, that I would use an interpreter.
But this is YOUR fun and work, so you have to decide, which way ist the most interesting for you, I think.
Have fun, Christof