Tests / Demos 4 propgcc

Reinhard · 2011-11-07 06:03

Hi,
Currently I write several Tests/Demos using the propgcc.

I will public they soon.
Sadly I have the problem, how can a running cog determine his own cogid.

for example in Catalina we can write a statement like this : myID = _cogid();
I have no statement, similar this, found in the header files.

Or must I use an inline assembly ?
How is herefore the syntax ?

best regards,
Reinhard

David Betz · 2011-11-07 06:55

Reinhard wrote: »

Hi,
Currently I write several Tests/Demos using the propgcc.

I will public they soon.
Sadly I have the problem, how can a running cog determine his own cogid.

for example in Catalina we can write a statement like this : myID = _cogid();
I have no statement, similar this, found in the header files.

Or must I use an inline assembly ?
How is herefore the syntax ?

best regards,
Reinhard

The cogid() macro was inadvertently left out of the last release of PropGCC. It will be in propeller.h in the next release. In the meantime, the definition is this;

#define cogid()                  __builtin_propeller_cogid()

Of course you could also use __builtin_propeller_cogid() without requiring any header file.

Reinhard · 2011-11-07 07:23

David Betz wrote: »
The cogid() macro was inadvertently left out of the last release of PropGCC. It will be in propeller.h in the next release. In the meantime, the definition is this;
#define cogid()                  __builtin_propeller_cogid()
Of course you could also use __builtin_propeller_cogid() without requiring any header file.

Thank you David

Ariba · 2011-11-07 10:33

Reinhard wrote: »

...
Or must I use an inline assembly ?
How is herefore the syntax ?
....

The syntax for inline assembly I would also like to know. Perhaps David knows more?

As for demos, I have just posted a C version for the Connect4-game for the QuickStart board here:
Quickstart-Smile-Games-Contest

Andy

David Betz · 2011-11-07 11:04

Ariba wrote: »

The syntax for inline assembly I would also like to know. Perhaps David knows more?

As for demos, I have just posted a C version for the Connect4-game for the QuickStart board here:
Quickstart-Smile-Games-Contest

Andy

I'm afraid I'm probably not a good resource for GCC inline assembly. I have to look up the syntax every time I do it and have only written a handful of inline assembly code. Eric can probably give you a better answer. Sorry to pass the buck but I want you to get the most accurate information possible and Eric is probably a better source.

That said, the assembly itself is very much like PASM. It's just the constructs around the assembly code that say how to interface to the surrounding C code that is a bit cryptic.

jazzed · 2011-11-07 11:34

Ariba wrote: »

The syntax for inline assembly I would also like to know. Perhaps David knows more?

As for demos, I have just posted a C version for the Connect4-game for the QuickStart board here:
Quickstart-Smile-Games-Contest

Andy

Hi Andy. Nice work! Pretty code too with lots of good comments.

We plan to make a separate demos distribution soon.
I would like permission to include your files. Can you add an MIT license?

I wanted to add a note to show an alternative build method without a makefile.
With the latest test distribution, we can compile like this:

propeller-elf-gcc -Os connect4.c -o connect4.elf

Thanks,
--Steve

Ariba · 2011-11-07 11:39

Thank you for the info, David

I know in C for the PICs inline assembly is surrounded by _asm and _endasm, perhaps this is the same here, I have to try...

BTW: You and the others of the GCC team have done a very good job, so far - Thanks!

Andy

Ariba · 2011-11-07 12:28

Jazzed

OK, I have added the MIT license, and for sure you have the permission to add it to a demo distribution

Andy

ersmith · 2011-11-07 12:45

Ariba wrote: »

The syntax for inline assembly I would also like to know. Perhaps David knows more?

The best source of information is the gcc manual. I think we provide a pdf of this in the binary distribution (if not, we definitely should!). It's also available online in various places, such as: http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html (although the online ones will be missing the propeller specific info).

The short version is that you put a block of code in an __asm__ statement. Here's a kind of nonsense made up one to set y = x+1:

__asm__( "mov %0, %1\n add %0, #1"
   : "=rC"(y)  /* outputs */
   : "rCi"(x)   /* inputs */
   :              /* clobbered registers (none in this example) */
);

In the assembly pattern %0 stands for the first argument, %1 for the next, and so on. After the string giving the assembly language come the arguments; outputs, inputs, and clobbered registers. Each one can be a C expression, but before it must come a string specifying how it is passed in to the assembly. "rC" means the argument can be in a register ("r") or a COG memory location ("C"). The "C" form is, obviously, propeller specific; "r" is a general GCC pattern. Similarly "rCi" means it can be in a register, COG memory location, or may be an immediate value ("i"). The "=" in front of the "=rC"(y) says that the variable is set by the assembly expression.

If the assembly modifies or relies on hardware registers or memory then you may want to say volatile __asm__ to let the compiler know that it can't move it around or optimize it away.

As you can see the inline assembly is very powerful and allows detailed interface to the C code. It also shouldn't be necessary very often :-). I don't see any inline assembly in our library, for example. Pretty much all of the Propeller instructions can be generated either directly in C or via the propeller specific builtin functions like __builtin_propeller_waitcnt, __builtin_propeller_cogid, and so on.

Eric

Reinhard · 2011-11-07 13:49

Hi,
now I can present a small demo, written with propgcc 0_1_7.

The ambition of the demo is to controll the cogregister from each cog via serial interface.
So I can use the propeller as Counter,NCO,HF Generator(PLL) or simple Portinterface for
set/reset a dedicated IO Pin.
However, the comfortable GUI is not the focus from this demo.
Here I use the built in terminal of propeller-load.

The attached zip contens:

the sourcecode ... CogView.c
the Binary ... CogView.elf
a Makefile
a Make for Windows ... mk.bat (Note: set the Port for your PC/Propeller connection!)
a screenshot from a session ... usage.txt

At time, I have only the access for OUTA and DIRA tested, but I guess other register, like FRQA etc.,
have also to work.

best regards,
Reinhard

jazzed · 2011-11-07 14:19

Hi Reinhard,

Nice demo using multiple cogs. If you don't mind and can add MIT license for your code, we can include it in our demos.

Thanks.
--Steve

Reinhard · 2011-11-07 14:39

jazzed wrote: »

Hi Reinhard,

Nice demo using multiple cogs. If you don't mind and can add MIT license for your code, we can include it in our demos.

Thanks.
--Steve

OK, I have added the MIT license, and for sure you have the permission to add it to a demo distribution

Ariba · 2011-11-07 15:53

ersmith wrote: »
The best source of information is the gcc manual. I think we provide a pdf of this in the binary distribution (if not, we definitely should!). It's also available online in various places, such as: http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html (although the online ones will be missing the propeller specific info).

The short version is that you put a block of code in an __asm__ statement. Here's a kind of nonsense made up one to set y = x+1:
__asm__( "mov %0, %1\n add %0, #1"
   : "=rC"(y)  /* outputs */
   : "rCi"(x)   /* inputs */
   :              /* clobbered registers (none in this example) */
);
In the assembly pattern %0 stands for the first argument, %1 for the next, and so on. After the string giving the assembly language come the arguments; outputs, inputs, and clobbered registers. Each one can be a C expression, but before it must come a string specifying how it is passed in to the assembly. "rC" means the argument can be in a register ("r") or a COG memory location ("C"). The "C" form is, obviously, propeller specific; "r" is a general GCC pattern. Similarly "rCi" means it can be in a register, COG memory location, or may be an immediate value ("i"). The "=" in front of the "=rC"(y) says that the variable is set by the assembly expression.

If the assembly modifies or relies on hardware registers or memory then you may want to say volatile __asm__ to let the compiler know that it can't move it around or optimize it away.

As you can see the inline assembly is very powerful and allows detailed interface to the C code. It also shouldn't be necessary very often :-). I don't see any inline assembly in our library, for example. Pretty much all of the Propeller instructions can be generated either directly in C or via the propeller specific builtin functions like __builtin_propeller_waitcnt, __builtin_propeller_cogid, and so on.

Eric

Eric, thank you for the detailed description.
It looks a bit complicated at first glance, but I'm sure there are reasons for that complexity (interfacing with C code).
I just added this to a existing C file:
__asm__(" mov r7,#99 ");
and found the instruction in the assembly listing generated from the elf output file, so it works (but makes not much sense).
I also think inline assembly will not be used often, but it's good to know that it is possible and how.

Andy

Tests / Demos 4 propgcc

Comments