If you post the source and ASM created of Working and Not Working blocks, I'm sure eyeballs on here will find the issue quickly.
Do you mean above 40 it starts to work ok, or do you mean test cases of between 20 & 40 fail.
20 is an unusual threshold, is 16.17 ok ?
Just a long shot here as I'm not frightfully familiar with the specifics of Basic, but I notice that you hove two more GPars (28 and 162) than you have SubCalls. Might it be a case of misalignment ?
Just a long shot here as I'm not frightfully familiar with the specifics of Basic, but I notice that you hove two more GPars (28 and 162) than you have SubCalls. Might it be a case of misalignment ?
Just wondering....
Cheers,
Peter (pjv)
thank you for noticing that. Though it appears I just missed part of the line when copying and pasting.
I wish I was comfortable enough with PropBASIC to just post the non-working code for review, though it is a new language to me (with very little in common with other BASIC languages). This is part of the reason that I am going to focus on getting everything correct in C, and then come back to PropBASIC later.
My hard copies are up to date with the soft copies of the PropBASIC code, so there is zero risk of loss.
David,
I will look into the problem.
I assume in your program you have the subroutines defined in the beginning (so you don't have to rename all the _ret lines in the PASM) ?
Bean
Action1 SUB 0
Action2 SUB 0
Action3 SUB 0
ON temp = 4,8,9 GOSUB Action1, Action2, Action3
SUB Action1
ENDSUB
SUB Action2
ENDSUB
SUB Action3
ENDSUB
David,
I will look into the problem.
I assume in your program you have the subroutines defined in the beginning (so you don't have to rename all the _ret lines in the PASM) ?
Bean
Action1 SUB 0
Action2 SUB 0
Action3 SUB 0
ON temp = 4,8,9 GOSUB Action1, Action2, Action3
SUB Action1
ENDSUB
SUB Action2
ENDSUB
SUB Action3
ENDSUB
Yes in my program I have all the subroutines declared at the beginning. Thank you very much.
David,
I found the problem. There is a maximum of 127 elements allowed per line. And commas count as an element.
I can change this for the next release, but it should work if you break the ON...GOSUB lines into two or three ON...GOSUB lines. If the variable doesn't make a match it will fall through to the next ON...GOSUB line.
David,
I found the problem. There is a maximum of 127 elements allowed per line. And commas count as an element.
I can change this for the next release, but it should work if you break the ON...GOSUB lines into two or three ON...GOSUB lines. If the variable doesn't make a match it will fall through to the next ON...GOSUB line.
Bean
Ah ok, that makes sense. I thank you for hunting that down.
David,
I found the problem. There is a maximum of 127 elements allowed per line. And commas count as an element.
I can change this for the next release, but it should work if you break the ON...GOSUB lines into two or three ON...GOSUB lines. If the variable doesn't make a match it will fall through to the next ON...GOSUB line.
Bean
Shouldn't David have at least gotten an error saying that?
Shouldn't David have at least gotten an error saying that?
That is a good point, huh.
Oh well as I write the C version I am thinking about how to translate it into PropBASIC, and I am avoiding using large switch case statements, thus it should be of little issue when I get back to PropBASIC with it.
Well PropBASIC is definitely going smooth now that I am just translating C code .
Who would have known.
Interestingly the same can be said for SPIN, that version is also going smoothly now that I am just translating from C. To bad there is not a Spin to native PASM compiler .
So I guess I will end up with the C, SPIN, and PropBASIC versions all in the first release.
I have not started on the new PASM version yet, though it should be interesting.
To bad there is not a Spin to native PASM compiler
I'm sure someone has mentioned this before but there is a two-step way to translate Spin to PASM. You can use spin2cpp to translate Spin to C++ and then compile the C++ to generate native LMM or CMM code.
I'm sure someone has mentioned this before but there is a two-step way to translate Spin to PASM. You can use spin2cpp to translate Spin to C++ and then compile the C++ to generate native LMM or CMM code.
Indeed. And if your code is all Spin, then you can do it in one step:
spin2cpp --binary -Os -mcog MyProgram.spin
for example, will produce a simple MyProgram.binary that you can run in a COG. Of course, MyProgram.spin (and all its dependencies) will have to fit in the COG!
Indeed. And if your code is all Spin, then you can do it in one step:
spin2cpp --binary -Os -mcog MyProgram.spin
for example, will produce a simple MyProgram.binary that you can run in a COG. Of course, MyProgram.spin (and all its dependencies) will have to fit in the COG!
That's nifty.
Does it warn/error if it fails to fit, and indicate by now much it missed ?
If we assume that will have to fit in the COG caveat is met in all cases, could a user do this up to 8 times, to generate 8 -mcog images they can then launch ?
Does it warn/error if it fails to fit, and indicate by now much it missed ?
The C compiler and/or linker will generate a section overflow message if it doesn't fit. I believe this says by how much it overflows.
If we assume that will have to fit in the COG caveat is met in all cases, could a user do this up to 8 times, to generate 8 -mcog images they can then launch ?
Well, theoretically, if the user has a tool that can launch more than one cog from the PC. I'm not aware of such a tool, but I haven't really looked either.
Has anyone done it with out using C or C++ as an intermediate?
A direct SPIN compiler should be fairly simple, it would take just a simple recursive decent compiler and be very simple if you are compiling to COG code. A bit more work to compile to LMM, XMM, or CMM (CMM is a lot faster than SPIN).
This is the simplest language in the Propeller list of supported languages that I have found, it is great.
I am quickly becoming accustomed to PropBASIC, despite a bit of a false start the first time around.
There are some definite quirks to using PropBASIC, though once you get accustomed to them it is a great language.
I have yet to succeed at making a library to use with a LOAD command, so the current version of my PropBASIC 3D Printer software is in one huge pbas file. Though I am sure with time I will figure that out as well.
Has anyone done it with out using C or C++ as an intermediate?
A direct SPIN compiler should be fairly simple, it would take just a simple recursive decent compiler and be very simple if you are compiling to COG code. A bit more work to compile to LMM, XMM, or CMM (CMM is a lot faster than SPIN).
Simple compilers are usually simple for any language. The problems come in when you want to optimize the code. I guess the Parallax Spin compiler does little or no optimization so it was probably fairly easy to write. On the other hand, GCC and LLVM try to do heavy optimization and that is far from trivial.
Simple compilers are usually simple for any language. The problems come in when you want to optimize the code. I guess the Parallax Spin compiler does little or no optimization so it was probably fairly easy to write. On the other hand, GCC and LLVM try to do heavy optimization and that is far from trivial.
I am well aware of the optimizations that GCC, and most others do. Not much use for COG code (optimizing for size can be done fairly easily inline in a recursive decent compiler), maybe a bit of use for LMM, CMM, and XMM code, though that is another story.
Ok it would take a little work to do things like dead code elimination, redundant sub expression consolidation, etc. Dead code elimination is a bad idea in a system like the propeller (unless it is in linked in libs, and that is up to the linker not the compiler), do to the way multithreading is done. Sub expression consolidation can be done by a first pass processor fairly easily (in most cases anyway).
As far as things like unrolling loops, etc are useless. Since the Propeller has a simple pipeline, it would not help to reorder instructions based on register access, or instruction type, with the exception of hub access instructions being interleaved with 8 cycles of instructions that do not use the data related to the access (and that is a simple peephole optimization).
So while advanced compilers do a lot of optimizations, most of these are useless on the Propeller, and of those that remain most will only help with LMM, CMM, or XMM, only a couple are of any use in COG mode code.
So it would be possible to implement a simple compiler for COG mode with little trouble. This is equally true for SPIN, C, BCPL, Pascal, or most other languages. The challenge comes on the shoulders of the user to implement code that does not exceed the 496 longs of COG RAM.
Just my views on the subject, I have not written a compiler for any language in at least a couple of years, and I do not think that I have written more than 20 compilers in my life (a lot less than most programmers/software engineers).
I am well aware of the optimizations that GCC, and most others do. Not much use for COG code (optimizing for size can be done fairly easily inline in a recursive decent compiler), maybe a bit of use for LMM, CMM, and XMM code, though that is another story.
Ok it would take a little work to do things like dead code elimination, redundant sub expression consolidation, etc. Dead code elimination is a bad idea in a system like the propeller (unless it is in linked in libs, and that is up to the linker not the compiler), do to the way multithreading is done. Sub expression consolidation can be done by a first pass processor fairly easily (in most cases anyway).
As far as things like unrolling loops, etc are useless. Since the Propeller has a simple pipeline, it would not help to reorder instructions based on register access, or instruction type, with the exception of hub access instructions being interleaved with 8 cycles of instructions that do not use the data related to the access (and that is a simple peephole optimization).
So while advanced compilers do a lot of optimizations, most of these are useless on the Propeller, and of those that remain most will only help with LMM, CMM, or XMM, only a couple are of any use in COG mode code.
So it would be possible to implement a simple compiler for COG mode with little trouble. This is equally true for SPIN, C, BCPL, Pascal, or most other languages. The challenge comes on the shoulders of the user to implement code that does not exceed the 496 longs of COG RAM.
Just my views on the subject, I have not written a compiler for any language in at least a couple of years, and I do not think that I have written more than 20 compilers in my life (a lot less than most programmers/software engineers).
20 compilers is more than I've written and I've never written a compiler that does significant optimization. I look forward to your COG mode compiler for any language. If it works as well as you indicate, it should be a great addition to the current set of Propeller programming tools. Any ETA?
20 compilers is more than I've written and I've never written a compiler that does significant optimization. I look forward to your COG mode compiler for any language. If it works as well as you indicate, it should be a great addition to the current set of Propeller programming tools. Any ETA?
WOW:
I guess that means that you are recruiting me for the task?
I can not give an eta, as I had not thought about writing one, so I still need to come up with a language specification, and then get to work.
I would say that BASIC is out, as I would go with something closer to standard BASIC, and that may confuse people with PropBASIC being so different. C is out as we already have at least two of those. SPIN is a possibility (and a strong one). PASCAL is another possibility.
I think I will draw up for SPIN and see where that leads me. It will NOT be self hosting (obvious reasons I hope), so I will have to decide what language to use for implementation.
Then there is the issue of the stack, if HUB RAM is used that is a speed bottleneck, if COG RAM is used that severely limits the size of the stack. Adding the code for stack checking, to dynamically shift between COG RAM and HUB RAM as the stack grows, would reduce the space available for program code.
Thank you for the challenge, I now have something to do once I Finnish up this 3D printer firmware in 4 programming languages (SPIN, C, PropBASIC, and PASM).
I guess that means that you are recruiting me for the task?
I can not give an eta, as I had not thought about writing one, so I still need to come up with a language specification, and then get to work.
I would say that BASIC is out, as I would go with something closer to standard BASIC, and that may confuse people with PropBASIC being so different. C is out as we already have at least two of those. SPIN is a possibility (and a strong one). PASCAL is another possibility.
I think I will draw up for SPIN and see where that leads me. It will NOT be self hosting (obvious reasons I hope), so I will have to decide what language to use for implementation.
Then there is the issue of the stack, if HUB RAM is used that is a speed bottleneck, if COG RAM is used that severely limits the size of the stack. Adding the code for stack checking, to dynamically shift between COG RAM and HUB RAM as the stack grows, would reduce the space available for program code.
Thank you for the challenge, I now have something to do once I Finnish up this 3D printer firmware in 4 programming languages (SPIN, C, PropBASIC, and PASM).
Just to be clear, I am not saying that this is a project that will be supported by Parallax. I don't speak for them. It's just that you suggested it wouldn't be that hard so I'm interested to see what you come up with.
Just to be clear, I am not saying that this is a project that will be supported by Parallax. I don't speak for them. It's just that you suggested it wouldn't be that hard so I'm interested to see what you come up with.
Well it will be the first compiler that I have written for a system that does not support any form of hardware stack at all. It should be interesting.
And all this over the simple question of what spin to native compilers already exist, a question that is still unanswered.
Well it will be the first compiler that I have written for a system that does not support any form of hardware stack at all. It should be interesting.
And all this over the simple question of what spin to native compilers already exist, a question that is still unanswered.
If you're not willing to accept the combination of spin2cpp and propgcc as a way to compile Spin to native COG code then the answer is that there is no such compiler.
I would say that BASIC is out, as I would go with something closer to standard BASIC, and that may confuse people with PropBASIC being so different. C is out as we already have at least two of those. SPIN is a possibility (and a strong one). PASCAL is another possibility.
Because a Spin compile pathway already exists, I would say the Pascal would have more appeal, especially as it has good PC and Pi2 support in place already.. (see other threads on Lazarus/FPC on Pi2)
Based on something like PropBASIC (source available when?) , a choice of front ends for BASIC / Pascal / Spin should not be too onerous.
Because a Spin compile pathway already exists, I would say the Pascal would have more appeal, especially as it has good PC and Pi2 support in place already.. (see other threads on Lazarus/FPC on Pi2)
Based on something like PropBASIC (source available when?) , a choice of front ends for BASIC / Pascal / Spin should not be too onerous.
Well there is still time to decide. Unfortunately my books on Pascal are in the guest room, and there is a friend asleep in there at the moment, so I will have to wait till morning to draw up a Pascal syntax (Extended Backus–Naur Form).
Would there be any interest in a more traditional BASIC with support for multiple operator expressions, and better form of sub/function declaration and definition?
eg something like:
DECLARE SUB MyProc(x AS LONG, y AS LONG, z AS LONG, s AS STRING, d AS BYTE PTR)
DIM var1, var2, var3, array(22) AS LONG
start:
'Some code here.
SUB MyProc(x AS LONG, y AS LONG, z AS LONG, s AS STRING, d AS BYTE PTR)
DIM lvar1 AS LONG
'do something.
END SUB
I ask as that is the style of BASIC that is so common, and that I use daily. It would also be fairly simple to implement the compiler.
Well there is still time to decide. Unfortunately my books on Pascal are in the guest room, and there is a friend asleep in there at the moment, so I will have to wait till morning to draw up a Pascal syntax (Extended Backus–Naur Form).
Would there be any interest in a more traditional BASIC with support for multiple operator expressions, and better form of sub/function declaration and definition?
eg something like:
DECLARE SUB MyProc(x AS LONG, y AS LONG, z AS LONG, s AS STRING, d AS BYTE PTR)
DIM var1, var2, var3, array(22) AS LONG
start:
'Some code here.
SUB MyProc(x AS LONG, y AS LONG, z AS LONG, s AS STRING, d AS BYTE PTR)
DIM lvar1 AS LONG
'do something.
END SUB
I ask as that is the style of BASIC that is so common, and that I use daily. It would also be fairly simple to implement the compiler.
The obvious forks to extend PropBASIC to me would be
a) to include BasicStamp compatible syntax, to allow porting basic Stamp code
b) to support some common PC compiler, to allow PC hosted code testing and function development.
FreeBasic is one candidate, but it is rather behind Lazarus/FreePascal in Editor/Debug areas.
The PropBASIC code seems to be close-to-available, so modifying that to extend support would be one solution.
Thank you for that, though that is fpc, which contains standard pascal, though also a lot of extensions mixed in.
The obvious forks to extend PropBASIC to me would be
a) to include BasicStamp compatible syntax, to allow porting basic Stamp code
b) to support some common PC compiler, to allow PC hosted code testing and function development.
FreeBasic is one candidate, but it is rather behind Lazarus/FreePascal in Editor/Debug areas.
The PropBASIC code seems to be close-to-available, so modifying that to extend support would be one solution.
I was thinking more a different BASIC, completely separate from PropBASIC.
A BASIC with a syntax close to the standard BASIC implementations, though targeted to the Prop and thus not having some things, as well as having some additional things to the norm.
I was thinking more a different BASIC, completely separate from PropBASIC.
A BASIC with a syntax close to the standard BASIC implementations, though targeted to the Prop and thus not having some things, as well as having some additional things to the norm.
I'd be wary of creating too many Basics, as that is actually one of the drawbacks....
which is why Pascal makes more sense, than another Basic variant.
Better to have common code generation and libraries, and syntax-options if you really need them.
Comments
Do you mean above 40 it starts to work ok, or do you mean test cases of between 20 & 40 fail.
20 is an unusual threshold, is 16.17 ok ?
Just a long shot here as I'm not frightfully familiar with the specifics of Basic, but I notice that you hove two more GPars (28 and 162) than you have SubCalls. Might it be a case of misalignment ?
Just wondering....
Cheers,
Peter (pjv)
I wish I was comfortable enough with PropBASIC to just post the non-working code for review, though it is a new language to me (with very little in common with other BASIC languages). This is part of the reason that I am going to focus on getting everything correct in C, and then come back to PropBASIC later.
My hard copies are up to date with the soft copies of the PropBASIC code, so there is zero risk of loss.
I will look into the problem.
I assume in your program you have the subroutines defined in the beginning (so you don't have to rename all the _ret lines in the PASM) ?
Bean
I found the problem. There is a maximum of 127 elements allowed per line. And commas count as an element.
I can change this for the next release, but it should work if you break the ON...GOSUB lines into two or three ON...GOSUB lines. If the variable doesn't make a match it will fall through to the next ON...GOSUB line.
Bean
Oh well as I write the C version I am thinking about how to translate it into PropBASIC, and I am avoiding using large switch case statements, thus it should be of little issue when I get back to PropBASIC with it.
Yeah, that would be a good idea...
Bean
I am not having any more trouble with the ON GOSUB, I am being a bit more careful.
Though I did notice one further thing missing from the PropBASIC documents:
There is no mention of the relational operators in the Operator listings.
thank you again for this great tool. And when will we see PropPASCAL
Or maybe just PropBCPL LOL.
Who would have known.
Interestingly the same can be said for SPIN, that version is also going smoothly now that I am just translating from C. To bad there is not a Spin to native PASM compiler
So I guess I will end up with the C, SPIN, and PropBASIC versions all in the first release.
I have not started on the new PASM version yet, though it should be interesting.
Indeed. And if your code is all Spin, then you can do it in one step: for example, will produce a simple MyProgram.binary that you can run in a COG. Of course, MyProgram.spin (and all its dependencies) will have to fit in the COG!
That's nifty.
Does it warn/error if it fails to fit, and indicate by now much it missed ?
If we assume that will have to fit in the COG caveat is met in all cases, could a user do this up to 8 times, to generate 8 -mcog images they can then launch ?
Well, theoretically, if the user has a tool that can launch more than one cog from the PC. I'm not aware of such a tool, but I haven't really looked either.
A direct SPIN compiler should be fairly simple, it would take just a simple recursive decent compiler and be very simple if you are compiling to COG code. A bit more work to compile to LMM, XMM, or CMM (CMM is a lot faster than SPIN).
_____________________________________________________________________________________
This is the simplest language in the Propeller list of supported languages that I have found, it is great.
I am quickly becoming accustomed to PropBASIC, despite a bit of a false start the first time around.
There are some definite quirks to using PropBASIC, though once you get accustomed to them it is a great language.
I have yet to succeed at making a library to use with a LOAD command, so the current version of my PropBASIC 3D Printer software is in one huge pbas file. Though I am sure with time I will figure that out as well.
Ok it would take a little work to do things like dead code elimination, redundant sub expression consolidation, etc. Dead code elimination is a bad idea in a system like the propeller (unless it is in linked in libs, and that is up to the linker not the compiler), do to the way multithreading is done. Sub expression consolidation can be done by a first pass processor fairly easily (in most cases anyway).
As far as things like unrolling loops, etc are useless. Since the Propeller has a simple pipeline, it would not help to reorder instructions based on register access, or instruction type, with the exception of hub access instructions being interleaved with 8 cycles of instructions that do not use the data related to the access (and that is a simple peephole optimization).
So while advanced compilers do a lot of optimizations, most of these are useless on the Propeller, and of those that remain most will only help with LMM, CMM, or XMM, only a couple are of any use in COG mode code.
So it would be possible to implement a simple compiler for COG mode with little trouble. This is equally true for SPIN, C, BCPL, Pascal, or most other languages. The challenge comes on the shoulders of the user to implement code that does not exceed the 496 longs of COG RAM.
Just my views on the subject, I have not written a compiler for any language in at least a couple of years, and I do not think that I have written more than 20 compilers in my life (a lot less than most programmers/software engineers).
I guess that means that you are recruiting me for the task?
I can not give an eta, as I had not thought about writing one, so I still need to come up with a language specification, and then get to work.
I would say that BASIC is out, as I would go with something closer to standard BASIC, and that may confuse people with PropBASIC being so different. C is out as we already have at least two of those. SPIN is a possibility (and a strong one). PASCAL is another possibility.
I think I will draw up for SPIN and see where that leads me. It will NOT be self hosting (obvious reasons I hope), so I will have to decide what language to use for implementation.
Then there is the issue of the stack, if HUB RAM is used that is a speed bottleneck, if COG RAM is used that severely limits the size of the stack. Adding the code for stack checking, to dynamically shift between COG RAM and HUB RAM as the stack grows, would reduce the space available for program code.
Thank you for the challenge, I now have something to do once I Finnish up this 3D printer firmware in 4 programming languages (SPIN, C, PropBASIC, and PASM).
Well it will be the first compiler that I have written for a system that does not support any form of hardware stack at all. It should be interesting.
And all this over the simple question of what spin to native compilers already exist, a question that is still unanswered.
Because a Spin compile pathway already exists, I would say the Pascal would have more appeal, especially as it has good PC and Pi2 support in place already.. (see other threads on Lazarus/FPC on Pi2)
Based on something like PropBASIC (source available when?) , a choice of front ends for BASIC / Pascal / Spin should not be too onerous.
Would there be any interest in a more traditional BASIC with support for multiple operator expressions, and better form of sub/function declaration and definition?
eg something like:
DECLARE SUB MyProc(x AS LONG, y AS LONG, z AS LONG, s AS STRING, d AS BYTE PTR) DIM var1, var2, var3, array(22) AS LONG start: 'Some code here. SUB MyProc(x AS LONG, y AS LONG, z AS LONG, s AS STRING, d AS BYTE PTR) DIM lvar1 AS LONG 'do something. END SUBI ask as that is the style of BASIC that is so common, and that I use daily. It would also be fairly simple to implement the compiler.
Google find this
http://www.win.tue.nl/~wstomv/software/formann/fpc-user.pdf
says (Note: all grammars are in EBNF, Extended Backus-Naur Form)
The obvious forks to extend PropBASIC to me would be
a) to include BasicStamp compatible syntax, to allow porting basic Stamp code
b) to support some common PC compiler, to allow PC hosted code testing and function development.
FreeBasic is one candidate, but it is rather behind Lazarus/FreePascal in Editor/Debug areas.
The PropBASIC code seems to be close-to-available, so modifying that to extend support would be one solution.
I was thinking more a different BASIC, completely separate from PropBASIC.
A BASIC with a syntax close to the standard BASIC implementations, though targeted to the Prop and thus not having some things, as well as having some additional things to the norm.
I'd be wary of creating too many Basics, as that is actually one of the drawbacks....
which is why Pascal makes more sense, than another Basic variant.
Better to have common code generation and libraries, and syntax-options if you really need them.