GCC usage?
davidsaunders
Posts: 1,559
Ok I give up, I do not want to fight a new to me language, and I know C very well so:
I have a few questions on the usage of C in GCC on the Propeller:
Where do I get the version of GCC to target the Propeller (using Linux ARMv6 on RPi, and Win32 on x86).
How do you compile COG code for multiple COGS?
In gcc what are the macros for COGINIT, the timer stuff, and the name assignment of the control registers?
How is HUB RAM accessed with code compiled -mcog?
What are the limits of mixing COG and LMM code in a single binary blob?
How do you avoid using the C stack in COG only code (for local variables and functions calls)?
Is there anything that compiles to be larger than would be expected with the Propeller target?
What else do I need to know before I translate my SPIN and PropBASIC code to C?
Am I correct in assuming that the Propeller implementation of GCC correctly supports K&R style function definitions and declarations like other implementations of GCC?
I have a few questions on the usage of C in GCC on the Propeller:
Where do I get the version of GCC to target the Propeller (using Linux ARMv6 on RPi, and Win32 on x86).
How do you compile COG code for multiple COGS?
In gcc what are the macros for COGINIT, the timer stuff, and the name assignment of the control registers?
How is HUB RAM accessed with code compiled -mcog?
What are the limits of mixing COG and LMM code in a single binary blob?
How do you avoid using the C stack in COG only code (for local variables and functions calls)?
Is there anything that compiles to be larger than would be expected with the Propeller target?
What else do I need to know before I translate my SPIN and PropBASIC code to C?
Am I correct in assuming that the Propeller implementation of GCC correctly supports K&R style function definitions and declarations like other implementations of GCC?
Comments
Did you see the example in the other thread, where David ? ported the PropBASIC frequency Counter to GCC in two modes, showing the stack effects ?
PropBASIC came in smaller, and it seems the main item restricting GCC, is that GCC is based on a 16 register code model.- and it's not clear if you can even force important variables to reserve one of those registers.
I have SimpleIDE, which includes prop-gcc, for the Raspbery Pi here: https://dl.dropboxusercontent.com/u/81267937/SimpleIDE-0-9-47.x86_64.debian-linux.tar.bz2 That's a year old now and I'm sure others have created packages for the Pi since.
A good way to see how to do what you want with COG code is to look in the demos that care in the propgcc source code:
https://github.com/parallaxinc/propgcc/tree/master/demos
For example https://github.com/parallaxinc/propgcc/tree/master/demos/full_duplex_serial_ht is a Full Duplex Serial I made that shows how to start in COG code and access HUB variables from it.
If you mean K&R style function definitions like:
int foo(a, p) int a; char *p; { return 0; }Don't do that. There is no reason to use that obsolete style and will only confuse people.You can get a RaspberryPi build of PropGCC from SwimDude0614 has setup a build server that automatically builds new versions of PropGCC for various platforms including the RaspberryPi whenever anything changes in the propeller-gcc project on github. Just log in as "guest" and select the "PropGCC" project in the tab on the upper left. If you click on the "Artifacts" tab for the gcc4 build you should find a tarball containing the results of the build.
Here is the URL to the build server: http://david.zemon.name:8111/login.html
I'll try to answer some of your other questions later.
I do append one more question:
What are the data type sizes in the Propeller target?
I would expect:
int = long
long = 32-bits.
short = 16 bits.
char = 8bits.
float = 32 bit IEEE floating point.
double = 64 bit IEEE floating point.
Would that be correct? I do not so much care about float and double, they are not of much use to me in small applications(heck even in rendering 3D graphics on a desktop computer I use pure integer math [still the fastest way with out using an accelerator]).
For dealing with the floating point numbers in G-Code I will just convert it to integers representing increments of 1/16th of a mm, and use only integer math, As the minimum usable size is about 0.0625mm on my 3D printer (and 99% only go down to 0.1mm) I see no reason to do better than that. The two or three places where the fractional value of a calculation could make a difference for rounding error I will just use shifted values (ie crude fixed point where IValue = FValue << 8), will work well as the range of values is way less than 65536 in any direction (with the exception of number of steps, which is 8 for each usable minimum move [minimum move being 0.0625mm] so 32768 [max possible range] * 8 is 262144 total steps if you expand the print volume in at least one direction all the way to 512 meters [good luck]).
I think that the floating point code would be just wasted space in a bit of firmware running on a Propeller, there are very very few applications that truly require floating point, so it is a lot better to just use integer math in 99% of cases and not waste the space of the floating point code.
char x = -1; printf("%d\n", x);char x; short y; y = 5; x = -5; if (x < y) puts("unsigned char type\n"); else puts("signed char type");That would give a definite answer. At the moment I am still attempting to recover where I was in PropBASIC, so I have not yet installed Prop GCC, and can not check for myself.
I spent 60 seconds looking after I posted and gave up. "huge" doesn't quite cover it
Heater,
Really? I am used to that, or at least learned it like that.
What is the preferred way, using the same example, and why?
int foo(int a, char *p) { return 0; }Some people will write this asint foo( int a, // First parameter char *p // Second parameter ) { return 0; }This method allows for adding comments after each parameter to describe what they mean. I haven't seen the K&R style used in years.I hope you'll choose to follow the (new?) standard of doxygen comments though. This is the comment/documentation standard used by Parallax and numerous others
/** * @brief My Cool function * @param a First parameter * @param *p Second parameter * @return The constant zero */ int foo(int a, char *p) { return 0; }See propeller.h.
With pointers. All data is in hub by default.
You have to compile them separately and link them together.
Declare functions _NATIVE, and declare variables to be _COGMEM.
You can translate your Spin code to C (or C++) with spin2cpp.
Eric
That's definitely the best way to check! And as you've noticed, unsigned char is a lot more natural on the Propeller.
Well, the style, and the standard changed about twenty years ago or so. As people have shown above.
Is it better or worse?. Up to you to judge I guess.
OUCH, that is going to make using pointers to hub locations difficult.
Ok easy enough. OK, that seems easy enough. Do not like auto translation programs, besides the PropBASIC Version is further along than the SPIN version.
So if I understand correctly for a COG only function and not using the stack I would do something like:
_NATIVE MyFunc(a,b,c,d) char *c; { _COGMEM long tmp; /* Do something using int parameters a, b, and d, and string parameter c */ return 0; }There are many views on the subject.
If you are doing a lot of sparse jump tables, one alternative method would be to pack the Addr:Condition into hub memory, and code either a compact scanner, or a dual-lookup. - There is more HUB memory than COG memory
I prefer to see the type info close to the param name & for many params, multiple lines are easily used.
All depending how deep you want to get into it.....
The simpletools library (simpletools.h) is the goto place to get things done quickly and then other times, you may just need a Propeller function without all the extras, in which case just use propeller.h. To get your code size down to a minimum, check "Enable Pruning" under compiler options.
Additionally, there are times when the SimpleIDE help is helpful for a quick reference, and then there are times when it is nice to look at the library itself, and the various definitions. Most if not all of the functions declared in simpletools.h, are defined in seperate C files. Although the C file names do not always match the function names. In which case, I simply search the function name, in the SimpleIDE directory, and several files usually pop up. Select the file that most closely resembles the function name and you will find the function defintion that you are seeking.