Menu
▾
▴
[sdcc-devel] [ sdcc-Support Requests-1724080 ] Strange variable named "bits" in BIT_BANK area in 2.7.0 RC1
|
From: SourceForge.net <no...@so...> - 2007-05-24 08:26:02
|
Support Requests item #1724080, was opened at 2007-05-23 12:49 Message generated for change (Comment added) made by patryks You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=200599&aid=1724080&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Open Priority: 5 Private: No Submitted By: Patryk (patryks) Assigned to: Maarten Brock (maartenbrock) Summary: Strange variable named "bits" in BIT_BANK area in 2.7.0 RC1 Initial Comment: I tested SDCC 2.7.0 RC1 against my current project developed with 2.6.0. There is strange variable named "bits" introduced in overlayable bit register bank (.area BIT_BANK), in C module other than main, containing one ISR and several variables and functions. "bits" is never used in code (neither my C nor generated asm), but in ISR (it calls other functions from that module) it is pushed and poped. There are some bit variables defined in this module (and in other modules too), but they are placed by compiler/linker in one byte at 0x20. Replacing bit by unsigned char didn't help. Just checked (in other modules with ISRs): "bits" is defined and pushed/poped when ISR calls other function. What is purpous of "bits"? If it is for local bit variables that could be overlayed, why compiler didn't place there one of my such vars (allocated globally as in 2.6.0)? Rest of my bit vars are global or static. So effectively I lost 2 bytes of RAM (one for "bits" and one for stack pushed in ISR) and gain nothing. Fragment of *.rst file: 34 ;---------------------- 35 ; overlayable bit register bank 36 ;---------------------- 37 .area BIT_BANK (REL,OVR,DATA) 0021 38 bits: 0021 39 .ds 1 8000 40 b0 = bits[0] 8100 41 b1 = bits[1] 8200 42 b2 = bits[2] 8300 43 b3 = bits[3] 8400 44 b4 = bits[4] 8500 45 b5 = bits[5] 8600 46 b6 = bits[6] 8700 47 b7 = bits[7] 48 ;--------------- ---------------------------------------------------------------------- >Comment By: Patryk (patryks) Date: 2007-05-24 10:25 Message: Logged In: YES user_id=1788180 Originator: YES "Double submit can happen if you click BACK and FORTH which will retransmit the form." That may be the cause as I remember. "And in older versions of the compiler it was impossible to use local bit vars in reentrant functions." Impossible means that such code didn't work, but compiler wasn't able to detect it, right? To clarify: such a function pushes "bits" to stack before calling self or other function? I can't check it myself: I'm trying to write such function, but compiler uses globals and even slocs, but not "bits", no matter how crazy the code looks like, example below. volatile bit z; static void Foo(bit x, bit y) { x |= z; if (y) { Foo(1, x); z &= x; Foo(y, 0); } return; } ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2007-05-23 21:05 Message: Logged In: YES user_id=888171 Originator: NO Double submit can happen if you click BACK and FORTH which will retransmit the form. Yes reentrant functions can have at most 8 bit vars 'alive' at any given time. More of them will result in use of normal registers wiht inefficient conversions. I wouldn't call it a cache though. And in older versions of the compiler it was impossible to use local bit vars in reentrant functions. I hope this resolves your question and the issue will be closed automatically unless you come back to it. You're also allowed to close it yourself. ---------------------------------------------------------------------- Comment By: Patryk (patryks) Date: 2007-05-23 16:08 Message: Logged In: YES user_id=1788180 Originator: YES Some error occurred - I didn't hit 'Submit Changes' button three times waiting 3 minutes after each :-) "If any function in any module uses reentrancy and local bit variables or parameters, they are stored in "bits". It's a group of 8 virtual bit registers." So only 8 parameters and/or local bits are allowed in such function? And such a function pushes "bits" to stack before calling self or other function? So "bits" is used as a cache to speed up bit operations? Such functions were non-reentrant in 2.6.0? #pragma exclude bits don't work - pitty :-( ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2007-05-23 14:08 Message: Logged In: YES user_id=888171 Originator: NO If any function in any module uses reentrancy and local bit variables or parameters, they are stored in "bits". It's a group of 8 virtual bit registers. If an ISR calls some function the compiler cannot determine if "bits" will be touched or not by it or its descendants. Thus it must save "bits" as it might be used by a reentrant function in another module the compiler knows nothing about. I agree that in your case you probably just lost some bytes. I have no good solution for you other than to Keep Isr's Short and Simple (KISS). If you remove the function call, you regain the bytes and also the stack space used for the call. ---------------------------------------------------------------------- Comment By: Patryk (patryks) Date: 2007-05-23 13:10 Message: Logged In: YES user_id=1788180 Originator: YES mcs51 is the target. ---------------------------------------------------------------------- Comment By: Patryk (patryks) Date: 2007-05-23 13:07 Message: Logged In: YES user_id=1788180 Originator: YES mcs51 is the target. ---------------------------------------------------------------------- Comment By: Patryk (patryks) Date: 2007-05-23 13:04 Message: Logged In: YES user_id=1788180 Originator: YES mcs51 is the target. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=200599&aid=1724080&group_id=599 |