Stack overflows in Oshon

[Mosaic]

hi, how to manage when oshon uses so many calls that it overflows the stack?

I am getting overflows cause of my interrupt.
But oshon makes embedded calls in its own code for its own purposes, so i can't predict the stack depth. Nor can i force it to sequence the code and NOT use unnecessary calls.

Unfortunately...this is happening after I am 95% done as the code is more complex now.

Any suggestions would be helpful.

 

[Ian Rogers]

This is the main reason I bought my C compiler.... Unfortunately Vladimir at Oshonsoft abides by the assembly stack which is 8 levels in the pic14's and 16 levels in the pic16's

When I say 14's and 16's I am referring to the instruction sizes.. Pic16Fxxx and pic18Fxxx respectively..

 

[Mosaic]

Well I am trying to flatten out my code...abandoning structured procedures and functions and doing a series of gotos. That helps
Now I have a new prob.

Oshon is sticking my interrupt routine across the $0800 page boundary and that is screwing up things....my embedded asm code is getting lost when branching.

How can I force Oshon to start my int routine at a page boundary to avoid this page switching?

 

[Mosaic]

Well.. after much effort I can't seem to solve these overflows.

After 2 months of oshon coding I have to abandon it and go back to asm.

Terribly frustrating. Oshon can't handle complex coding on stack limited PICS. It uses way too many calls its commands. Does foolish things like place the interrupt code in some obscure part of prg memory so that a call is wasted just getting to the interrupt.

 

[Ian Rogers]

Try great cow basic http://gcbasic.sourceforge.net/

What chip are you using? Are you able to bump up to the pic18?

 

[Mosaic]

Great cow huh...is it smarter?

I am using a 16f886.

 

[Mosaic]

Do u think I can swap in a 16F1936, it seems to be a drop in upgrade with 16 stack levels etc?
FYI, I am programming in oshon but assembling in ASM and simulating in ISIS.
OSHON does not support the 16f1936, but ISIS does. So I am hoping to create 16F886 ASm to run on the 16F1936, but the ISIS sim will now have a 16 level stack to use.

Edit:

Well I had a go at it, too many config registers are different. Sux

 

[Ian Rogers]

Why don't you give C a try? You can do scads more...

 

[Mosaic]

Only know basic C++.

For now...it's back to good 'ol asm.

I did about 200 lines of asm last nite.
Proceeded to run into page switching via PCLATH for a lookup table feeding the LCD text.
Sure, it slowed me for a few min. BUT is was joy to have the control to fix it.

Conerting to asm isn't as bad as it looked, as all the OSHON code used structured coding...procs and functions. Asm offers a means to optimize flag bit handling as well by grouping them into nybbles and bytes I can quickly xorlw them and do parallel processing of flags rather than using multiple ors & ands & ifs in Oshon.

I will buy a C compiler, maybe this year. Which do u reccomend?

 

[Ian Rogers]

It doesn't add up in my brain... Asm is still limited to the same stack..... In C we have a software stack of ( well a page size to begin with )..

Oshon soft uses the same boundaries... It looks like Great Cow is the same...( I downloaded it last night and had a play )..

I use XC8 now... Previously I had C18 and I had to use the free Hi-Tech compiler.. Now its all covered in one.

 

[Mosaic]

Ok.

In ASM u can do more with an 8 level stack. Relatively easy to flatten code if u must, u just give up some structured calls and either embed macros or use goto to hop around.

 

[Ian Rogers]

Ok.

In ASM u can do more with an 8 level stack. Relatively easy to flatten code if u must, u just give up some structured calls and either embed macros or use goto to hop around.

Like I said... The same applies to Oshonsoft.... You just need to take care..

 

[languer]

use goto to hop around

That's what you use the PROC and FUNC on Oshonsoft for.

 

[Mosaic]

That's what you use the PROC and FUNC on Oshonsoft for.

Actually, those are the cause of the problem. If u read the asm Oshon makes....structured elements cause more calls/returns. Therefore as u go along and u start to do math with functions inside of Procs inside of perhaps a For Next loop etc... u run out of stack.

The solution is either to move to a PIC with more stack, do flat unstructured BASIC with many gotos or , as I did...move to asm to do the job. ASM allows complete control over stack issues in a predictable fashion. BASIC doesn't let u see what's really going on.

 

[ot1]

Some 16Fs have an 8 level stack, others have a 16 level stack, I believe all 18Fs have at least a 31 level stack. Oshonsoft Basic is a High Level Language and as such a programmer using should expect internal calls when using built in Functions of the language, which do chew up stack space. For example the LCD calls use up to 5 levels of stack, not much much leftover for other nested calls when using a uP that only has an 8 level stack. Proper programming can alleviate too many nested calls to prevent blowouts(stack overflows), but sometimes there is no way around it in BASIC and one must use a uP with a deeper stack. This is no fault of Oshonsoft, he attempts to make BASIC easier to use by providing Functions that allow the programmer more rapid development. In Oshonsoft, one can easily observe current stack usage in the SFRs, to prevent overflows, when stepping through the program.