s0 s1, l0, l1 question

[phjvh 0]

Hi,Can you expect a much better performance using a lot of s0,s1 etc and l0,l1 etc?Isn't there a risk using them in a big gauge with a lot of functions.When do you get conflicts?EXample(Var1) s0(Var2) s1l1 l0 > ..something(Var1) s0(Var2) s1l1 l0 > ..somethingetc.or(Var1) s0(Var2) s1l1 l0 > ..something(Var1) s2(Var2) s3l2 l3 > ..somethingThanks for comments and advices,Jan"Beatus ille qui procul negotiis..."

[pve 0]

Hi Jan I use them lots don't see any speed problems and conflicts. I find they are easy to understand and a neater solution. Tom explained in a recent post on the conflict problem. I have hundreds in the FMC gauge no problems. Example neat Vref code for 737-800 (A:Total weight, pounds) 1000 / s0 l0 100 <= l0 91 >= && if{ 0 } l0 110 <= l0 101 >= && if{ 1 } l0 120 <= l0 111 >= && if{ 2 } l0 130 <= l0 121 >= && if{ 3 } l0 140 <= l0 131 >= && if{ 4 } l0 150 <= l0 141 >= && if{ 5 } l0 160 <= l0 151 >= && if{ 6 } l0 170 <= l0 161 >= && if{ 7 } l0 180 <= l0 171 >= && if{ 8 }l0 190 <= l0 181 >= && if{ 9 } (>L:VrefCalc,number) Toms solution for LSK key page jumping (L:FMC_Page,enum) 7 == (L:FMC_PLN_Sub,enum) 1 == & if{ (@c:FacilityICAO) (>@c:FlightPlanNewWaypointICAO) 0 (>@g:enteringInput) } (L:FMC_Page,enum) 7 == (L:FMC_PLN_Sub,enum) 1 == & if{ 7 s0 1 s1 } (L:FMC_Page,enum) 5 == (L:FMC_PLN_Sub,enum) 0 == & if{ 3 s0 0 s1 } (L:FMC_Page,enum) 4 == (L:FMC_PLN_Sub,enum) 0 == & if{ 4 s0 1 s1 } (L:FMC_Page,enum) 4 == (L:FMC_PLN_Sub,enum) 1 == & if{ 4 s0 0 s1 } (L:FMC_Page,enum) 3 == (L:FMC_PLN_Sub,enum) 0 == & if{ 3 s0 1 s1 } (L:FMC_Page,enum) 3 == (L:FMC_PLN_Sub,enum) 1 == & if{ 3 s0 0 s1 } (L:FMC_Page,enum) 3 == (L:FMC_PLN_Sub,enum) 1 == & if{ 3 s0 2 s1 } (L:FMC_Page,enum) 3 == (L:FMC_PLN_Sub,enum) 2 == & if{ 3 s0 2 s1 } (L:FMC_Page,enum) 2 == (L:FMC_PLN_Sub,enum) 2 == & if{ 5 s0 0 s1 } (L:FMC_Page,enum) 2 == (L:FMC_PLN_Sub,enum) 0 == & if{ 5 s0 0 s1 } (L:FMC_Page,enum) 1 == (L:FMC_PLN_Sub,enum) 1 == & if{ 5 s0 0 s1 } (L:FMC_Page,enum) 1 == (L:FMC_PLN_Sub,enum) 0 == & if{ 1 s0 1 s1 } (L:FMC_Page,enum) 0 == (L:FMC_PLN_Sub,enum) 0 == & if{ 2 s0 4 s1 } (L:FMC_Page,enum) 8 == (L:FMC_PLN_Sub,enum) 0 == & if{ 9 s0 0 s1 } (L:FMC_Page,enum) 9 == (L:FMC_PLN_Sub,enum) 0 == & if{ 9 s0 0 s1 } (L:FMC_Page,enum) 9 == (L:FMC_PLN_Sub,enum) 0 == & if{ @PROCButton } l0 (>L:FMC_Page,enum) l1 (>L:FMC_PLN_Sub,enum)

[phjvh 0]

Thanks,I can understand that, using them myself about the same way.The question remains wether where and how you can use s0 etc. in one gauge.Can you use s0 in a new element after using it already in another element, so each element has its own s0--s50?btw. is this working code, new for me:Your codeYour codeJan"Beatus ille qui procul negotiis..."

[taguilo 33]

Jan,>Can you use s0 in a new element after using it already inanother element, so each element has its own s0--s50?Registers 0-49 "s/l" are shared by and the entire set of structures in a gauge. It means that you can save a value to a register (s0) in one element and restore it in another (l0), which also implies that the register is overwritten each time is saved (s0).For example 15 s0 15 stored to Register 0 l0 s1 23 s0 15 stored to Register 1 and 23 stored to Register 0One important thing to highlight is that saving with "s" does NOT remove the value from the stack, which has to be done using "sp". Saving with "s" is useful when the value will be used inmediately in the stack, for example (LVar) s0 15 >= . Now. when the saved value will be retrieved further, it is better to save with "sp" as to keep the stack balanced, with no "hidden" data.For Example (LVar) 1 == if{ 15 sp0 }(LVar) 2 == if{ 20 sp0 }l0 (>Lvar)Tom

[phjvh 0]

Tom,So when you use:...(L:Var0) s0 (L:Var1) sp1 (L:Var2) s2(L:Var3) sp3...(L:Var49) s49...You can use l0...l49 in the upcoming 's and 's?etc>(I'm recoding the huge "system" gauges to get better FPS)Jan"Beatus ille qui procul negotiis..."

[javfn 0]

Hello!I just wanted to comment I use the option you write in your first example Jan in your first post and so far I have not had any problems or comflicts whith the register. This way you do not have to worry if you have exceed the max number of storage allowed. I do not know if using the storage as you do in the second example may limit somehow the number of those storaged values to 48 in the whole gauge instead of just limit to an element.Javier

[pve 0]

Jan Yes both are working code. Full code for Vref is For PFD Vref speed bug set and FMC approach page text (A:Total weight, pounds) 1000 / s0 l0 100 <= l0 91 >= && if{ 0 } l0 110 <= l0 101 >= && if{ 1 } l0 120 <= l0 111 >= && if{ 2 } l0 130 <= l0 121 >= && if{ 3 } l0 140 <= l0 131 >= && if{ 4 } l0 150 <= l0 141 >= && if{ 5 } l0 160 <= l0 151 >= && if{ 6 } l0 170 <= l0 161 >= && if{ 7 } l0 180 <= l0 171 >= && if{ 8 }l0 190 <= l0 181 >= && if{ 9 } (>L:VrefCalc,number) (L:VrefFlapSelect,enum) 1 == if{ 174 169 164 159 154 148 142 135 129 122 10 (L:VrefCalc,number) case (>L:PFDvref,number) } (L:VrefFlapSelect,enum) 2 == if{ 165 160 156 151 146 141 135 129 123 116 10 (L:VrefCalc,number) case (>L:PFDvref,number) } (L:VrefFlapSelect,enum) 3 == if{ 157 153 148 144 139 133 128 122 116 109 10 (L:VrefCalc,number) case (>L:PFDvref,number) }

[taguilo 33]

Jan,>You can use l0...l49 in the upcoming 's and 's?For the set of yes, but for is a different story.In a gauge only one can be processed per cycle, so registers' visibilty is limited to the stack's space used inside that structure. Rememeber that registers, being a component of the stack, are reset to 0 on each gauge's cycle. Tom

[taguilo 33]

Hi,""I do not know if using the storage as you do in the second example may limit somehow the number of those storaged values to 48 in the whole gauge instead of just limit to an element.""There's only 50 registers that can be assigned a value in a gauge. Think of them as if they were variables, you can assign and retrieve values almost the same way as you would do when using Vars with the same name (which of course "are" the same vars :-))Tom

[phjvh 0]

Tom,I understand.So using the registers only simplifies coding, or is there still a gain in speed?Jan"Beatus ille qui procul negotiis..."

[taguilo 33]

Jan,I think both are true. It is obvious that typing less is what every programmer wish to do when dealing with large code. In this case, speed gain seems logic as well, because registers have to share with the stack a common memory area, whereas variables may be allocated in reserved zones that are far away (in memory space terms) from the calling pointers. Tom

[javfn 0]

Hi!So if I reach the s49 limit and I want to keep on using the register I only have to use s0 for the next value I want to storage or it might cause some inconsistencies whit the l0 in the previous elements, unless XML looks for the inmidiatly previous s0 and ignores the other ones?Javier

[taguilo 33]

Javier,You may store a value to a given register as may times as you wish, the stored value will always be the last one. Examples:1-Using same registers in only one element 45 sp0 l0 sp25 32 sp0 l0 (>LVar1) l25(>LVar2)LVar1=32 and LVar2=45 1-Using same registers in two-more elements 45 sp0 l0 sp25 32 sp0 l0 (>LVar1) l25(>LVar2)l0 (>LVar3) 64 sp25 l25 (>LVar4)LVar1=32 and LVar2=45 LVar3=32 and LVar4=64 Except when dealing with complex comparisons' code, it would be rare that you'd have to store a value into each one of the 50 registers, normally only two or three are used at the same time.Tom

[javfn 0]

I understand now I can use only 50 times the register does not matter if I use s0, s0, s0... or s0, s1, s2,... and that the retrived value in l0 is the previous s0 in a single or multiple element.Thank you TomJavier