Nice tips here.
Thank you Rob and Vasile.

Cheers,
FS

On Sunday, August 21, 2022 at 4:57:45 PM UTC+1 vasile wrote:

> I think sometimes whichever you will use procedure or function will not be 
> fast enough. One bad example is too long if...end if procedures containing 
> stuff you are not using it. The common answer you'll get is that compiler 
> will delete unused stuff, which is correct unless it' s about defined 
> registers. So when you have time constrains, already defined procedures 
> that you get from the libraries have to be modified and simplified on your 
> own need. This is totally against the jallib policy :) but is the only way 
> which works. One good way is to check frequently the code length when major 
> revisions occure. A simple pass of a variable from one procedure to other 
> or from a function to a procedure may substantially increase the code 
> length. Too structured source code in which you call a procedure from 
> another procedure and from another one is increasing the used stack. 
> Sometimes repeating a portion of code is much better than calling it within 
> a procedure. And so on,  things you will discover by yourself...
>
> On Sun 21 Aug 2022, 6:04 PM Rob CJ <[email protected] wrote:
>
>> Hi Filipe,
>>
>> About 1). I am not sure, you should have a look at the assembly code. If 
>> you would replace a function by a procedure then you should have at least 
>> one parameter of the type 'out'. There is a way to speed up a function or 
>> procedure by declaring it 'inline'. If you do that the procedure or 
>> function is not called but the code is copied into the program where it is 
>> used. This increases the code size of your program but saves you a call to 
>> the procedure or function.
>>
>> And if you use interrupts there is an option 'fast' to speed it up but I 
>> never used it and you need to take some precautions if you use that.
>>
>> Kind regards,
>>
>> Rob
>>
>> ------------------------------
>> *Van:* [email protected] <[email protected]> namens flyway38 
>> <[email protected]>
>> *Verzonden:* zondag 21 augustus 2022 13:46
>> *Aan:* jallib <[email protected]>
>> *Onderwerp:* Re: [jallib] Procedures vs Functions 
>>  
>> Hello Kiste,
>>
>> Thank you for your input.
>>
>> Cheers,
>> FS
>>
>> On Sunday, August 21, 2022 at 12:03:37 PM UTC+1 Kiste wrote:
>>
>> Hi Filipe,
>>
>> I can tell you für 2): No. At compile time, the variable name is replaced 
>> by a fixed memory address. There's no difference if the name is declared 
>> inside a procedure/function or in the main program. There is, however, a 
>> little space ("access RAM") which contains a bit "faster" variables. So, it 
>> can make a little difference if a variable is declared earlier or later in 
>> a program.
>>
>> 8-bit PIC controllers are a bit special, as in a sense they don't have 
>> RAM at all, they merely have up to several thousand processor registers. 
>> Accessing (simple, not array) variables is therefore very fast compared to 
>> other processor architectures. 
>>
>> Greets,
>> Kiste
>>
>> Am Sonntag, 21. August 2022, 12:49:39 MESZ hat flyway38 <
>> [email protected]> Folgendes geschrieben: 
>>
>>
>> Hi all,
>>
>> Always had this doubt about efficiency in choosing Procedure or Function 
>> for structuring my code. I know how to use them by experience in coding JAL 
>> for many years.
>> Another doubt is declaring VARs inside Procedures or Functions will make 
>> them slower or not..., so here goes the questions;
>>
>> 1) - Which is the fastest/ efficient at runtime (Procedure or Function) ?
>> 2) - Declaring VARs inside Procs/Funcs will make them slower ?
>>
>> Thank you very much
>>
>> Kind regards,
>> Filipe Santos
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "jallib" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected].
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jallib/049c5097-750d-4cf7-845a-a89720963961n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jallib/049c5097-750d-4cf7-845a-a89720963961n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "jallib" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected].
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jallib/365d7bab-9091-4ac5-b55f-265f5cd23104n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jallib/365d7bab-9091-4ac5-b55f-265f5cd23104n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "jallib" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected].
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jallib/GVXP195MB1637DBE0E8F8E73A20BA5E98E66E9%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM
>>  
>> <https://groups.google.com/d/msgid/jallib/GVXP195MB1637DBE0E8F8E73A20BA5E98E66E9%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jallib/20e10c28-b231-4063-a3e7-351688293f23n%40googlegroups.com.

Reply via email to