This is an extract of the requirement in the first post...
We are seeking a contractor who would complete a direct and feature-equivalent port from Spin/PASM to C/PASM for the S3 robot code base. The BlocklyProp system for programming the S3 would stay the same on the surface but we would modify the blocks to support equivalent C code generation on our demo system. To see the top-level Spin code created by Blockly, create an S3 program in blockly.parallax.com and click on view - code. All of the underlying Spin/PASM files used are the “Scribbler Default V2579.zip” listed in the S3 Open Source Files download link below. The inclusion of the PASM code would be directly included in the C environment. The translated Spin to C code base would be fully tested and included as part of our Simple Libraries distribution and of course be used in the Blockly system.
My understanding from this is that all spin modules in the zip file must be converted to C. In addition, Parallax requires a direct and feature-equivalent port. That therefore includes the scribbler_default.spin program, which includes all the other programs including the scribbler-test program. This program in spin/pasm only has 536 longs free including the spin stack. And this is before C conversion which we all know takes a heck of a lot more code space than spin.
This is an extract of the requirement in the first post...
We are seeking a contractor who would complete a direct and feature-equivalent port from Spin/PASM to C/PASM for the S3 robot code base. The BlocklyProp system for programming the S3 would stay the same on the surface but we would modify the blocks to support equivalent C code generation on our demo system. To see the top-level Spin code created by Blockly, create an S3 program in blockly.parallax.com and click on view - code. All of the underlying Spin/PASM files used are the “Scribbler Default V2579.zip” listed in the S3 Open Source Files download link below. The inclusion of the PASM code would be directly included in the C environment. The translated Spin to C code base would be fully tested and included as part of our Simple Libraries distribution and of course be used in the Blockly system.
My understanding from this is that all spin modules in the zip file must be converted to C. In addition, Parallax requires a direct and feature-equivalent port. That therefore includes the scribbler_default.spin program, which includes all the other programs including the scribbler-test program. This program in spin/pasm only has 536 longs free including the spin stack. And this is before C conversion which we all know takes a heck of a lot more code space than spin.
So I guess you're saying that all of the other code that is in the S3 github repository is not needed. I guess that's good news. However, I don't see why the test code can't be split off and run as a second executable. That doesn't technically meet Ken's requirements but, as you say, there is probably no way to meet them with a single executable. This might be the best compromise. I guess we'll know early next week how Ken intends to proceed with this project and who will do it.
Cluso, would you like to contact Ken and tell him what he's asking for is impossible? I'm sure Ken realizes that some trade-offs may have to be made. I have already described an approached that could be used to provide functionally equivalent C code that would fit on the S3. I do agree that more detailed requirements are needed about the Spin-to-C conversion. When I sent Ken my proposal it was based on some assumptions about what he wants to do. Things should become clearer next week when Ken posts his decisions about the project. I'm sure his plan will factor in the issues and solutions that have been discussed in this thread.
Ken has kindly sent me an S3 robot, and so I was able to do some debugging of spin2cpp's output. It turns out there were some serious bugs -- wordfill() with all 0 was producing incorrect code sometimes, and the "res" operator was behaving differently with respect to hub addresses than in openspin. WIth these fixes, which are in spin2cpp 3.2.1, I was able to get some C code running on the S3. Note that the DAT section translation is still pretty ugly, so whoever does do the final conversion will have to clean that up manually, but at least the code seems to work.
Note that the DAT section translation is still pretty ugly, so whoever does do the final conversion will have to clean that up manually, but at least the code seems to work.
I was a little too hasty -- a *very* simple program works, but things that use the motors don't work properly yet. Also, there's a bug in the C translation of coginit, which is fixed in the spin2cpp source code but not (yet) in the binary release.
Yes, good work on spin2cpp. It looks like the S3 code is helping to wring out a few issues in spin2cpp, and it will make it an even more useful utility.
Yes, this is definitely an interesting code base and it has turned up several nasty bugs. I just fixed the motor control function (the underlying bug was a mistake in assigning dat label values after an expression like FOO[3]; plain integer constants like 0[3] advanced the PC correctly, but FOO[3] was only adding 1 to the PC ). The new version is 3.2.2. Anyone working on the S3 code should use the latest spin2cpp release, or even better compile it from source -- that way you definitely know you're up to date!
Yes, this is definitely an interesting code base and it has turned up several nasty bugs. I just fixed the motor control function (the underlying bug was a mistake in assigning dat label values after an expression like FOO[3]; plain integer constants like 0[3] advanced the PC correctly, but FOO[3] was only adding 1 to the PC ). The new version is 3.2.2. Anyone working on the S3 code should use the latest spin2cpp release, or even better compile it from source -- that way you definitely know you're up to date!
As far as I know, Ken has yet to decide who is working on the S3 code.
Any update on this? Is Parallax still planning to hire someone to do this porting or will they handle it internally now that Eric has enhanced spin2cpp?
Eric's improvements to Spin2Cpp seem to have done wonders for this project. Last week we successfully ported the entire code base and ran it in SimpleIDE. In the meantime we owe a tremendous amount of appreciation to David Betz, Dave Hein, Cluso and Brett Weir for providing us with very well-thought proposals for manual conversion.
We still have testing to do as well as some top-level cleanup by putting files into includes.
Eric's improvements to Spin2Cpp seem to have done wonders for this project. Last week we successfully ported the entire code base and ran it in SimpleIDE. In the meantime we owe a tremendous amount of appreciation to David Betz, Dave Hein, Cluso and Brett Weir for providing us with very well-thought proposals for manual conversion.
We still have testing to do as well as some top-level cleanup by putting files into includes.
Ken Gracey
I know many people here like the idea of putting code in include files but I still think it is a bad idea. I would discourage you from doing that.
Here's the thing, David. Blockly is a high-level programming tool and the use of C in the S3 robot is quite basic - introductory at best, consisting of basic function calls. Blockly provides a first-time look at C code for many and we need to keep their exposure to it fairly simple in order to introduce them to the next steps.
Here's the thing, David. Blockly is a high-level programming tool and the use of C in the S3 robot is quite basic - introductory at best, consisting of basic function calls. Blockly provides a first-time look at C code for many and we need to keep their exposure to it fairly simple in order to introduce them to the next steps.
But won't this body of code also be used for people who want to code the S3 directly in C without using Blockly?
I'm curious status of this project. According to the original post it was supposed to be done by the end of October. I am interested in hearing how the code size issues were handled. Was the test portion of the code put into the upper half of the EEPROM?
Comments
My understanding from this is that all spin modules in the zip file must be converted to C. In addition, Parallax requires a direct and feature-equivalent port. That therefore includes the scribbler_default.spin program, which includes all the other programs including the scribbler-test program. This program in spin/pasm only has 536 longs free including the spin stack. And this is before C conversion which we all know takes a heck of a lot more code space than spin.
We have put a short-term hold on making an official decision as we communicate with Eric Smith about Spin2cpp, which could make the job much easier.
Therefore, if you'll give us a tad more time to do this we will return and discuss the next step.
Ken Gracey
We still have testing to do as well as some top-level cleanup by putting files into includes.
Ken Gracey
I'm sure there are some, yes. Yet we have to target a particular audience and try to serve them well to make the product successful.
Ken Gracey