@evanh said:
I have yet to use a skip pattern. I guess it's because I've not run out of cogRAM in my experimenting so not needed to compact any code.
You probably need to try to write a large PASM2 driver with lots of features. Skip patterns can then be a godsend. An effort to maintain though whenever you need to alter something.
I like the visualization in the debugger for SKIP, but writing or reading this stuff is quite painful.
So you already can access constants in a sub object via subname#constant and methods via subname.method, how about subname@datlabel to get the real address of a sub object DAT (or even VAR of a instance) label from a main program?
I think (not tested) that flexspin did that, a least I remember @Wuerfel_21 writing about that.
That would fit into the language and, really changing CONSTANTS sounds stupid to me, and for the cost of the ONLY code removal PropTool does, folding in multiple DAT and CODE copies into one, just leaving VAR for each instance even more as stupid.
Way more important for PropTool would be removing unused Methods as BST and Flexspin do.
@msrobots said:
So you already can access constants in a sub object via subname#constant and methods via subname.method, how about subname@datlabel to get the real address of a sub object DAT (or even VAR of a instance) label from a main program?
I think (not tested) that flexspin did that, a least I remember @Wuerfel_21 writing about that.
flexspin lets you write subname.name for any name inside an object, whether it's a method, constant, VAR, or label in a DAT section.
@ersmith said:
flexspin lets you write subname.name for any name inside an object, whether it's a method, constant, VAR, or label in a DAT section.
Oh, that's attractive. In my recent Prop1 project, I've been getting adept with passing lots of pointers and using long[pointer] all over the place. It's not the most elegant.
@ersmith said:
flexspin lets you write subname.name for any name inside an object, whether it's a method, constant, VAR, or label in a DAT section.
Oh, that's attractive. In my recent Prop1 project, I've been getting adept with passing lots of pointers and using long[pointer] all over the place. It's not the most elegant.
Reminder that flexspin's bytecode mode produces smaller and faster code than PropTool, too
My P1 code goes into ~5000 laser tag units per year. The team thinks that will jump to the ~15K mark with the features we plan to implement with the P2. I have other clients that sell fewer devices, but testing is just as critical for them.
Reminder that flexspin's bytecode mode produces smaller and faster code than PropTool, too
Are you willing to put it into several thousand commercial devices that people pay you good money for?
Flexspin must be quite reliable, since a lot of people are using it and I haven't heard of any problems. Eric is pretty attentive. He probably has a more thorough quality-control approach than I do.
It comes down to what is used for proving the source code during testing doesn't it.
I started with Flexspin at home but have been using Proptool since moving to the customer's test bench. It didn't phase me initially but I've become less happy with the change since. The Proptool's undo edits seems a little unreliable. I maybe a little heavily relied on this feature with Kate. I dislike Proptool's single window editor as well.
Basically, IDE's now feel constrained for me these days. Historically I managed large sources using a folding editor. Kate supports such but I'm now liking a large desktop display for multiple editor windows, a plain text editor and the shell for compiling. I guess I should try to sort out an equivalent for Windoze.
PS: I have noticed a difference in Spin syntax of some operators between Flexspin and Proptool too. Eg: I was getting away with AND and OR directly on a variable within IF statements for logical combinations but these broke under Proptool. I needed to add compare with zero operators as well.
I cant speak for FlexSpin, but I do have a couple of things out there in a very hostile location that are written in FlexBASIC that havent been rebooted in almost a year. These are sitting on very large 3-phase motors that run 24/7.
@evanh said:
It comes down to what is used for proving the source code during testing doesn't it.
This, basically.
PS: I have noticed a difference in Spin syntax of some operators between Flexspin and Proptool too. Eg: I was getting away with AND and OR directly on a variable within IF statements for logical combinations but these broke under Proptool. I needed to add compare with zero operators as well.
When you notice such a thing, report it. The Spin syntax should be identical, save for certain extension.
@evanh said:
PS: I have noticed a difference in Spin syntax of some operators between Flexspin and Proptool too. Eg: I was getting away with AND and OR directly on a variable within IF statements for logical combinations but these broke under Proptool. I needed to add compare with zero operators as well.
When you notice such a thing, report it. The Spin syntax should be identical, save for certain extension.
There's no Internet on site. I wasn't that motivated.
When I read the Prop1/Spin1 reference manual I realised AND is a binary operator in Spin1 instead of the logical operator of every other language. I thought that's just wrong, no wonder it's different in Flexspin. Notably, Chip has fixed this in Spin2.
When I read the Prop1/Spin1 reference manual I realised AND is a binary operator in Spin1 instead of the logical operator of every other language.
Huh? No it's not! From the P1 manual (and from my own experience with PropTool):
"The Boolean AND ‘AND’ operator compares two operands and returns TRUE (-1) if both values
are TRUE (non-zero), or returns FALSE (0) if one or both operands are FALSE (0). Boolean AND
can be used in both variable and constant expressions."
When I read the Prop1/Spin1 reference manual I realised AND is a binary operator in Spin1 instead of the logical operator of every other language.
Huh? No it's not! From the P1 manual (and from my own experience with PropTool):
"The Boolean AND ‘AND’ operator compares two operands and returns TRUE (-1) if both values
are TRUE (non-zero), or returns FALSE (0) if one or both operands are FALSE (0).
I think what @evan meant is that in A AND B most languages only evaluate B if A is TRUE; if A is FALSE then they don't bother calculating B, because its value doesn't matter. Spin1 always evaluates both A and B though.
flexspin does the short circuiting, but it's supposed to only do it if B has no side effects (so it doesn't matter whether it gets evaulated or not). If you find a case where its behavior is different from the official Spin1 compiler, please let us know!
Okay, reading the manual again, I see what's happening. In most languages AND is always boolean. In Spin1 (only) it can be either boolean or bitwise depending on use of associated comparison operators. I wasn't using those comparisons so it treated my code as a bitwise operation when I was expecting it to be boolean.
if a and b
do_something()
else
do_something_else()
if (a <> 0) and (b <> 0)
do_something()
else
do_something_else()
In Spin1, those evaluate differently. In Spin2 and everything else they are the same.
Oops, I may have misread the bitwise description. I now see it doesn't have quotes around the AND word. So AND is boolean only.
Well, I dunno why adding the comparison operators made a difference now. I'd have to dig up the actual case I guess ...
EDIT: Apologies, the AND operator problem isn't a Spin problem. It is with a Basic I'm using on the same project. There is multiple controllers involved. I've definitely tripped up a few times as well, switching between Basic and Spin and using other controller's syntax then getting compile errors.
There was something I had to edit in Spin to make Proptool happy. Just can't remember what it was now.
I've hacked up a functioning Modbus multi-drop slave driver btw. It's not very pretty though. Got some special case code in FullDuplexSerial for echo management and handling flow control with a RS485 line transceiver that has RXD and TXD on the same pin.
@msrobots said:
So you already can access constants in a sub object via subname#constant and methods via subname.method, how about subname@datlabel to get the real address of a sub object DAT (or even VAR of a instance) label from a main program?
I think (not tested) that flexspin did that, a least I remember @Wuerfel_21 writing about that.
flexspin lets you write subname.name for any name inside an object, whether it's a method, constant, VAR, or label in a DAT section.
I hope you support sub#constant for compability with P1 Spin too.
And yes I also hope that @cgracey would adapt PropTool/Pnut a bit to support extensions FlexSpin has, like optional default parameters in Methods (very useful), ifdef & co, removing unused code and your sd/host file system.
@ersmith said:
Getting back to the original thread: what did you decide to do about parameterizing object instantiations, @cgracey ?
I think I will allow CON symbol overrides in OBJ instantiations.
I would have had it done, already, but I've been cleaning out the barn because Doug Pientak wants to expand his machine shop operation. I just took another 1,400 lbs of stuff to the dump today. I got some used warehouse pallet racks set up against one wall so that I can get the floor cleared. It made the barn way bigger. This cleanup also involves sifting through all the stuff that came from my parents' house three years ago. It's like reviewing the last 60 years of their lives as I go through all these banker boxes of hanging files. Almost all of it went to the dump - the place of reckoning.
Comments
You probably need to try to write a large PASM2 driver with lots of features. Skip patterns can then be a godsend.
An effort to maintain though whenever you need to alter something.
I like the visualization in the debugger for SKIP, but writing or reading this stuff is quite painful.
So you already can access constants in a sub object via subname#constant and methods via subname.method, how about subname@datlabel to get the real address of a sub object DAT (or even VAR of a instance) label from a main program?
I think (not tested) that flexspin did that, a least I remember @Wuerfel_21 writing about that.
That would fit into the language and, really changing CONSTANTS sounds stupid to me, and for the cost of the ONLY code removal PropTool does, folding in multiple DAT and CODE copies into one, just leaving VAR for each instance even more as stupid.
Way more important for PropTool would be removing unused Methods as BST and Flexspin do.
Mike
flexspin lets you write subname.name for any name inside an object, whether it's a method, constant, VAR, or label in a DAT section.
Oh, that's attractive. In my recent Prop1 project, I've been getting adept with passing lots of pointers and using
long[pointer]
all over the place. It's not the most elegant.Reminder that flexspin's bytecode mode produces smaller and faster code than PropTool, too![:) :)](https://forums.parallax.com/resources/emoji/smile.png)
Are you willing to put it into several thousand commercial devices that people pay you good money for?
Good point. I'm totally sticking with Prop Tool, even thought the dream of "thousand" seems completely remote.
-Phil
My P1 code goes into ~5000 laser tag units per year. The team thinks that will jump to the ~15K mark with the features we plan to implement with the P2. I have other clients that sell fewer devices, but testing is just as critical for them.
Flexspin must be quite reliable, since a lot of people are using it and I haven't heard of any problems. Eric is pretty attentive. He probably has a more thorough quality-control approach than I do.
It comes down to what is used for proving the source code during testing doesn't it.
I started with Flexspin at home but have been using Proptool since moving to the customer's test bench. It didn't phase me initially but I've become less happy with the change since. The Proptool's undo edits seems a little unreliable. I maybe a little heavily relied on this feature with Kate. I dislike Proptool's single window editor as well.
Basically, IDE's now feel constrained for me these days. Historically I managed large sources using a folding editor. Kate supports such but I'm now liking a large desktop display for multiple editor windows, a plain text editor and the shell for compiling. I guess I should try to sort out an equivalent for Windoze.
PS: I have noticed a difference in Spin syntax of some operators between Flexspin and Proptool too. Eg: I was getting away with AND and OR directly on a variable within IF statements for logical combinations but these broke under Proptool. I needed to add compare with zero operators as well.
I cant speak for FlexSpin, but I do have a couple of things out there in a very hostile location that are written in FlexBASIC that havent been rebooted in almost a year. These are sitting on very large 3-phase motors that run 24/7.
This, basically.
When you notice such a thing, report it. The Spin syntax should be identical, save for certain extension.
I wouldn't be able to program the P2 without FlexSpin, so I am very grateful for Eric's work.
There's no Internet on site. I wasn't that motivated.
When I read the Prop1/Spin1 reference manual I realised
AND
is a binary operator in Spin1 instead of the logical operator of every other language. I thought that's just wrong, no wonder it's different in Flexspin. Notably, Chip has fixed this in Spin2.Huh? No it's not! From the P1 manual (and from my own experience with PropTool):
"The Boolean AND ‘AND’ operator compares two operands and returns TRUE (-1) if both values
are TRUE (non-zero), or returns FALSE (0) if one or both operands are FALSE (0). Boolean AND
can be used in both variable and constant expressions."
The binary (bit-wise) operator is &.
-Phil
I think what @evan meant is that in
A AND B
most languages only evaluate B if A is TRUE; if A is FALSE then they don't bother calculating B, because its value doesn't matter. Spin1 always evaluates both A and B though.flexspin does the short circuiting, but it's supposed to only do it if B has no side effects (so it doesn't matter whether it gets evaulated or not). If you find a case where its behavior is different from the official Spin1 compiler, please let us know!
Okay, reading the manual again, I see what's happening. In most languages AND is always boolean. In Spin1 (only) it can be either boolean or bitwise depending on use of associated comparison operators. I wasn't using those comparisons so it treated my code as a bitwise operation when I was expecting it to be boolean.
In Spin1, those evaluate differently. In Spin2 and everything else they are the same.
I have no idea what that even means. Example?
-Phil
Oops, I may have misread the bitwise description. I now see it doesn't have quotes around the AND word. So AND is boolean only.
Well, I dunno why adding the comparison operators made a difference now. I'd have to dig up the actual case I guess ...
EDIT: Apologies, the AND operator problem isn't a Spin problem. It is with a Basic I'm using on the same project. There is multiple controllers involved. I've definitely tripped up a few times as well, switching between Basic and Spin and using other controller's syntax then getting compile errors.
There was something I had to edit in Spin to make Proptool happy. Just can't remember what it was now.
I've hacked up a functioning Modbus multi-drop slave driver btw. It's not very pretty though. Got some special case code in FullDuplexSerial for echo management and handling flow control with a RS485 line transceiver that has RXD and TXD on the same pin.
Getting back to the original thread: what did you decide to do about parameterizing object instantiations, @cgracey ?
I hope you support sub#constant for compability with P1 Spin too.
And yes I also hope that @cgracey would adapt PropTool/Pnut a bit to support extensions FlexSpin has, like optional default parameters in Methods (very useful), ifdef & co, removing unused code and your sd/host file system.
Mike
I think I will allow CON symbol overrides in OBJ instantiations.
I would have had it done, already, but I've been cleaning out the barn because Doug Pientak wants to expand his machine shop operation. I just took another 1,400 lbs of stuff to the dump today. I got some used warehouse pallet racks set up against one wall so that I can get the floor cleared. It made the barn way bigger. This cleanup also involves sifting through all the stuff that came from my parents' house three years ago. It's like reviewing the last 60 years of their lives as I go through all these banker boxes of hanging files. Almost all of it went to the dump - the place of reckoning.
went thru that too, it helps to let go
Mike