PropGCC fcache and CMM

SRLM

I'm having a curious problem with the fcache. I've run into this before, but for one reason or another wasn't able to make a post for it.

First, why do I assume the problem is the fcache? Because with -mfcache -mcmm the program does not work. With the other combinations (no-fcache/CMM, LMM/fcache) it works fine. The problematic code is not timing dependent or use any I/O.

Thy symptom of this problem is a loop that works if you have sufficient "stuff" inside of it (such as a printf or two), but fails when you don't have sufficient stuff. The fail mode is execution freezing. Other instances of this issue have resulted in gibberish on the pins.

I've tried several times to isolate this problem in a small program to no avail. So, I'm posting the full program here. It's the serial driver from libpropeller. The particular bit that fails is this:

libpropeller/printstream/printstream.h:

while(formatString[stringIndex] >= '0' and formatString[stringIndex] <= '9'){
    paddingBuffer[paddingIndex++] = formatString[stringIndex];
//  printf("+%c+", formatString[stringIndex]);				
    stringIndex++;
}

This loop works (ie, no freezing) with -mno-fcache, but freezes with -mfcache in CMM.

If I uncomment the printf the loop works (completes), even in cmm fcache mode.

I assume that my code is not the issue because of the change in behavior with the fcache switch. I'd expect that the code would operate identically with and without the switch.

I've attached a minimum working example. To run, make sure the symbolic links are good (or copy the files over). Then cd to the libpropeller/printstream/ folder. Run "make", then "./run_unit" (or load the .elf).

jazzed

Hi SRLM,

Does this happen with release_1_0 branch or the default?

I never call other functions from an fcache function.
The release_1_0 compiler doesn't support it AFAIK.

SRLM

jazzed wrote: »

Hi SRLM,

Does this happen with release_1_0 branch or the default?

I've been dancing around this issue for a while (6 months or more?). My current testing is with a recent build (propellergcc-alpha_v1_9_0_2193).

I never call other functions from an fcache function.
The release_1_0 compiler doesn't support it AFAIK.

Well, it's not calling anything (except optionally printf, which fixes the problem). And in any case if it's fcache'd then the compiler is doing it automatically: it's not an fcache marked function.

jazzed

SRLM wrote: »

I've been dancing around this issue for a while (6 months or more?). My current testing is with a recent build (propellergcc-alpha_v1_9_0_2193).

Well, it's not calling anything (except optionally printf, which fixes the problem). And in any case if it's fcache'd then the compiler is doing it automatically: it's not an fcache marked function.

Please file a bug report pointing to this thread so we can scheduled a fix.

SRLM

jazzed wrote: »

Please file a bug report pointing to this thread so we can scheduled a fix.

Ok, I've created issue #63: https://code.google.com/p/propgcc/issues/detail?id=63

ersmith

The code example seems to work OK with the current "default" branch (well, it doesn't freeze with -mcmm and -mfcache), but I was able to reproduce the failure with release_1_0. The code is using different registers with the two compiler versions, and some things are subtly re-arranged. I don't see anything "obviously" wrong with the release_1_0 version, but there probably is a bug there, either in the compiler itself (most likely) or in the assembler's translation from CMM instructions to PASM instructions for FCACHE. I think we did fix a few bugs in the assembler, come to think of it, so it could be that. I'll try to track it down, but in the meantime you may have better luck with the current Mercurial code, if you can build that.

Eric

ersmith

OK, I was wrong about the default branch -- the example doesn't actually work with it (I must have screwed up the makefile somehow). I did find the root cause: the assembler is outputting an incorrect relocation for the "leasp" pseudo-op when it has to translate it to a non-compressed form (e.g. inside an FCACHE). We should have a fix for this soon.

Thanks for the bug report!

SRLM

Ooops. I started building PropGCC last night, then forgot to check when it was done.

Anyway, you're right: I tried it with the most recent version of the code (propellergcc-alpha_v1_9_0_2245) and it still froze. I'm glad you found a fix!

On an unrelated note, the upgrade from 2193 to 2245 caused an increase in code size for two programs that I measured (same configuration both times):

| A      | B
-------+--------+------------
Before | 12464  | 22736 bytes
After  | 12944  | 23032 bytes

So, a minimum of 300 bytes in this test.

SRLM

Solved: It looks like version 2248 fixes the issue.

As an interesting note, fcache increases the code size from 12944 to 13668 bytes, and changed the execution time from 0.285s to 0.279s. The code is some unit tests of a serial function.