C Objects in the Parallax Object Exchange
ImageCraft
Posts: 348
Parallax informed me that you can now upload C object files in the Object Exchange. When you upload an object, you can specify whether it is Spin, asm, or C, and you can also sort the list as well based on the type field.
I hope ICC users will share their objects. Thank you for your support.
// richard
I hope ICC users will share their objects. Thank you for your support.
// richard
Comments
ICC tends to create a lot of files, and the need for some of them are suspect. I wish ICC had a "clean" command so that generated files can be removed; putting generated files under source control is a no-no. The object exchange is a repository however lacking in normal source control tools it may be. I wouldn't want generated files there mainly because it's a waste of space and having them can cause big problems in some source control tools that professionals must use. I've used Eclipse for some C projects ... it has real and convenient source control; I would add makefiles for those projects to the object exchange I guess.
It seems that the common denominator is really the C (*.c *.h *.s) source files. Adding just those files would be reasonable as there would be little clutter in the exchange and users can just pick them up and use them in projects.
If one followed the example of what is created with the Propeller archive tool, the _README_.txt is similar to a Makefile, and the .spin files are like the C sources (*.[noparse][[/noparse]chs]).
I'm not suggesting anyone must follow an example really. I just want a good idea of what the community thinks is appropriate so that I can start committing files to the exchange.
This does open up a feature request for ICC ... Richard, it would be quite useful if ICC had an achive command similar to what the Propeller tool provides.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Any chance of getting a standalone compiler and loader for linux and or mac osx ? I'm willing to pay for it! (Before I embark myself into adding a port to sdcc or gcc)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I've looked quite closely at both of those and I reckon SDCC is the way to go. GCC appears to be a target with a much higher bar..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
That has a bytecode generator so it's a case of taking that bytecode and producing Propeller Code ( PASM, LMM or some other Propeller bytecode, even Spin bytecode ). A much simpler and easier proposition than writing the compiler itself. If one wants more than the compiler delivers out the box there's no choice but getting in up to one's elbow. It would be possible to rewrite the back-end code generator to target the Propeller to create a standalone compiler.
That's possibly why ImageCraft have based their offering around LCC. While I was simply day-dreaming about it, they actually did it.
Post Edited (hippy) : 8/16/2008 3:33:40 PM GMT
This is something I've been thinking about pretty seriously.. It's not suitable for everything, but the SPIN bytecode is reasonably flexible.. why not a compiler for BASIC.. or PASCAL.. or C to target the SPIN Interpreter..
Maybe a spin compiler that understands a "BAS" block or A "CC" block..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Well I have added a new port to LCC, it is crude, it needs some serious help from a kernel but it works (sort of)... but I'll do my best to have something more working really soon. Stay tuned.
Here a crude example
I cannot comment on licensing and any agreements, or how extensively LCC may be used, but iccv7prop certainly acknowledges its use and indicates relevant permissions have been granted ...
Full LCC lcensing details here : drh.svnrepository.com/svn/lcc/trunk/CPYRIGHT
Writing a standalone bytecode to Propeller back-end would probably be okay. IANAL.
Post Edited (hippy) : 8/16/2008 9:10:27 PM GMT
The backend lburg is great.... for 32 bits RISC machines. All our code generators generate some sort of pseudo-asm code internally so we can perform optimizations. Otherwise, the code will not be competitive for production use.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Spin byte code could be generated. But that would mean converting a register based compiler into a stack based one... maybe with a modified kernel that could be done more efficiently, it should be possible.
My approach would be to design a virtual instruction set which does the job required, knock up a a simple assembler for that and then optimise from there.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jazzed: Are you going to post your C VGA driver?
I will post more as time permits (one a day if possible).
I have several drivers to add:
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The VGA_Text code ships with ICC software. I'll commit it to OBEX last.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
I got behind on my OBEX commits. Today I took time to post all the OBEX quality C source I have. This includes Tom's fswr code ... Tom, if you want me to pass control back to you please speak up.
Just wanted to point out that anyone can take a PASM driver and convert it to a C module by creating an ASCII-byte array. This is what I did for most of the work committed to OBEX. I hope I'm not the only C programmer that will have a desire to contribute to the community.
Thanks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Post Edited (jazzed) : 8/26/2008 6:11:21 PM GMT
Thanks for posting your serial driver!
Is the procedure to "take a PASM driver and convert it to a C module by creating an ASCII-byte array" documented anywhere?
I'll put this on the wiki later.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
I'm not a lawyer, but I understand the need for copyright is that you can't have licensing rules if you don't claim a copyright. You can say "This is mine, but I give it away", but you can't make any claim or set any requirements if you don't "own" it to begin with.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Hey Steve, that shouldn't be difficult to add as a function in our IDE. I mean converting what od/cur/sed is doing to C/C++
Please help me test the included Windows console application.
It is·a C based·application that extracts the DAT section from a spin binary and creates an ASCII-byte (long actually) array for use in a driver. The "entry org 0" should be the first code in the DAT section for this to work. The app decodes the spin bytes so you don't have to do it.
I've tried this on a few projects and am quite happy with it so far. I'll send the source to Richard after more test results. Here are some output examples.
TIA
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.com
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again
BTW: I type as I'm thinking, so please don't take any offence at my writing style