Each cog could have its own accumulator in hub. When a cog reads its accumulator, a flag or something will decide if the accumulator gets cleared. One cog could start multiple cordic requests back to back and have them all going through the cordic engine at the same time. A 4 bit number would get shifted through the pipeline along with the cordic data to identify which cog made the request. When a request gets to the end, it will get accumulated into the right cog's accumulator. This method allows both accumulation and multiple requests at once per cog. If you don't want them to be accumulated, start the first cordic op, start the second, wait for the first to be ready and read and clear the accumulator, and then wait for the second to be ready and then read and clear the accumulator. If you do want them to be accumulated, only read the accumulator once, at the end.
Each cog could have its own accumulator in hub. When a cog reads its accumulator, a flag or something will decide if the accumulator gets cleared. One cog could start multiple cordic requests back to back and have them all going through the cordic engine at the same time. A 4 bit number would get shifted through the pipeline along with the cordic data to identify which cog made the request.
This sounds like a MathBlock version of HUB Slot mapping ? (Hub-Slot mapping has already been suggested, like this, it has a 4 bit identifier with each time-slot )
Mapping does allow users to allocate valuable time/bandwidth resource, instead of it being forced/locked to 1:16
In MathOps cases, there is of course the caveat that no new-operations can be done if they need a pending result.
It's true that we could add floating point, as well. Since all this is now separate from the cogs, all kinds of things are possible.
The most common requests by the volume users have not frequently included floating point, though I recognize math is so much more productive to do this without integers, compilers and objects. This time we have 16 cogs and really high speed, so a math library wouldn't be as consuming as it were on Propeller 1. To me, that's a much easier sell than it was on Propeller 1 where it took at least a few cogs if I recall correctly.
I'm in Washington D.C. right now. This week I met with a consulting engineering firm who uses the Propeller in a telemetry application. The entire product has been achieved in a Propeller 1 but more RAM and a few more cores would meet the needs of the next revision nicely. They didn't mention floating point math as a clear need.
When features are so easy to add they could allow Parallax to leverage them for the next revision. Future improvements, no matter how fast they are completed, show that we're in this business for Parallax and our customers. Of course, I don't know anything about the design time required to add floating point, so it's very difficult to say if it's worth the effort at this stage. However, please feel free to disagree with me.
I'm in Washington D.C. right now. This week I met with a consulting engineering firm who uses the Propeller in a telemetry application. The entire product has been achieved in a Propeller 1 but more RAM and a few more cores would meet the needs of the next revision nicely. They didn't mention floating point math as a clear need.
Ken Gracey
They probably never considered it as an option with this class of MCU. If you had it would they use it? Probably. Once they did they would then wonder how they ever got along without it.
Can I do process control without it? Yes. If the Prop has it would I use it? Yep. Would having it make a positive difference to my product. Without doubt.
Not that I am saying we NEED it for this version of the Prop. Just that IF Chip magically finds a way to include it that it would be a great feature to have.
How many MCU's in this class even have it? Would having it in the Prop give it a selection edge when being considered for a project?
Yes, but I was thinking more of sharing the hub address/data bus with the ROM/RAM and MathBlock, instead of perhaps having a separate bus to the MathBlock.
As long as the MATHOP access window is out-of-phase with HUBOP access window, I'd think you could mux the QUADs between the two. If MATHOPs stall, then this definitely shouldn't be an issue.
There is a huge raft of applications that don't need floating point acceleration even if they do use floating point maths. The C compilers give you floating point with no effort.
I suspect floating point should some how be added to the Spin language. Now that the Spin byte code interpreter is not in ROM or confined to a COG that should be doable. I'm not sure how this would look in Spin as there aren't really any types in the language.
If anyone needs floating point acceleration in their MCU they are not going to be using a Propeller even if it does get a floating point unit. I can't imagine that the performance would be comparable.
So my feeling is that there is no benefit in investing time, effort and power budget on floating point hardware. At least not for this iteration of the P2.
I too agree with Ken and Heater, and as great a feature it would be, we already have Lonesock's awesome F32, and I'd rather ( assuming it's not an incredibly simple and quick mod to add ) have a P1+/P2 sooner than later.
There is a huge raft of applications that don't need floating point acceleration even if they do use floating point maths. The C compilers give you floating point with no effort.
I suspect floating point should some how be added to the Spin language. Now that the Spin byte code interpreter is not in ROM or confined to a COG that should be doable. I'm not sure how this would look in Spin as there aren't really any types in the language.
If anyone needs floating point acceleration in their MCU they are not going to be using a Propeller even if it does get a floating point unit. I can't imagine that the performance would be comparable.
So my feeling is that there is no benefit in investing time, effort and power budget on floating point hardware. At least not for this iteration of the P2.
Spin does have types it has BYTE WORD and LONG in a VAR's definition so could be done there, when any maths is done on it, to use the FLOAT functions.
Is Spin still going to be part of the ROM? I thought it was not going to be part of the ROM, yes this would get messy with many versions floating around, but it would then definitely also allow for a floating version of Spin. ( although even if it was in ROM we could still do a float variant of spin in RAM )
Spin does not really have types. BYTE, WORD, LONG determine the amount of storage used. But what about when passing parameters to methods? Inside the method it has no idea what types it is dealing with. What about when sending pointers to different types through mail box structures and so on.
VAR
long l1, l2
float f1, f2
PUB start | l, f
l := doIt (l1, l2) ' What are l and f, float or int?
f := doIt (f1, f2)
PUB doIt (x, y)
return x * y ' Float or integer multiply?
There have been proposals in the past to add types to Spin. The use of types could be optional, so that those that abhor using types would not be forced to do so. If types were added to the Spin language the compiler could automatically convert "f1 * f2" to F.FMUL(f1,f2). The compiler could also do type checking to catch newbie mistakes like ser.tx(string("Hello World")) or doing ser.str(strbuf) instead of ser.str(@strbuf).
Heater, good point. I was thinking (apparently not much thinking) more along the lines of a preprocessor than full up adding types to Spin. Perhaps all lines with a floating point operation could be required to have a marker like *FLOAT* as a comment.
Heater, good point. I was thinking (apparently not much thinking) more along the lines of a preprocessor than full up adding types to Spin. Perhaps all lines with a floating point operation could be required to have a marker like *FLOAT* as a comment.
John Abshier
Perhaps a single tick (`) character before the operator:
y := m `* x `+ b
If there was some simple way to differentiate floating point operators, that might be all that is needed. Or, let float be the default and have special integer operators.
Perhaps a single tick (`) character before the operator:
Oh, please, no.
When the types of the variables are known, the rule is simple: always promote the operation to the higher of its two arguments, converting as necessary. The compiler just needs to keep track of the type on its syntax stack. The right way to answer Heater's query is to declare types of formal parameters:
Perhaps a single tick (`) character before the operator:
y := m `* x `+ b
If there was some simple way to differentiate floating point operators, that might be all that is needed. Or, let float be the default and have special integer operators.
Or just make F32's functions part of the language.
The issue of types in Spin is a huge barrel of worms that could probably do with a thread of it's own "Spin II Features" anybody?
I would like to make some observations.
1) Type correctness does not ensure program correctness.
Those who favour strongly typed languages are always pointing out how great it is to have the compiler spit out errors when the programmer uses the wrong types. However having all your types all "line up" does not guarantee that your program works as expected. You still need to test everything to be sure.
Now, given the super fast "edit-run" cycle when programming in Spin and given that you are going to test the thing anyway, those compile time type checks have less significance.
2) The most noobie friendly languages we have are things like Python and JavaScript. Where types are very sloppy things and errors don't show up until run time. Clearly noobies like loosely typed languages.
3) Currently Spin is gloriously simple. Adding types to it will make a pigs ear out of it. Given the added complexity on might think it is being turned into C. So why not just use C ?!
I kind of like John's idea. In order to allow floating point work one has to some how tell the compiler that the numbers involved are floats. That can be done by a type system or it by introducing some new weird operators that are the floating point versions of +,-,*,/ etc.
Or, as John said, somehow annotate expressions so that the arithmetic operators are doing float ops. How about a syntax like:
r := float(x * y / z + 3.2)
Where the thing that looks like a function called float simply causes the compiler to generate floating point ops for the expression in parenthesis.
I don't think I have see such an approaach in any language.
The right way to answer Heater's query is to declare types of formal parameters:
That may well be true. Don't you also need types on the local variables? This approach starts to add a lot of verbosity and stuff for noobies to have to know. It's turning Spin in to C. Which seems a bit silly as we already have C.
The issue of types in Spin is a huge barrel of worms that could probably do with a thread of it's own "Spin II Features" anybody?
I would like to make some observations.
1) Type correctness does not ensure program correctness.
Those who favour strongly typed languages are always pointing out how great it is to have the compiler spit out errors when the programmer uses the wrong types. However having all your types all "line up" does not guarantee that your program works as expected. You still need to test everything to be sure.
Now, given the super fast "edit-run" cycle when programming in Spin and given that you are going to test the thing anyway, those compile time type checks have less significance.
2) The most noobie friendly languages we have are things like Python and JavaScript. Where types are very sloppy things and errors don't show up until run time. Clearly noobies like loosely typed languages.
3) Currently Spin is gloriously simple. Adding types to it will make a pigs ear out of it. Given the added complexity on might think it is being turned into C. So why not just use C ?!
I kind of like John's idea. In order to allow floating point work one has to some how tell the compiler that the numbers involved are floats. That can be done by a type system or it by introducing some new weird operators that are the floating point versions of +,-,*,/ etc.
Or, as John said, somehow annotate expressions so that the arithmetic operators are doing float ops. How about a syntax like:
r := float(x * y / z + 3.2)
Where the thing that looks like a function called float simply causes the compiler to generate floating point ops for the expression in parenthesis.
I don't think I have see such an approaach in any language.
Heater,
Point 1 doesn't make any sense in the context you're delivering it. There is a place for strongly typed languages, and it does prevent situations even during testing that would cause damage to equipment or injury to personnel. Sometimes the only test is a live test. People try to stuff 1000 into a byte all the time. Even cooler I've seen smart pointers popping up more and more, preventing some real bone-headed things from happening. I don't know how this safety relates to spin, other than wishing there was some way to know when the stack was trashed because it was sized too small.
Point 2 lets me express my n00b frustration with Javascript. Maybe I want to do an integer division, and not have that decimal point stuff making things look ugly? It's not clear from the language how to do it without knowing all the ins and outs of the terminology. The worst abuse to me is just using a variable in an IF statement without a comparison. And that variable could be a function reference, function result, just a number, a string, etc. but one has to sift through the code to be sure.
The right way to answer Heater's query is to declare types of formal parameters:
That may well be true. Don't you also need types on the local variables? This approach starts to add a lot of verbosity and stuff for noobies to have to know. It's turning Spin in to C. Which seems a bit silly as we already have C.
It's definitely not turning Spin into C -- thank goodness! And the notion that Spin be relegated to a "noobie" language is just plain wrong. Anyway, anything would be less cumbersome than making all float operations be function calls, as is the case now. Other languages -- even simple ones like MSBasic -- use siglets to denote type. That might well be the best option for Spin. But the siglets belong on the variable names, not on the operators.
The cog will have fast multiply instructions (mul/muls) and 64-bit accumulation would take just two more instructions (add, addx). That's six clocks vs maybe 34 for a big math operation like CORDIC.
Extending that point, an extended precision use of Mul/Muls (with 4 multiplies, 3-64 bit adds, and a bunch of shifts) stands a good chance of being faster than a 34-clock big-math 32x32=>64 bit multiply. Still, the big-math wins on convenience. The big-math block may also win on speed if the cog can go do other stuff while the big-math block crunches away. (ofc, the cordic, square root, and divide are likely to be faster in all cases even at 34 clocks)
On the subject of floating point. With inline assembly in SPIN II, we should be able to code a super fast version of FME allowing inline floating point to handle more use cases. Also, packing and unpacking floats takes up a good fraction of the time used by current Prop1 floating point libraries. Re-factoring the API to avoid pack and unpack will also gain significant floating point speed. (i.e. unpack to a stack, do math operations on the stack, then pack the result once. This saves all the pack/unpack calls for intermediate values) Floats also have a TON of edge cases. Unless we need mega-flops, I'd rather have this functionality in software where debugging costs won't add to the silicon development time.
As shorthand for floating point operators, I'd be fine with ".*" "./" ".+" ".-" etc. Matlab uses them for "array" operators to quickly multiply the elements of an array. (instead of doing a matrix multiply or divide)
Point 1 doesn't make any sense in the context you're delivering it.
Why not?
I spent some years involved in software testing. Little projects like the fly-by-wire Primary Flight Computers of the Boeing 777 and Rolls Royce jet engine management systems. That code could well be written in a language that is very fussy about types, like Ada.
Guess what? Us guys doing the testing don't care. We will create unit tests that exercise every requirement we can find over all kinds of extremes of input values. That will cover every statement in the code. That will test every conditional for all it's possibilities, either side of the condition and at the extremes of the number ranges. And so on.
Also guess what? We find piles of bugs.
That's before we start on the integration tests. And then there is all those code reviews that go on.
Given that all this testing and reviewing is going on, which involves writing more lines of code than the actual code under test and takes an awful long time, one can see that the static checking the compilers do is actually insignificant to the quality of the finished product. All those possible type errors will have been discovered in testing.
Plus we are not going to trust the compiler anyway:) The tests have to be done.
Having said that, I do agree, for huge, safety critical projects I would go for a language like Ada. For tiny little programs in an MCU that can be compiled and tested in seconds all this type checking seems less valuable.
Oh, and now I remember, a lot of that Boeing PFC logic, were speed was of the essence, was done by custom processors in ASICs where the code was written in assembler. So much for type safety there.
Point 2 lets me express my n00b frustration with Javascript.
Adding types to method signatures sure looks C'ish to me.
I don't mean to imply that Spin is only a noobie language. Seasoned pros can appreciate it's simplicity as well. Let's not make it complex and ugly.
I really don't want to see float operations done in a function call syntax. Hence the suggestion for being able to define a kind of "scope" where all the operators become floating point operators.
VAR
long x, y
PUB doIt(x, y)
z := 2.1
return float(x + y * z)
I really don't want to see float operations done in a function call syntax. Hence the suggestion for being able to define a kind of "scope" where all the operators become floating point operators.
Re: return float(x + y * z) That's too confusing vis-a-vis other languages. The usual interpretation of that expression is to do the operations in integer and convert the result to float.
Heater, what's wrong with C'ish? If C has some nice feature that works well why not use it in Spin?
To me, the float(x + y * z) syntax implies that the integer expression (x + y * z) should be evaluated and then converted to floating point. I think it's much cleaner to declare x, y and z as float variables at one point in the code rather than scattering float() throughout the code.
Not that I am saying we NEED it for this version of the Prop. Just that IF Chip magically finds a way to include it that it would be a great feature to have.
How many MCU's in this class even have it? Would having it in the Prop give it a selection edge when being considered for a project?
Sure, I understand your disposition on the idea very clearly - if it's a snap then throw it in.
How many MCUs in this class have it? Not sure - how many have preemptive multithreaded in multicore environments? Also not sure.
It's nice to know that the Float32 objects and compilers will effectively handle these processes for us, even if they take cores (not cogs) to run.
I do agree that float(bla bla) clashes somewhat with what C++ programmers would expect. It's not used in C. Perhaps there is a better way to do that annotation.
By the way "The usual interpretation of that expression is to do the operations in integer and convert the result to float." is not correct, not in C++ anyway. In C++ it's same as the C style (float)(x * y / z) where x, y and z can be any type and will be cast upward if required. The final result being cast to float.
We already have enough in Spin to confuse C programmers. Like the operators. Why worry about adding more?
Dave,
what's wrong with C'ish?
Nothing wrong with C'ish. I love C. Can't live with out it.
My little point there is that Spin is not C. It's much leaner and meaner. I'm sure you have heard Spin supporters expounding on how nice that is.
So why make it more C'ish by adding complexity that will upset people? If you want C'ish use C, right.
As always, feel free to carry on any related discussions in these threads or as usual, just wherever you happen to be when the thought occurs, whether it be on topic or not!
Comments
electrodude
This sounds like a MathBlock version of HUB Slot mapping ? (Hub-Slot mapping has already been suggested, like this, it has a 4 bit identifier with each time-slot )
Mapping does allow users to allocate valuable time/bandwidth resource, instead of it being forced/locked to 1:16
In MathOps cases, there is of course the caveat that no new-operations can be done if they need a pending result.
The most common requests by the volume users have not frequently included floating point, though I recognize math is so much more productive to do this without integers, compilers and objects. This time we have 16 cogs and really high speed, so a math library wouldn't be as consuming as it were on Propeller 1. To me, that's a much easier sell than it was on Propeller 1 where it took at least a few cogs if I recall correctly.
I'm in Washington D.C. right now. This week I met with a consulting engineering firm who uses the Propeller in a telemetry application. The entire product has been achieved in a Propeller 1 but more RAM and a few more cores would meet the needs of the next revision nicely. They didn't mention floating point math as a clear need.
When features are so easy to add they could allow Parallax to leverage them for the next revision. Future improvements, no matter how fast they are completed, show that we're in this business for Parallax and our customers. Of course, I don't know anything about the design time required to add floating point, so it's very difficult to say if it's worth the effort at this stage. However, please feel free to disagree with me.
Ken Gracey
They probably never considered it as an option with this class of MCU. If you had it would they use it? Probably. Once they did they would then wonder how they ever got along without it.
Can I do process control without it? Yes. If the Prop has it would I use it? Yep. Would having it make a positive difference to my product. Without doubt.
Not that I am saying we NEED it for this version of the Prop. Just that IF Chip magically finds a way to include it that it would be a great feature to have.
How many MCU's in this class even have it? Would having it in the Prop give it a selection edge when being considered for a project?
As long as the MATHOP access window is out-of-phase with HUBOP access window, I'd think you could mux the QUADs between the two. If MATHOPs stall, then this definitely shouldn't be an issue.
There is a huge raft of applications that don't need floating point acceleration even if they do use floating point maths. The C compilers give you floating point with no effort.
I suspect floating point should some how be added to the Spin language. Now that the Spin byte code interpreter is not in ROM or confined to a COG that should be doable. I'm not sure how this would look in Spin as there aren't really any types in the language.
If anyone needs floating point acceleration in their MCU they are not going to be using a Propeller even if it does get a floating point unit. I can't imagine that the performance would be comparable.
So my feeling is that there is no benefit in investing time, effort and power budget on floating point hardware. At least not for this iteration of the P2.
Spin does have types it has BYTE WORD and LONG in a VAR's definition so could be done there, when any maths is done on it, to use the FLOAT functions.
Is Spin still going to be part of the ROM? I thought it was not going to be part of the ROM, yes this would get messy with many versions floating around, but it would then definitely also allow for a floating version of Spin. ( although even if it was in ROM we could still do a float variant of spin in RAM )
Spin does not really have types. BYTE, WORD, LONG determine the amount of storage used. But what about when passing parameters to methods? Inside the method it has no idea what types it is dealing with. What about when sending pointers to different types through mail box structures and so on.
The Spin compiler would start F32 and translate y := m * x + b to
y := F.FADD(F.FMUL(m,x),b)
John Abshier
How would this be handled?
VAR long l1, l2 float f1, f2 PUB start | l, f l := doIt (l1, l2) ' What are l and f, float or int? f := doIt (f1, f2) PUB doIt (x, y) return x * y ' Float or integer multiply?John Abshier
Perhaps a single tick (`) character before the operator:
y := m `* x `+ b
If there was some simple way to differentiate floating point operators, that might be all that is needed. Or, let float be the default and have special integer operators.
When the types of the variables are known, the rule is simple: always promote the operation to the higher of its two arguments, converting as necessary. The compiler just needs to keep track of the type on its syntax stack. The right way to answer Heater's query is to declare types of formal parameters:
-Phil
Or just make F32's functions part of the language.
I would like to make some observations.
1) Type correctness does not ensure program correctness.
Those who favour strongly typed languages are always pointing out how great it is to have the compiler spit out errors when the programmer uses the wrong types. However having all your types all "line up" does not guarantee that your program works as expected. You still need to test everything to be sure.
Now, given the super fast "edit-run" cycle when programming in Spin and given that you are going to test the thing anyway, those compile time type checks have less significance.
2) The most noobie friendly languages we have are things like Python and JavaScript. Where types are very sloppy things and errors don't show up until run time. Clearly noobies like loosely typed languages.
3) Currently Spin is gloriously simple. Adding types to it will make a pigs ear out of it. Given the added complexity on might think it is being turned into C. So why not just use C ?!
I kind of like John's idea. In order to allow floating point work one has to some how tell the compiler that the numbers involved are floats. That can be done by a type system or it by introducing some new weird operators that are the floating point versions of +,-,*,/ etc.
Or, as John said, somehow annotate expressions so that the arithmetic operators are doing float ops. How about a syntax like: Where the thing that looks like a function called float simply causes the compiler to generate floating point ops for the expression in parenthesis.
I don't think I have see such an approaach in any language.
Chip,
I really really hate those tick marks. Very ugly.
Heater,
Point 1 doesn't make any sense in the context you're delivering it. There is a place for strongly typed languages, and it does prevent situations even during testing that would cause damage to equipment or injury to personnel. Sometimes the only test is a live test. People try to stuff 1000 into a byte all the time. Even cooler I've seen smart pointers popping up more and more, preventing some real bone-headed things from happening. I don't know how this safety relates to spin, other than wishing there was some way to know when the stack was trashed because it was sized too small.
Point 2 lets me express my n00b frustration with Javascript. Maybe I want to do an integer division, and not have that decimal point stuff making things look ugly? It's not clear from the language how to do it without knowing all the ins and outs of the terminology. The worst abuse to me is just using a variable in an IF statement without a comparison. And that variable could be a function reference, function result, just a number, a string, etc. but one has to sift through the code to be sure.
But somehow I agree with point 3.
It's definitely not turning Spin into C -- thank goodness! And the notion that Spin be relegated to a "noobie" language is just plain wrong. Anyway, anything would be less cumbersome than making all float operations be function calls, as is the case now. Other languages -- even simple ones like MSBasic -- use siglets to denote type. That might well be the best option for Spin. But the siglets belong on the variable names, not on the operators.
-Phil
Extending that point, an extended precision use of Mul/Muls (with 4 multiplies, 3-64 bit adds, and a bunch of shifts) stands a good chance of being faster than a 34-clock big-math 32x32=>64 bit multiply. Still, the big-math wins on convenience. The big-math block may also win on speed if the cog can go do other stuff while the big-math block crunches away. (ofc, the cordic, square root, and divide are likely to be faster in all cases even at 34 clocks)
On the subject of floating point. With inline assembly in SPIN II, we should be able to code a super fast version of FME allowing inline floating point to handle more use cases. Also, packing and unpacking floats takes up a good fraction of the time used by current Prop1 floating point libraries. Re-factoring the API to avoid pack and unpack will also gain significant floating point speed. (i.e. unpack to a stack, do math operations on the stack, then pack the result once. This saves all the pack/unpack calls for intermediate values) Floats also have a TON of edge cases. Unless we need mega-flops, I'd rather have this functionality in software where debugging costs won't add to the silicon development time.
As shorthand for floating point operators, I'd be fine with ".*" "./" ".+" ".-" etc. Matlab uses them for "array" operators to quickly multiply the elements of an array. (instead of doing a matrix multiply or divide)
Marty
I spent some years involved in software testing. Little projects like the fly-by-wire Primary Flight Computers of the Boeing 777 and Rolls Royce jet engine management systems. That code could well be written in a language that is very fussy about types, like Ada.
Guess what? Us guys doing the testing don't care. We will create unit tests that exercise every requirement we can find over all kinds of extremes of input values. That will cover every statement in the code. That will test every conditional for all it's possibilities, either side of the condition and at the extremes of the number ranges. And so on.
Also guess what? We find piles of bugs.
That's before we start on the integration tests. And then there is all those code reviews that go on.
Given that all this testing and reviewing is going on, which involves writing more lines of code than the actual code under test and takes an awful long time, one can see that the static checking the compilers do is actually insignificant to the quality of the finished product. All those possible type errors will have been discovered in testing.
Plus we are not going to trust the compiler anyway:) The tests have to be done.
Having said that, I do agree, for huge, safety critical projects I would go for a language like Ada. For tiny little programs in an MCU that can be compiled and tested in seconds all this type checking seems less valuable.
Oh, and now I remember, a lot of that Boeing PFC logic, were speed was of the essence, was done by custom processors in ASICs where the code was written in assembler. So much for type safety there. Nooo. Not here. We have a special thread for the JavaScript debate here: http://forums.parallax.com/showthread.php/152201-The-Official-JavaScript-Religious-War-Thread. Please join in.
Adding types to method signatures sure looks C'ish to me.
I don't mean to imply that Spin is only a noobie language. Seasoned pros can appreciate it's simplicity as well. Let's not make it complex and ugly.
I really don't want to see float operations done in a function call syntax. Hence the suggestion for being able to define a kind of "scope" where all the operators become floating point operators.
Re: return float(x + y * z) That's too confusing vis-a-vis other languages. The usual interpretation of that expression is to do the operations in integer and convert the result to float.
-Phil
To me, the float(x + y * z) syntax implies that the integer expression (x + y * z) should be evaluated and then converted to floating point. I think it's much cleaner to declare x, y and z as float variables at one point in the code rather than scattering float() throughout the code.
Sure, I understand your disposition on the idea very clearly - if it's a snap then throw it in.
How many MCUs in this class have it? Not sure - how many have preemptive multithreaded in multicore environments? Also not sure.
It's nice to know that the Float32 objects and compilers will effectively handle these processes for us, even if they take cores (not cogs) to run.
Ken Gracey
I do agree that float(bla bla) clashes somewhat with what C++ programmers would expect. It's not used in C. Perhaps there is a better way to do that annotation.
By the way "The usual interpretation of that expression is to do the operations in integer and convert the result to float." is not correct, not in C++ anyway. In C++ it's same as the C style (float)(x * y / z) where x, y and z can be any type and will be cast upward if required. The final result being cast to float.
We already have enough in Spin to confuse C programmers. Like the operators. Why worry about adding more?
Dave, Nothing wrong with C'ish. I love C. Can't live with out it.
My little point there is that Spin is not C. It's much leaner and meaner. I'm sure you have heard Spin supporters expounding on how nice that is.
So why make it more C'ish by adding complexity that will upset people? If you want C'ish use C, right.
We got them.......nobody wants to use them!
Spin2/PASM2 Implementation - How to do it - Byte codes, native code, COG mode VM, HUBEXEC VM, etc. (threaded interpreter, anyone??)
Spin2/PASM2 Language Definition - Language definition, added features, missing features
As always, feel free to carry on any related discussions in these threads or as usual, just wherever you happen to be when the thought occurs, whether it be on topic or not!
Type checking in SPIN isn't something I would want to see personally.
Frankly, given we get inline PASM, I would much prefer we continue to use functions, rather than complicate SPIN.