If you give the COGC program a chunk of hub memory to use as a stack you don't have to worry about this. It is only necessary if you want to operate without a stack which is kind of unnatural for C anyway.
The general premise/expectation behind COG mode is to run COG local, with PASM like speed.
ie to use C as a high level assembler, and that will of course be somewhat constrained.
The link mentions 2 calls deep ?
What is the speed impact, when it does flip to use a Hub Stack ?
What CLK speeds does that use ?
I see 1MHz is widespread, and 3.4MHz is mentioned on some parts (eg Cypress FM24V10) not cheap, but could test 3.4MHz code.
1MHz parts can likely be over-clocked with tuning of pullup ressitors and code.
Not sure how fast it is trying to go. Jazzed wrote the EEPROM external memory driver. I've attached it here in case you want to look over the code. It doesn't use waitcnt for timing but instead uses djnz loops.
The general premise/expectation behind COG mode is to run COG local, with PASM like speed.
ie to use C as a high level assembler, and that will of course be somewhat constrained.
The link mentions 2 calls deep ?
What is the speed impact, when it does flip to use a Hub Stack ?
Remember, PropGCC is built on GCC. The compiler itself doesn't have any Propeller-specific constructs. It just has a Propeller code generator. The GCC compiler and C itself pretty much assume a stack so any code that can get away without one is exceptional. You *can* generate that sort of code by being a bit careful about how you use nested functions but it isn't really that straight forward. It would, of course, be possible to write an entirely new compiler that is tuned to generate code for the COG but that would be a much bigger effort than writing a code generator for GCC. We didn't do that. Even Catalina didn't do that.
What is the speed impact, when it does flip to use a Hub Stack ?
I just tried the fibo program in LMM and COG modes, and COG is about twice as fast as LMM. Of course, the fibo program uses recursive calling, so has to use the stack. I would expect a COG program to be at least 4 times faster than LMM as long as it doesn't use the stack or hub variables.
Remember, PropGCC is built on GCC. The compiler itself doesn't have any Propeller-specific constructs. It just has a Propeller code generator. The GCC compiler and C itself pretty much assume a stack so any code that can get away without one is exceptional. You *can* generate that sort of code by being a bit careful about how you use nested functions but it isn't really that straight forward. It would, of course, be possible to write an entirely new compiler that is tuned to generate code for the COG but that would be a much bigger effort than writing a code generator for GCC. We didn't do that. Even Catalina didn't do that.
It's impressive that PropGCC can generate COG-mode code.
Does the use of the HUB-stack appear in reports, or can it generate a warning ?
I just tried the fibo program in LMM and COG modes, and COG is about twice as fast as LMM. Of course, the fibo program uses recursive calling, so has to use the stack. I would expect a COG program to be at least 4 times faster than LMM as long as it doesn't use the stack or hub variables.
Sounds tolerable, what about the PropBASIC Frequency counter I linked in #27 as a more real-world example ?
Can that fit into COG mode, (sans-stacks?), and produce similar size / speed code ?
COG mode is thanks to Eric. I didn't think it could be done!
No, no warning or message of any kind is generated for stack usage. Stack usage is normal and expected in C.
Yes, I was meaning more as a user option ?
When they want COG mode and no stacks, (which is a special case) being able to avoid the need to manually double-check ASM listing, makes code a lot more maintainable.
Yes, I was meaning more as a user option ?
When they want COG mode and no stacks, (which is a special case) being able to avoid the need to manually double-check ASM listing, makes code a lot more maintainable.
I suppose it would be possible to do that by setting a flag in the code generator every time a stack operation is generated. That is, if it is possible at that level to distinguish between stack operations and other hub accesses. I'm not sure how useful it would be though. It would basically just tell you that a stack was needed but not why.
I suppose it would be possible to do that by setting a flag in the code generator every time a stack operation is generated. That is, if it is possible at that level to distinguish between stack operations and other hub accesses. I'm not sure how useful it would be though. It would basically just tell you that a stack was needed but not why.
Any warning is going to need additional investigation, it is the change in warning level that matters.
More useful than a simple flag, could be a stack counter, that INCs on every code generator stack case.
Reporting that would give a reference point for code maintainers ( & retains usefulness in >0 cases ).
WOW, a lot of good information here. I only expected a few quick answers.
So as I had thought, the use of stack space is still a concern (and a big one with only 496 longs of memory to work with). And much of the code I have seen uses some macros (if I remember correctly the header file is something like prop.h), macros that look a lot like spin commands, though have different parameters.
Just as a thought:
Why does not someone concentrate on a subset of C, and tuning it for COG execution. Perhaps start with something very simple like CUCU and add a little bit to take care of redundant code generated (to save space), and also have it generate native Propeller code directly. Then if you add a stack limit, most things should be fairly simple.
I think a simple subset C compiler like that would be a perfect fit on the Propeller. That is just my view.
Just as a thought:
Why does not someone concentrate on a subset of C, and tuning it for COG execution. Perhaps start with something very simple like CUCU and add a little bit to take care of redundant code generated (to save space), and also have it generate native Propeller code directly. Then if you add a stack limit, most things should be fairly simple.
I think a simple subset C compiler like that would be a perfect fit on the Propeller. That is just my view.
Things are pretty close to that already - the discussion is around how to make that 'simple subset C' a little more control-able and maintainable.
The Stack use is code-optional, but currently any use is a little hidden from users, hence my suggestion of some reporting (eg counter?)
I think a COG-Mode working example, that is real-world in nature (not fibc), would help demonstrate the issues here, and the PropBASIC freqCounter I linked seems a good reference.
That has some maths, some control flow, some string work, & comms, and gives a useful result, and seems to fit easily entirely in a COG ( ~152 Longs) with the small number-string in HUB..
It is small enough, that Prop GCC can be 2x the size and still fit to demonstrate COG-mode.
Here is a COG mode example that works and uses no stack space. In fact, this is the driver I was working on when I wrote those notes about using COG mode and eliminating stack usage.
Here is a COG mode example that works and uses no stack space. In fact, this is the driver I was working on when I wrote those notes about using COG mode and eliminating stack usage.
Can you include the ASM listing from that too ?
Is it easy to then make it use a stack, and include the .C/ASM for that one too ?
My question on BASIC still remains open. Compiled structured BASIC is a great language, and I see no reason not to use it. PropBASIC is great, though I would like to know of other options before I commit to a particular version of BASIC.
My question on BASIC still remains open. Compiled structured BASIC is a great language, and I see no reason not to use it. PropBASIC is great, though I would like to know of other options before I commit to a particular version of BASIC.
I don't know of any other Basic for the Propeller that produces PASM or LMM code. The others are either straight interpreters like FemtoBasic or byte code compilers like my xbasic or ebasic.
I don't know of any other Basic for the Propeller that produces PASM or LMM code. The others are either straight interpreters like FemtoBasic or byte code compilers like my xbasic or ebasic.
Thank you for that information. It is to bad we do not have more BASIC compilers for the Propeller.
Thank you for that information. It is to bad we do not have more BASIC compilers for the Propeller.
PropBASIC is being added to the Propeller IDE, (after being somewhat ignored) so that should boost the usage and support of PropBASIC.
Not sure why you'd want more than one ?
I'd rather see a PropPASCAL, before a second PropBASIC.
PropBASIC is being added to the Propeller IDE, (after being somewhat ignored) so that should boost the usage and support of PropBASIC.
Not sure why you'd want more than one ?
I'd rather see a PropPASCAL, before a second PropBASIC.
Just that having more than one helps push the use and development of what there is.
Sounds tolerable, what about the PropBASIC Frequency counter I linked in #27 as a more real-world example ?
Can that fit into COG mode, (sans-stacks?), and produce similar size / speed code ?
I converted the PropBASIC frequency counter program to C, and it's in the attached zip file. FreqCounter3.c doesn't use any of the special cog attributes, and it uses the stack. FreqCounter3cog.c uses the _NAKED, _NATIVE and _COGMEM attributes, and does not use the stack. It does use hub memory for strings and constants.
I use CTRB to generate a signal, which is measured by CTRA. You can change the frequency by changing the #define for FREQ. The signal pin number is defined by Signal.
I also generated the assembly output, which is included in the zip file.
In your code, I see you disabled the standard serial driver. I would assume you did this to reduce program overhead. If so, what kind of reduction in size is there?
Just that having more than one helps push the use and development of what there is.
Or, the opposite can occur as you can disperse the effort, and just confuse new users.
( rather like PropIDE and SimpleIDE is doing right now... )
That said, I can see a place for ByteCode BASIC and compiled Basic, tho ideally they are compatible...
Comments
The general premise/expectation behind COG mode is to run COG local, with PASM like speed.
ie to use C as a high level assembler, and that will of course be somewhat constrained.
The link mentions 2 calls deep ?
What is the speed impact, when it does flip to use a Hub Stack ?
eeprom_xmem.spin
It's impressive that PropGCC can generate COG-mode code.
Does the use of the HUB-stack appear in reports, or can it generate a warning ?
No, no warning or message of any kind is generated for stack usage. Stack usage is normal and expected in C.
Sounds tolerable, what about the PropBASIC Frequency counter I linked in #27 as a more real-world example ?
Can that fit into COG mode, (sans-stacks?), and produce similar size / speed code ?
Yes, I was meaning more as a user option ?
When they want COG mode and no stacks, (which is a special case) being able to avoid the need to manually double-check ASM listing, makes code a lot more maintainable.
More useful than a simple flag, could be a stack counter, that INCs on every code generator stack case.
Reporting that would give a reference point for code maintainers ( & retains usefulness in >0 cases ).
So as I had thought, the use of stack space is still a concern (and a big one with only 496 longs of memory to work with). And much of the code I have seen uses some macros (if I remember correctly the header file is something like prop.h), macros that look a lot like spin commands, though have different parameters.
Just as a thought:
Why does not someone concentrate on a subset of C, and tuning it for COG execution. Perhaps start with something very simple like CUCU and add a little bit to take care of redundant code generated (to save space), and also have it generate native Propeller code directly. Then if you add a stack limit, most things should be fairly simple.
I think a simple subset C compiler like that would be a perfect fit on the Propeller. That is just my view.
The Stack use is code-optional, but currently any use is a little hidden from users, hence my suggestion of some reporting (eg counter?)
I think a COG-Mode working example, that is real-world in nature (not fibc), would help demonstrate the issues here, and the PropBASIC freqCounter I linked seems a good reference.
That has some maths, some control flow, some string work, & comms, and gives a useful result, and seems to fit easily entirely in a COG ( ~152 Longs) with the small number-string in HUB..
It is small enough, that Prop GCC can be 2x the size and still fit to demonstrate COG-mode.
i2c_driver.c
Is it easy to then make it use a stack, and include the .C/ASM for that one too ?
Comments :
byte <<= 1;
if (INA & sda_mask) byte++;
should code smaller than
byte <<= 1;
byte |= (INA & sda_mask) ? 1 : 0;
and I notice using vars of byte, can give larger code than using the native prop size, as the compiler adds a masking step.
addit : The compiler knows about andn, so nicely does this (open drain)
but in other places, it seems to forget that, and instead uses another register to load the mask, then flips the bits and uses and, instead of andn ?!
My question on BASIC still remains open. Compiled structured BASIC is a great language, and I see no reason not to use it. PropBASIC is great, though I would like to know of other options before I commit to a particular version of BASIC.
Not sure why you'd want more than one ?
I'd rather see a PropPASCAL, before a second PropBASIC.
I use CTRB to generate a signal, which is measured by CTRA. You can change the frequency by changing the #define for FREQ. The signal pin number is defined by Signal.
I also generated the assembly output, which is included in the zip file.
In your code, I see you disabled the standard serial driver. I would assume you did this to reduce program overhead. If so, what kind of reduction in size is there?
( rather like PropIDE and SimpleIDE is doing right now... )
That said, I can see a place for ByteCode BASIC and compiled Basic, tho ideally they are compatible...