Assembly options in GCC
Rayman
Posts: 14,665
Are the different assembly options explained somewhere?
I'd like to know what my options are...
Here's what I think the options are:
1. Use spin2cpp to generate a data array that you can do a cognew on.
2. Use inline assembly
3. Include a .S file with native assembly
4. Write GAS code
I think I really only have a handle on the first one...
Are there others?
Is there a guide of some sort to the others?
Which one of these would you use to write a driver to run in it's own cog?
I have a feeling that 2..4 may generate LMM type code and not driver-like cog code...
I'd like to know what my options are...
Here's what I think the options are:
1. Use spin2cpp to generate a data array that you can do a cognew on.
2. Use inline assembly
3. Include a .S file with native assembly
4. Write GAS code
I think I really only have a handle on the first one...
Are there others?
Is there a guide of some sort to the others?
Which one of these would you use to write a driver to run in it's own cog?
I have a feeling that 2..4 may generate LMM type code and not driver-like cog code...
Comments
Maybe there are two different types of assembly output: regular cog PASM and LMM style GAS.
The regular cog PASM is what you do in Spin to make a driver that runs in a cog.
In GCC, you need to compile that PASM code with spin2cpp (BST or Roy's spin compiler) and then include it as a data array that you would then
invoke with cognew or coginit in your GCC code.
The LMM style GAS generates the same kind of assembly code that the GCC compiler does.
This approach just lets you generate it directly.
The code can either be "inline" in your c code or in a seperate .S file.
You can write in either GAS or PASM syntax.
Is this closer?
Yes. That's the best way to look at it. Sorry we haven't made it clearer.
To me GAS is just a GCC support thing and PASM is for COG drivers.
GAS does allow sharing variables better than PASM though.
SimpleIDE will take any .spin file having a PASM driver and make a link-able COG binary.
You can see the commands in the build output if you need to know how.
I've planned to add support for spin2cpp, but everything else keeps getting in the way.
And, I think that PropGCC brings a paradigm shift to how code is written for the Propeller. In the Spin world, you wrote cog assembly drivers for the speed. For some drivers, such as I2C, whenever you weren't using them they sat idle. And when you were using them, the "calling" cog waited for the result. So, at any one time you only used one cog of execution.
These are good candidates for switching to inline assembly, and skipping the whole cog driver model.