 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Idle curiosity about internal stack space
| Author | Message | ||||
CaptainBoing Guru  Joined: 07/09/2016 Location: United KingdomPosts: 1985 |
MM Mk2 44pin '170 Never had this error before; When MMBasic complains "expression is too complex" what are the causes here? I suspect it is stack space etc. in the shunting yard of the expression evaluator but could one of the MMBasic gurus please provide some insight on the limits? [532] Local Integer s,n,m,f Error: Expression is too complex That looks like I was right on the limit and grabbing another 256 bytes just pushed it over the edge. I found this post which seems to underpin the assumption where stack space had been increased (V5.2) to reduce the occasions of this error. I have a load of date manipulation functions that make things really easy but I got that error in the middle of a compare where I was reducing two strings to their Epoch/Unix times to compare them, So I was already heavily into the stack of the expression evaluator when it got hit again with a fairly complex function and then yet again with the same function all inside brackets, e.g. something like IsDST=Not(UnixTime(d$)<UnixTime(FindLastSunday(d$))) and MMbasic just went off into a corner and started rocking back and forwards in the foetal position, sucking its thumb, twiddling its hair and making strange mewing noises. My guilty secret here is  > ? mm.ver 5.0408 for operational reasons - it seemed (to me at any rate) to be the last rock solid version before a run of hiccups in 5.05xx that were fixed with a change that meant blowing out VAR SAVEd data when uploading new software. I am just curious. I have never had this before and I must confess I was kicking the arse off the poor little blighter, but it triggered an amount of work-around that made things a bit more complicated than I had hoped. Still, got there in the end, just not as tidy as it could have been. Sometimes I need to pinch myself and remember these are micro-controllers. Still blows me away what I can get this single chip to do. I look at completed projects that have a tiny board a '170 and a handful of resistors and think "is that it?"  |
||||
| zeitfest Guru Joined: 31/07/2019 Location: AustraliaPosts: 378 |
(Just from interest, I don't have knowledge of the source) Does the MMBasic expression evaluator use the shunting yard algorithm ? I thought the lexers, parsers etc mainly used for the Basic interpreters used a different method (?)  |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1985 |
Hey Z I don't know either, just a guess... I have written a couple of expression evaluators over the years and each one had a shunting yard to boil conventional infix, "algrebraic" expressions to reverse polish notation (computery stack-based maths). It was easy and very quick. If you get into the machine routines and the maths pack uses a stack to process either the top or top two numbers, bet your last penny it uses a shunting yard to get to that there from algebraic expressions. Watch someone prove me wrong now  Edited 2020-06-30 23:07 by CaptainBoing |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
This error basically says that the interpreter has overflowed its stack (this is the C stack). The way the expression evaluation algorithmic works is that it recursively calls itself and the most likely cause of a stack overflow is a very complex expression... therefor this error message when a stack overflow is detected. There is not much that can be done about this. The only fix is to increase the stack size which will reduce the amount of RAM available to a BASIC program and the last time that I did that it caused a huge outcry from some users who were using every byte of RAM. . No, it is a home grown algorithm which I have not seen documented anywhere. Geoff Geoff Graham - http://geoffg.net |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3655 |
If it's essentially as per the Duinomite, I'd say recursive descent. John |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1985 |
OK, thanks - good head knowledge. I had worked around it anyway (by splitting the expression into three bits) Not asking for a fix Geoff. I reckon it is fairly rare and easy enough to sort. Plus this is on 5.0408 and I wouldn't expect anyone to look after non-current software. cheers |
||||
| Bizzie Senior Member  Joined: 06/07/2014 Location: AustraliaPosts: 185 |
Hi all, Just came across "Error: Expression is too complex" in some fruits of the shed code:- If you load up UnixTime and associated dependencies. The regex function will generate this error in the MatchChar sub IF running on a GCmicroboard2b BUT runs fine on a 170! Solution is to break the offending line in two. eg j=Instr(r+1,regex$,Mid$(text$,s,1)) break it up to :- t$ = Mid$(text$,s,1) j=Instr(r+1,regex$,t$) and all's well. Rob White |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3655 |
Is that a typo for CGmicroboard2b? i.e. this board Does it have a different MMBasic version, probably older than the on on the 170? The stack was increased at some pint so maybe newer version would be a fix. John |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1985 |
you are in the same area I was when I found the same error. I mostly use 170s and had no problems - starting to think I dodged a bullet.  I did the same, broke a complex expression into bits with a variable. What I found interesting is that LOCALs are shoved on the stack too (example at the start of this thread) so that extra 256 bytes in t$ could be just as guilty. I suppose there is mileage in DIMing global variables as general workspace and using those where you can - of course this is asking for trouble with nesting... "here be dragons" warning seems appropriate. The regex might seem a lot of overkill for the IsDate & IsTime but is makes things supremely easy to read and program, but boy does it kick things. Dates are always a pain, I wish we could all standardise on yyyy-mm-dd then all comparisons between strings could use < and > etc. The inner geek in me would like Epoch/Unixtime... but i don't reckon the rest of the world would go for it. Do I win a bun for "Accidentally Complex Code Guaranteed to Run the Stack Dry"? Edited 2020-07-02 17:11 by CaptainBoing |
||||
| Bizzie Senior Member Joined: 06/07/2014 Location: AustraliaPosts: 185 |
They are both running 5.0408 (according to ? MM.VER) I was surprised that's why I posted. I wanted to use UnixTime to save on file/memory storage and to simplify sorting. Rob White |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1985 |
they are on different platforms so is it possible there will be slight differences in the compiled MMBasic firmware(?). that's my guess Edited 2020-07-02 19:29 by CaptainBoing |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2286 |
what?! that is a really bad way of doing it - please, someone tell me this is not so. local variables should be implemented something equivalent to the below: Sub mysub Dim myvar(1000) As integer ' [do some stuff in here] Erase myvar End Sub cheers, rob :-) |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8578 |
Its not so |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1985 |
really? why the error at a declaration I wonder? Shared memory (with the stack)? [532] Local Integer s,n,m,f Error: Expression is too complex Edited 2020-07-03 04:14 by CaptainBoing |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8578 |
parsing the command uses the stack as various C subroutines are called. You just happened to hit the stack limit on the variable declaration. All variables are created on a MMBasic specific heap created and managed by the MMbasic firmware and unrelated to the C heap which isn't used. #define RAMEND ((unsigned int)&_stack - (unsigned int)&_min_stack_size) void TestStackOverflow(void) { register unsigned int msp asm("sp"); if(msp < (unsigned int)RAMEND) error("Expression is too complex"); } |
||||
 Print this page |
