unable to compile on XC8 since svn 248

[Brandon Smith]

SVN rev 248 changed how error handling was done in such a way that the
XC8 compiler's stupid recursion detection routine now refuses to compile
the code.

Any thoughts on what to do here?

I'm looking for non-terrible ways to tell the compiler to shut its face
and compile the code, but nothing good has come to mind yet.

Thanks,

--Brandon

[Robert Deliën]

> SVN rev 248 changed how error handling was done in such a way that the
> XC8 compiler's stupid recursion detection routine now refuses to compile
> the code.

You're too kind to point it out, but I'm not too proud to admit it: It's the stupid code, not the stupid compiler.

> Any thoughts on what to do here?

There is a recursion indeed, and that's not pretty, but the this recursion will never occur due to different argument values required for that.

> I'm looking for non-terrible ways to tell the compiler to shut its face
> and compile the code, but nothing good has come to mind yet.

Perhaps there's a pragma you can set to make the compiler build the code anyway?
The only other things I can think of is to either disable the offending function call, or to duplicated the function.

Cheers,

Robert.

[Brandon Smith]

On 2013-03-22 (Fri) at 07:26:49 +0000, Robert Deli?n wrote:
> > SVN rev 248 changed how error handling was done in such a way that the
> > XC8 compiler's stupid recursion detection routine now refuses to compile
> > the code.

> You're too kind to point it out, but I'm not too proud to admit it: It's the stupid code, not the stupid compiler.

:)

> The only other things I can think of is to either disable the offending function call, or to duplicated the function.

Most of the recursion can be cleared if we separate litterlanguage_pause
from litterlanguage_unpause. Unfortunately, not all of it.

The rest can be cleared if we change litterlanguage_event to be
litterlanguage_error (since it only does things on errors any way),
because that removes the call points that look like they could recurse.

We could always introduce a new function litterlanguage_success if, in
the future, there are actual actions to take in successful cases.

Thoughts?

Thanks!

--Brandon

[Brandon Smith]

On 2013-03-22 (Fri) at 10:08:01 -0700, Brandon Smith wrote:
> > The only other things I can think of is to either disable the offending function call, or to duplicated the function.
>
> Most of the recursion can be cleared if we separate litterlanguage_pause
> from litterlanguage_unpause. Unfortunately, not all of it.
>
> The rest can be cleared if we change litterlanguage_event to be
> litterlanguage_error (since it only does things on errors any way),
> because that removes the call points that look like they could recurse.
>
> We could always introduce a new function litterlanguage_success if, in
> the future, there are actual actions to take in successful cases.

Here's a patch doing those things...

Let me know what you think!

--Brandon

[Robert Deliën]

> Most of the recursion can be cleared if we separate litterlanguage_pause
> from litterlanguage_unpause. Unfortunately, not all of it.
>
> The rest can be cleared if we change litterlanguage_event to be
> litterlanguage_error (since it only does things on errors any way),
> because that removes the call points that look like they could recurse.

It's intended as an event mechanism, for both errors and generic events, such as a decreased cartridge level after dosing some detergent.

> We could always introduce a new function litterlanguage_success if, in
> the future, there are actual actions to take in successful cases.

Perhaps it could be split.

> Thoughts?

Not recently; I'm a bit absent because I'm completely swamped. I'm still reading all the messages though, but I don't always feel the need to pick up the work to solve it. That will change over time though…

[KuriKat]

Brandon,

The pause and unpause features are in a single function in order to dynamically "allocate" memory for the pause state and "free" it when resumed.  Otherwise, the variables declared there have to be global which means those memory locations will never be free for other use:
    static struct {
        unsigned bowl    : 2;
        unsigned arm     : 2;
        unsigned water   : 1;
        unsigned pump    : 1;
        unsigned dosage  : 1;
        unsigned dryer   : 1;
        unsigned long    wait;
        unsigned long    fill;
        unsigned long    drain;
        unsigned long    autodose;
        unsigned long    autoarm;
    } context;


I forget the exact amount, but depending on the chip you only have something like 368 bytes of memory, so we have to be extremely contentious of that constraint.

[Robert Deliën]

Again an answer, not preceded by a question; I'll have to check my filter...

The pause and unpause features are in a single function in order to dynamically "allocate" memory for the pause state and "free" it when resumed.  Otherwise, the variables declared there have to be global which means those memory locations will never be free for other use:
    static struct {
        unsigned bowl    : 2;
        unsigned arm     : 2;
        unsigned water   : 1;
        unsigned pump    : 1;
        unsigned dosage  : 1;
        unsigned dryer   : 1;
        unsigned long    wait;
        unsigned long    fill;
        unsigned long    drain;
        unsigned long    autodose;
        unsigned long    autoarm;
    } context;

No, they're global alright; Context is allocated statically, so it ends up in .bss, meaning that this memory is not available for anything else at any time. The reason why it's declared within the pause function is to limit its availability name space: This variable should not be used outside the pause function, so it's available only within that function name space.

I forget the exact amount, but depending on the chip you only have something like 368 bytes of memory, so we have to be extremely contentious of that constraint.

Yeah, pause is a rather expensive function when every byte counts. You could make it a compile time option though: HAS_PAUSE

[KuriKat]

Yes, you are right that is global.  I copied and pasted without noticing the "static".  So, breaking up this function should be easy.

 

We could make those vars local only (not static), and write (duplicate) the code to wait for a keypress before continuing in that same function.  That should get rid of the recursion issue AND make the vars non-global, saving memory.  Two birds with one stone.

[KuriKat]

Actually, we had discussed this before, but we could save the state to EEPROM in the pause function, and restore it in the unpause function.

 

That would allow us to:

• Break up pause/unpause, eliminating the recursion issue
• Free up global memory
• If needed, power off the CatGenie by removing the processing unit and/or unplugging it after pausing.  You could use this to clean the water sensor or get the scoop unstuck while the program is running.  The startup code can then look in the EEPROM to see if there was pause state saved and either go back into pause mode or just automatically restore the pause state (effectively unpause).

 

Thoughts?

[Robert Deliën]

Actually, we had discussed this before, but we could save the state to EEPROM in the pause function, and restore it in the unpause function.

Possibly; We've discussed lots of things, but I don't remember this one ;-). Anyway, I think it's a good idea.

That would allow us to:

• Break up pause/unpause, eliminating the recursion issue

Yes.

• Free up global memory

Somewhat.

• If needed, power off the CatGenie by removing the processing unit and/or unplugging it after pausing.  You could use this to clean the water sensor or get the scoop unstuck while the program is running.  The startup code can then look in the EEPROM to see if there was pause state saved and either go back into pause mode or just automatically restore the pause state (effectively unease).

For a pause/unpause to survive a power-cylcle, a little more needs to be saved: At least the ll-program counter and a flag indicating it was paused.

But I'm all for it!

[Ian Jeffrey]

Dear Robert and Brandon,

Has the compiler problem been solved?

I tried to compile using the latest Catgenius B04 SVN but I get errors. See below.  Brandon made a patch and I was wondering if you were going to incorporate this into the next revision or B05? And if you approve of the patch or what your thoughts were with the compile errors.  For now I just reverted to Rev 245 and I have no problems compiling any changes that I make in the romwashprogram.c file. Are there any major issues that I should be worried about using r245 instead of the current version?

Thanks for all your help.

ian

Error and warning messages below:

HI-TECH C Compiler for PIC10/12/16 MCUs (PRO Mode)  V9.82
Copyright (C) 2011 Microchip Technology Inc.
Licensed for evaluation purposes only.
This licence will expire on Sun, 22 Sep 2013.
Warning [1089] C:\Users\Ian\Desktop\Catgenius B04\software\catgenius\userinterface.c; 343. recursive function call to "_litterlanguage_event"
Warning [1089] C:\Users\Ian\Desktop\Catgenius B04\software\catgenius\litterlanguage.c; 361. recursive function call to "_litterlanguage_stop"
Warning [1089] C:\Users\Ian\Desktop\Catgenius B04\software\catgenius\litterlanguage.c; 267. recursive function call to "_litterlanguage_pause"
Warning [1090] C:\Users\Ian\Desktop\Catgenius B04\software\catgenius\..\common\catgenie120.c; 450. variable "_pct_deployed" is not used
Warning [1090] C:\Users\Ian\Desktop\Catgenius B04\software\catgenius\litterlanguage.c; 575. variable "_pc" is not used
Warning [1090] C:\Users\Ian\Desktop\Catgenius B04\software\catgenius\userinterface.c; 74. variable "_error_nr" is not used
Warning [1393] C:\Users\Ian\Desktop\Catgenius B04\software\catgenius\catgenius.c; 124. possible hardware stack overflow detected, estimated stack depth: 9
Error   [1347] ; 0. can't find 0x102 words (0x102 withtotal) for psect "text3288" in class "CODE" (largest unused contiguous range 0xF8)
Error   [1347] ; 0. can't find 0x97 words (0x97 withtotal) for psect "text3223" in class "CODE" (largest unused contiguous range 0x87)
Error   [1347] ; 0. can't find 0x79 words (0x79 withtotal) for psect "text3247" in class "CODE" (largest unused contiguous range 0x47)
Error   [1347] ; 0. can't find 0x6F words (0x6f withtotal) for psect "text3211" in class "CODE" (largest unused contiguous range 0x47)
Error   [1347] ; 0. can't find 0x5F words (0x5f withtotal) for psect "text3224" in class "CODE" (largest unused contiguous range 0x47)
Error   [1347] ; 0. can't find 0x57 words (0x57 withtotal) for psect "text3206" in class "CODE" (largest unused contiguous range 0x47)
Error   [1347] ; 0. can't find 0x54 words (0x54 withtotal) for psect "cinit" in class "CODE" (largest unused contiguous range 0x47)
Error   [1347] ; 0. can't find 0x4C words (0x4c withtotal) for psect "text3228" in class "CODE" (largest unused contiguous range 0x47)
Error   [1347] ; 0. can't find 0x36 words (0x36 withtotal) for psect "idataBANK2" in class "CODE" (largest unused contiguous range 0x20)
Error   [1347] ; 0. can't find 0x2F words (0x2f withtotal) for psect "idataBANK3" in class "CODE" (largest unused contiguous range 0x20)
Error   [1347] ; 0. can't find 0x2C words (0x2c withtotal) for psect "text3202" in class "CODE" (largest unused contiguous range 0x20)
Error   [1347] ; 0. can't find 0x24 words (0x24 withtotal) for psect "idataBANK1" in class "CODE" (largest unused contiguous range 0x20)
Error   [1347] ; 0. can't find 0xA words (0xa withtotal) for psect "text3287" in class "CODE" (largest unused contiguous range 0x7)
Error   [1347] ; 0. can't find 0x8 words (0x8 withtotal) for psect "clrtext" in class "CODE" (largest unused contiguous range 0x7)
Error   [1347] ; 0. can't find 0x8 words (0x8 withtotal) for psect "text3284" in class "CODE" (largest unused contiguous range 0x7)

********** Build failed! **********

[Ian Jeffrey]

Well I just applied Brandon's patch but I still get errors when I try to compile. So I guess I will have to stick with r245.

On Thursday, March 21, 2013 10:36:46 PM UTC-4, Brandon Smith wrote:

[C Anthony Risinger]

errors you say?

--

C Anthony

--
You received this message because you are subscribed to the Google Groups "CatGenius" group.
To unsubscribe from this group and stop receiving emails from it, send an email to catgenius+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Robert Deliën]

Yeah, probably the 'possible' recursive call. Didn't fix it, the patch just changes too much.

 

---

From: catg...@googlegroups.com [catg...@googlegroups.com] on behalf of C Anthony Risinger [ant...@xtfx.me]
Sent: 07 August 2013 16:19
To: catg...@googlegroups.com
Subject: Re: [catgenius] Re: unable to compile on XC8 since svn 248

[KuriKat]

The warnings about recursion and unused variables are just that: Warnings. They will not prevent compilation.

The actual errors (one is enough) deal with being out of memory. The XC8 compiler does not optimize memory well, hence the issue. Instead, use the HI-TECH C compiler. You can "eval" the software for free for 45 days.