Sounds good. Do you have an example of how the user gets at Propellerisms like waitcnt ? - the xBasic manual does not find Bytecode or ASM ?
Here is an example of how the waitcnt and waitpne functions are implemented. You'll see that this is a combination of xbasic bytecodes and native Propeller instructions. I wrote a simple PASM assembler for xbasic but haven't had time to integrate it. That's why the Propeller instructions are in hex.
def waitcnt(n)
asm
lref 0
native 0xf87c0a00 // waitcnt tos, #0
returnx
end asm
end def
def waitpne(state, mask)
asm
lref 1 // get mask
native 0xa0bc0205 // mov t1, tos
lref 0 // get state
native 0xf4bc0a01 // waitpne tos, t1 wr
returnx
end asm
end def
I am currently infatuated with JavaScript. It has features that only recently Java and C++ has have tried to implement. First class functions, Lambdas, closures, etc. It's evented model of programming makes many jobs very easy.
...or, you could use a careful subset (checked with a javascript module, of course ) and then target a Prop hosted variant. Of course, you now need a Prop specific byte code compiler somewhere. ( a .js Parser version of xBasic perhaps ? )
I'm not sure I follow where you are going with that.
I would say that sub-setting JS invalidates the whole idea. Might as well go with a different language to avoid confusion.
The Espruino JS interpreter is a bout as small as it gets. 50 odd K bytes. I'm hoping to see that running on the Props, especially PII, one day. Old incomplete versions of Espruino do run on the prop with external RAM attached. Slowly.
JavaScript interpreters do not use bytecodes. They interpret the raw text of the JS source. Of course JS engines in browsers do actually JIT that source to machine code as they run. But those engines are huge.
JavaScript interpreters do not use bytecodes. They interpret the raw text of the JS source. Of course JS engines in browsers do actually JIT that source to machine code as they run. But those engines are huge.
I'm not sure this is universally true. I have certainly seen JavaScript interpreters that compile to bytecode on the fly. I've never seen one where you can precompile something and load already compiled bytecode binaries though. You've probably already gathered that I like playing with languages. I also have a language called Bob that looks a lot like JavaScript and it compiles to bytecodes on the fly but it can also load already compiled bytecode binaries.
Interesting. I guess compiling JS to byte codes as it runs, JIT fasion, is much the same as compiling to some native instructions. Isn't there a JS engine that translates on the fly to Java byte codes?
As far as I understand compiling JS to static code, native or byte code, is not possible because the types are so dynamic. You might have a nice loop running around arrays of numbers which you could make static code for. But then at any time your program can dump an object or array into an element of your array. BOOM you have to dynamically reorganize your code for that. And what would you do with "eval"? You need the JS compiler in your run time!
Except of course for the JavaScript subset called asm.js which is written to certain rules such that the run time can make assumptions about types and optimize for that. FireFox's SpiderMonkey handles asm.js source amazingly quickly.
Emscripten compiles C/C++ to asm.js standard JavaScript. That's how FireFox can run fft_bench only about 6 times slower than native code!
That's all well and good but asm.js is not intended to be written by humans. Much like Lisp:)
I'm told that every programming language evolves to become lisp eventually if it does not die off first.
I know everyone hates parens in Lisp but they never bothered me. In any case, I agree that JavaScript has some nice features and might be a good language to use for controlling robots. I guess Parallax needs to describe in more detail what they're looking for since it's hard to suggest a solution without knowing the problem space. I do think it would be good to provide a way for the "program", whatever that ends up being, to run on the robot itself rather than being fed simple "go left", "start", "stop" like commands from a controller over Wi-Fi. As others have said, learning to program autonomous behavior is one of the exciting aspects of robot programming.
I do think it would be good to provide a way for the "program", whatever that ends up being, to run on the robot itself rather than being fed simple "go left", "start", "stop" like commands from a controller over Wi-Fi
I could not agree more.
If the students are so far removed from reality what is the point of the exercise anyway? That was what my little joke about replacing the Prop with a simulation was about.
I want to know why they don't put the iPads aside and break out the soldering irons and multi-meters.
I want to know why they don't put the iPads aside and break out the soldering irons and multi-meters.
1) Liability - nobody every got burned (physically) by an iPad.
2) Qualified instructors. Hands on skills need to be taught by people with hands on experience. There is probably a small percentage of the population that can solder - an even smaller percentage of teachers.
Ken is CEO of Megacorp (highly placed in the fortune 500), we're his collected senior staff (Presidents, Executive VP's, Chief Techonolgy Officers, etc.) On the 29th, he brought this idea up at a staff meeting. This morning, he send out an email:
"People,
There has been 10 days of debate on this and only two groups have anything coming close to a proof of concept. Let me restate the goals and give you some timeframes to help you focus. Congratulations to those that have used this time wisely.
My son's robotics class has been given iPads, I have a number of ActivityBOTs that I am donating to the school. They WILL start using these items when the new semester begins after Winter Holiday. They NEED to be able to control and/or program these robots through their iPads in some fashion.
I want working proofs of concept in my office by December 2nd.
A usable solution scaled to the class size of 25 robots should be ready to set up in the classroom over the Winter Holiday.
The system should be tested and ready to use by the second week of the semester.
You know what resources and tools are available or can be available in this short time frame. Your resources are unlimited (because you're all volunteers! )
This is important strategically to the company and has a lot of community visibility.
I know you and your teams won't let me down so close to the end after the fine year we've had and the important gains we've made.
An interesting language I've dealt with is RobotBasic http://www.robotbasic.org/. Too bad it only works on Windows otherwise it may have been a good fit since works with serial and can run on a web page.
EDIT: I found that RobotBasic works in Linux with Wine but getting a Raspberry PI to do Wine is tricky.
I'm sure it was brought up in passing a couple times, but here's using a method that would get everything they are looking for. You can get Python for the IOS https://itunes.apple.com/us/app/python-2.7-for-ios/id485729872?mt=8. This allows instruction with a Python, which is as desirable a teaching language as any.
If you used the WIFI ad-hoc connection to an Rpi, and the PropForth kernel running on the Prop Board (yes I know, don't shoot me), you would have all the pieces. The only thing that would be needed is a nice dictionary for the robot (ActivityBot). This would keep the robot specific control local to the prop, and allow on-the-fly programming in Python from the IOS.
You could keep the dictionaries on the IOS side or the Prop side. This requires no compiling (except once for the kernel). If you don't like Forth, you could go with some other Prop interpreter language and achieve the same results. Don't be mad at me about the Forth idea - I'm still learning it, and getting used to it, but it seems like a clean solution that is already pretty much implementable.
However, I'm not happy with the way the Python folks have handled the transition from 2.x to 3.x with respect to syntax and multi-os distribution. If it is any indication, the transition from 3.x to 4.x won't be any better.
I've been taking a Python class and trying out applications that use the serial port, but I won't get very serious with Python until syntax and other things have matured. It's kind of like .net all over again.
However, I'm not happy with the way the Python folks have handled the transition from 2.x to 3.x with respect to syntax and multi-os distribution. If it is any indication, the transition from 3.x to 4.x won't be any better.
I've been taking a Python class and trying out applications that use the serial port, but I won't get very serious with Python until syntax and other things have matured. It's kind of like .net all over again.
They changed the language syntax between 2.x and 3.x? Is it backward compatible?
Not entirely. For example, 2.7 allows print "hello" 3.3 requires print("hello")
Maybe there is a compatibility switch ?
It doesn't sound like there's a switch from everything I've read. Pick one or the other and it is usually clearly stated in the code package which version something is written for.
I do think it would be good to provide a way for the "program", whatever that ends up being, to run on the robot itself rather than being fed simple "go left", "start", "stop" like commands from a controller over Wi-Fi. As others have said, learning to program autonomous behavior is one of the exciting aspects of robot programming.
Maybe this was already covered, but what is the consensus of using the audio out port on the iPad for data out? Similar to the credit card swipe devices that are in use all over the place on iPads? It sure seems like a simple solution to have a text editor for writing code that sends the text file to a server, then the server sends back the compiled file to the iPad app, the app then sends 32k file to a Propeller Programming module that is plugged into the robot or other Prop device. Then for control, use the audio out data to a Nordic tranceiver which talks to the robot. Program each robot by ID.
This would allow any number or Prop devices to be programmed via ID, the iPad app sends the 32k to the Programmer/Tranceiver Module, the Programmer sends the opcodes with the device ID followed by the 32k data, all devices will see the data but only the ID instructed to update it's program will store the 32k(verify checksum etc) and overwrite it's program.
This argument I do not quite follow. If you want to run on a small target micro, you have a subset of resource available.
A pint is a subset of a gallon but I'm not sure I would say a NAND gate is a subset of a flip-flop. Take that gate away and you don't have a flip-flop at all. One is a quantitative difference and the other is a qualitative difference.
Sure an MCU has smaller memory and slower speed etc but it's qualitatively still a computer.
Sub-setting a programming language is removing features from that language. Remove enough significant features and it's not the same language anymore. In the world of programming languages having standards is very important. Having missing features and surprises is a no no. That may be a surprise for those used to the woolly world of BASIC and other languages where there are no standards and every implementation is somewhat different.
Any, whichever way you look at it, what features would you remove from JavaScript in order to make it's run time smaller and suitable for running on a Prop?
JavaScript is already a pretty minimalist language. The Espruino implementation is down to 40KB and it pretty much manages to covers the whole language.
In fact, that is the way to move the execution engine from browser to target inorder to get autonomous operation. Just add a 2 dollar STM32 ARM micro on a tiny board to the target. The JS runs on the ARM and the real-time stuff runs on the Propeller.
In fact, that is the way to move the execution engine from browser to target inorder to get autonomous operation. Just add a 2 dollar STM32 ARM micro on a tiny board to the target. The JS runs on the ARM and the real-time stuff runs on the Propeller.
See how your 'logic' has removed the Prop entirely from the language candidate ?
So it's not likely to interest Parallax.
I prefer to focus on what I can use a language for, rather than on what may be excluded.
I am used to working in constrained systems, if a PC has 8 byte Reals, and a uC does not, that does not prevent me from using both.
Thus I consider something like CogC a significant feature of Gcc.
A subset-averse designer, would never have created CogC.
Rather than complain and dismiss "it's not the same language anymore", I tend to be more optimistic, and consider it is better than PASM, and a nice soft transition candidate - sure, some operator skill will be needed, due to the constraints.
See how your 'logic' has removed the Prop entirely from the language candidate ?
Yep it did. I'm not sure that it was my logic so much as the demands of the problem posed on this thread which sound like:
a) Must be able to use an iPad.
b) Students and teachers don't want anything very taxing (like having to program an actual micro-controller:))
OK. Let's leave JS out of this. One day we may get JS running on a PII with it's extra speed and external RAM. Even then it may only ever be a curiosity.
Thus I consider something like CogC a significant feature of Gcc.
I agree. Whatever solution comes up here it should allow programming the naked Propeller in C/C++ and Spin. All we need to attain is:
1) An editor/IDE to use in the browser. Solutions are available: Web IDE or Cloud 9 or ACE or whatever.
2) A server or servers able to compile the C/++ and Spin. Solutions are available: anything from a Raspberry Pi per Propeller to a more class central PC or even a totally remote machine in the cloud.
3) A means of getting binaries downloaded to the Props. Solutions have been proposed: WIFI dongles, other wireless links, even direct serial cables.
4) A means of communicating from Prop to server to browser when the Prop program is running. Hopefully using the same link as used for programming. HTML5 websockets will help a lot here.
A subset-averse designer, would never have created CogC.
CogC is not a subset of C. It is C.
The issue of Parallax creating a subset of C or a "C like" language compiler that would be more friendly to the Propeller was discussed here at length some time ago. I forget the name of the project was. The Proposal was roundly rejected.
As it turns out such a subset was not required. The propgcc gurus worked their magic and got the real thing working really well.
Why was the sub-setting idea rejected? Mostly I think it comes down to two major points:
1) Anyone looking for C on the Propeller would be very disappointed to see some inferior C like language instead. It would be a joke, toy language. The last thing this world needs is yet another language to deal with.
2) Anyone starting out with the Prop and this C half breed would be starting on the wrong foot. In that way it is better they start with something obviously very different from C, like Spin.
With the COG only to run in, it must be a subset - you simply cannot fit one instance of all C supports, compiled into a COG.
Even printf has an alternative, yes, a subset, that is better suited to the Prop.
I would be interested in ceiling cases, of what is practical to draw from C, and fit into a COG.
eg Will it overflow a COG, to do Real and long mathsops for sensor scaling ?
What about long long mathops, even in the special subset case, of an interim result ?
With the COG only to run in, it must be a subset - you simply cannot fit one instance of all C supports, compiled into a COG. Even printf has an alternative, yes, a subset, that is better suited to the Prop.
Ah, I see what you mean. Something like "you can't have printf in cog therefore it's a subset of C"
Now I know the standard C library is, well, specified in the C standard. But I take a rather different view of things.
To my mind there is C the language. The language is defined by it's syntax and semantics as laid out in the standards documents.
Then there are the libraries with our beloved printf and everything else.
Whilst those libraries are in the standards spec they are not the language as such. It is perfectly possible to progam in C for years without ever using any functions from the standard library. I have done so. The Linux kernel does so. Many other projects do. You are still working in C though.
Ergo C iin COG is C, the core C. Just without the libs. This is demonstrated by the fact that in my FFT running in HUB the compier can decide to cache the inner loops into COG and run them there much faster. I don't have to do anything sopecial to make that happen. Appart from, say, sticking a printf in the middle"
I would be interested in ceiling cases, of what is practical to draw from C, and
fit into a COG.
I have a couple of examples:
1) fft_bench. As stated above it was not written to run in COG but it's three nested inner loops can be "fcached" into COG at run time. There it performs the FFT nearly as fast as the hand crafted PPASM version of the same thing I made. I am amazed it fits in COG!
2) Serial port. My "full_duplex_serial_ht" is a UART Tx and Rx writen in C and running in COG. Works up to 115200 baud.
Have a look in the progcc demos directory.
Will it overflow a COG, to do Real and long mathsops for sensor scaling ? What about long long mathops, even in the special subset case, of an interim result ?
No idea. In theory such operations can be compiled into COG. F32 shows that a lot of floating point code will fit. doubles probabply not. Here we are really hitting memory limits not the language per se.
There is one place where I think I have to conceed that C in COG is a subset of "real C". That is in the support of recursive function calls. The COG C code I have generated uses the normal PASM calling convention, not a call stack, so recursive calls are not possible. I'm nt sure if it's even possible.
Something for classrooms, iPads and robots does NOT need to do everything, nor support more than one language. Putting in the ability to do everything increases complexity and this becomes a use barrier. How would the propeller sell on the educational market if there weren't 20 different form factors, four basics, three c languages and most of the support objects in a proprietary language???
An educationally targeted entry level system needs to support kids, not engineers, not the people on this forum. (all that complex stuff is for them)
Comments
def waitcnt(n) asm lref 0 native 0xf87c0a00 // waitcnt tos, #0 returnx end asm end def def waitpne(state, mask) asm lref 1 // get mask native 0xa0bc0205 // mov t1, tos lref 0 // get state native 0xf4bc0a01 // waitpne tos, t1 wr returnx end asm end defI'm not sure I follow where you are going with that.
I would say that sub-setting JS invalidates the whole idea. Might as well go with a different language to avoid confusion.
The Espruino JS interpreter is a bout as small as it gets. 50 odd K bytes. I'm hoping to see that running on the Props, especially PII, one day. Old incomplete versions of Espruino do run on the prop with external RAM attached. Slowly.
JavaScript interpreters do not use bytecodes. They interpret the raw text of the JS source. Of course JS engines in browsers do actually JIT that source to machine code as they run. But those engines are huge.
Well, perhaps nearly.
I'm told that every programming language evolves to become lisp eventually if it does not die off first.
Interesting. I guess compiling JS to byte codes as it runs, JIT fasion, is much the same as compiling to some native instructions. Isn't there a JS engine that translates on the fly to Java byte codes?
As far as I understand compiling JS to static code, native or byte code, is not possible because the types are so dynamic. You might have a nice loop running around arrays of numbers which you could make static code for. But then at any time your program can dump an object or array into an element of your array. BOOM you have to dynamically reorganize your code for that. And what would you do with "eval"? You need the JS compiler in your run time!
Except of course for the JavaScript subset called asm.js which is written to certain rules such that the run time can make assumptions about types and optimize for that. FireFox's SpiderMonkey handles asm.js source amazingly quickly.
Emscripten compiles C/C++ to asm.js standard JavaScript. That's how FireFox can run fft_bench only about 6 times slower than native code!
That's all well and good but asm.js is not intended to be written by humans. Much like Lisp:)
I could not agree more.
If the students are so far removed from reality what is the point of the exercise anyway? That was what my little joke about replacing the Prop with a simulation was about.
I want to know why they don't put the iPads aside and break out the soldering irons and multi-meters.
1) Liability - nobody every got burned (physically) by an iPad.
2) Qualified instructors. Hands on skills need to be taught by people with hands on experience. There is probably a small percentage of the population that can solder - an even smaller percentage of teachers.
Ken is CEO of Megacorp (highly placed in the fortune 500), we're his collected senior staff (Presidents, Executive VP's, Chief Techonolgy Officers, etc.) On the 29th, he brought this idea up at a staff meeting. This morning, he send out an email:
"People,
There has been 10 days of debate on this and only two groups have anything coming close to a proof of concept. Let me restate the goals and give you some timeframes to help you focus. Congratulations to those that have used this time wisely.
My son's robotics class has been given iPads, I have a number of ActivityBOTs that I am donating to the school. They WILL start using these items when the new semester begins after Winter Holiday. They NEED to be able to control and/or program these robots through their iPads in some fashion.
I want working proofs of concept in my office by December 2nd.
A usable solution scaled to the class size of 25 robots should be ready to set up in the classroom over the Winter Holiday.
The system should be tested and ready to use by the second week of the semester.
You know what resources and tools are available or can be available in this short time frame. Your resources are unlimited (because you're all volunteers!
This is important strategically to the company and has a lot of community visibility.
I know you and your teams won't let me down so close to the end after the fine year we've had and the important gains we've made.
Sincerely,
Mr Big"
EDIT: I found that RobotBasic works in Linux with Wine but getting a Raspberry PI to do Wine is tricky.
If you used the WIFI ad-hoc connection to an Rpi, and the PropForth kernel running on the Prop Board (yes I know, don't shoot me), you would have all the pieces. The only thing that would be needed is a nice dictionary for the robot (ActivityBot). This would keep the robot specific control local to the prop, and allow on-the-fly programming in Python from the IOS.
You could keep the dictionaries on the IOS side or the Prop side. This requires no compiling (except once for the kernel). If you don't like Forth, you could go with some other Prop interpreter language and achieve the same results. Don't be mad at me about the Forth idea - I'm still learning it, and getting used to it, but it seems like a clean solution that is already pretty much implementable.
It works if it's pre-installed.
However, I'm not happy with the way the Python folks have handled the transition from 2.x to 3.x with respect to syntax and multi-os distribution. If it is any indication, the transition from 3.x to 4.x won't be any better.
I've been taking a Python class and trying out applications that use the serial port, but I won't get very serious with Python until syntax and other things have matured. It's kind of like .net all over again.
Not entirely. For example, 2.7 allows print "hello" 3.3 requires print("hello")
Maybe there is a compatibility switch ?
It doesn't sound like there's a switch from everything I've read. Pick one or the other and it is usually clearly stated in the code package which version something is written for.
So, I can depend on you (or someone else) change all that 2.7 code (including the code I wrote) for me before 2.7 is retired?
-Phil
LOL. Maybe you should mention this to the Python folks. They'll probably use sed though.
I'm on a confernece call right now getting laid off, so I should have some free time for 2.7 to 3.x conversions! :frown:
Ouch. Ya, my main gig was over last month so I get it.
Exactly. Which is why I look for common subsets.
This argument I do not quite follow.
If you want to run on a small target micro, you have a subset of resource available.
To me it is smarter to allow code blocks, and training, to be reused, than to jump to "a different language"
This provides another good example of a subset candidate.
iPad Controller(text editor/server interaction/buttons for robot control) < > Programmer/Nordic Master Module < > Robot Receiver Module(s)
This would allow any number or Prop devices to be programmed via ID, the iPad app sends the 32k to the Programmer/Tranceiver Module, the Programmer sends the opcodes with the device ID followed by the 32k data, all devices will see the data but only the ID instructed to update it's program will store the 32k(verify checksum etc) and overwrite it's program.
Sure an MCU has smaller memory and slower speed etc but it's qualitatively still a computer.
Sub-setting a programming language is removing features from that language. Remove enough significant features and it's not the same language anymore. In the world of programming languages having standards is very important. Having missing features and surprises is a no no. That may be a surprise for those used to the woolly world of BASIC and other languages where there are no standards and every implementation is somewhat different.
Any, whichever way you look at it, what features would you remove from JavaScript in order to make it's run time smaller and suitable for running on a Prop?
JavaScript is already a pretty minimalist language. The Espruino implementation is down to 40KB and it pretty much manages to covers the whole language.
In fact, that is the way to move the execution engine from browser to target inorder to get autonomous operation. Just add a 2 dollar STM32 ARM micro on a tiny board to the target. The JS runs on the ARM and the real-time stuff runs on the Propeller.
See how your 'logic' has removed the Prop entirely from the language candidate ?
So it's not likely to interest Parallax.
I prefer to focus on what I can use a language for, rather than on what may be excluded.
I am used to working in constrained systems, if a PC has 8 byte Reals, and a uC does not, that does not prevent me from using both.
Thus I consider something like CogC a significant feature of Gcc.
A subset-averse designer, would never have created CogC.
Rather than complain and dismiss "it's not the same language anymore", I tend to be more optimistic, and consider it is better than PASM, and a nice soft transition candidate - sure, some operator skill will be needed, due to the constraints.
a) Must be able to use an iPad.
b) Students and teachers don't want anything very taxing (like having to program an actual micro-controller:))
OK. Let's leave JS out of this. One day we may get JS running on a PII with it's extra speed and external RAM. Even then it may only ever be a curiosity. I agree. Whatever solution comes up here it should allow programming the naked Propeller in C/C++ and Spin. All we need to attain is:
1) An editor/IDE to use in the browser. Solutions are available: Web IDE or Cloud 9 or ACE or whatever.
2) A server or servers able to compile the C/++ and Spin. Solutions are available: anything from a Raspberry Pi per Propeller to a more class central PC or even a totally remote machine in the cloud.
3) A means of getting binaries downloaded to the Props. Solutions have been proposed: WIFI dongles, other wireless links, even direct serial cables.
4) A means of communicating from Prop to server to browser when the Prop program is running. Hopefully using the same link as used for programming. HTML5 websockets will help a lot here. CogC is not a subset of C. It is C.
The issue of Parallax creating a subset of C or a "C like" language compiler that would be more friendly to the Propeller was discussed here at length some time ago. I forget the name of the project was. The Proposal was roundly rejected.
As it turns out such a subset was not required. The propgcc gurus worked their magic and got the real thing working really well.
Why was the sub-setting idea rejected? Mostly I think it comes down to two major points:
1) Anyone looking for C on the Propeller would be very disappointed to see some inferior C like language instead. It would be a joke, toy language. The last thing this world needs is yet another language to deal with.
2) Anyone starting out with the Prop and this C half breed would be starting on the wrong foot. In that way it is better they start with something obviously very different from C, like Spin.
With the COG only to run in, it must be a subset - you simply cannot fit one instance of all C supports, compiled into a COG.
Even printf has an alternative, yes, a subset, that is better suited to the Prop.
I would be interested in ceiling cases, of what is practical to draw from C, and fit into a COG.
eg Will it overflow a COG, to do Real and long mathsops for sensor scaling ?
What about long long mathops, even in the special subset case, of an interim result ?
Now I know the standard C library is, well, specified in the C standard. But I take a rather different view of things.
To my mind there is C the language. The language is defined by it's syntax and semantics as laid out in the standards documents.
Then there are the libraries with our beloved printf and everything else.
Whilst those libraries are in the standards spec they are not the language as such. It is perfectly possible to progam in C for years without ever using any functions from the standard library. I have done so. The Linux kernel does so. Many other projects do. You are still working in C though.
Ergo C iin COG is C, the core C. Just without the libs. This is demonstrated by the fact that in my FFT running in HUB the compier can decide to cache the inner loops into COG and run them there much faster. I don't have to do anything sopecial to make that happen. Appart from, say, sticking a printf in the middle" I have a couple of examples:
1) fft_bench. As stated above it was not written to run in COG but it's three nested inner loops can be "fcached" into COG at run time. There it performs the FFT nearly as fast as the hand crafted PPASM version of the same thing I made. I am amazed it fits in COG!
2) Serial port. My "full_duplex_serial_ht" is a UART Tx and Rx writen in C and running in COG. Works up to 115200 baud.
Have a look in the progcc demos directory. No idea. In theory such operations can be compiled into COG. F32 shows that a lot of floating point code will fit. doubles probabply not. Here we are really hitting memory limits not the language per se.
There is one place where I think I have to conceed that C in COG is a subset of "real C". That is in the support of recursive function calls. The COG C code I have generated uses the normal PASM calling convention, not a call stack, so recursive calls are not possible. I'm nt sure if it's even possible.
So yeah, you got me there:)
An educationally targeted entry level system needs to support kids, not engineers, not the people on this forum. (all that complex stuff is for them)