<!--[if (gte mso 9)|(IE)]><style type="text/css">.main-style-58ecfe89283f0eb0956a { font-family: sans-serif; font-size: 11pt; /* inherit */ }</style><![endif]--><div style="/* inherit */" class="main-style-58ecfe89283f0eb0956a"><div>James, <br /></div><div><br /></div><div>not every body is using a GHz machine. I am , for example, programming a 80186 in an embedded system with very limited speed an RAM. <br /></div><div>But I understand thats not a general argument. <br /></div><div><br /></div><div>But look at MISRA C. Its a big set of rules for "real" save C programming, more or less now the standard in the automobile industry. <br /></div><div>Also here are strict rules for counters in for loops. <br /></div><div>See: <br /></div><div><a href="https://www.misra.org.uk/forum/viewtopic.php?t=272" rel="noopener noreferrer" target="_blank">https://www.misra.org.uk/forum/viewtopic.php?t=272</a>​</div><div><br /></div><div>So what they are doing is writing Pascal programs in C... ;-) And they need huge and expensive and complex  tools to check the C code for <br /></div><div>MISRA compatibility!</div><div>So we should NOT give up the safety of Pascal for the sloppiness of C! <br /></div><br><div class="front-signature fa-uid_e37f2a53e1f980507ba4197d9407543f"><div>Kind Regards</div><div><br /></div><div>Markus</div></div></div><img src="https://app.frontapp.com/api/1/noauth/companies/schleibinger_geraete_gmbh/seen/msg_3t3yn9e/han_9pzu6a/a2c200f4.gif" style="width: 1px; height: 1px"><br><blockquote type="cite" class="front-blockquote">On September 9, 2019, 7:19 PM GMT+2 <a href="mailto:james@productionautomation.net" target="_blank" rel="noopener noreferrer">james@productionautomation.net</a> wrote:<br /><br /><div id="fae_3t3yn9ede55it">Yes, today such limitations do seem too restrictive, I wonder if the reasons for the restrictions have become obsolete.  You would have to have a really slow computer with very limited resources to optimize loops to the point of reducing functionality like this, and the tendency with modern pc's is to have a larger library of much more powerful and more flexible tools, even if they are more complex and take more memory and resources.  For example Case statements used to only work with characters or integers,  but the modern version now also works with strings, very much added functionality for sure, but also would use more resources.... but we would all rather have the capability because even a raspberry pi is blazing fast and has ram to burn compared to our old 8086s  It seems silly to me that I can't so what I used to do with Turbo Pascal for DOS where I was limited to programs of a few hundred K, due to optimizations that just can't make much of a difference at all on modern computers.   I am happy that FPC has TP compatibility mode though!   It's just I get to a point where I eventually can't cross units since I can't have a circular unit reference.  So I have to choose for any given unit.. do I want my old for loops and change the control variables, or do I want cool new case statements... etc..  it would be nice to have {$Mode everything_the_way_I_want_it}<br /><br />Since the compiler knows I was trying to change the variable inside the for loop, could it not just compile in not quite as efficient code (TP MODE for loop) when it detects this, and use the more efficient optimized code when it detects that it is able to use it?<br /><br />James<br /><br />-----Original Message-----<br />From: fpc-pascal <<a rel="noopener noreferrer" href="mailto:fpc-pascal-bounces@lists.freepascal.org" target="_blank">fpc-pascal-bounces@lists.freepascal.org</a>> On Behalf Of Bernd Oppolzer<br />Sent: Monday, September 9, 2019 10:46 AM<br />To: FPC-Pascal users discussions <<a rel="noopener noreferrer" href="mailto:fpc-pascal@lists.freepascal.org" target="_blank">fpc-pascal@lists.freepascal.org</a>><br />Subject: Re: [fpc-pascal] Illegal counter variable?<br /><br />Am 09.09.2019 um 16:11 schrieb James Richters:<blockquote type="cite" class="front-blockquote"><br />> I just don't see why having the limitation, there is no technical <br />> reason that the for loop couldn't change that I can see.. especially since it works in TP mode.<br /><br />The original reason why some Pascal implementations had this limitation:<br /><br />for performance or optimization reasons, the loop control variable was transferred to a register at the beginning of the loop, and changing the variable (at its storage location) inside the loop simply had no effect, because the variable was not fetched from there again during loop execution.<br />Worse: maybe, to make read accesses to the loop control variable valid inside the loop, they are prepared by storing the control register value into the loop control variable, thus turning changes to the loop control variable useless.<br /><br />Forbidding (write) accesses to the loop control variable allows for many aggressive optimization strategies around loops.<br /><br />Maybe today such limitations seem too restrictive.<br /><br />Kind regards<br /><br />Bernd<br /><br />_______________________________________________<br />fpc-pascal maillist  -  <a rel="noopener noreferrer" href="mailto:fpc-pascal@lists.freepascal.org" target="_blank">fpc-pascal@lists.freepascal.org</a> <a rel="noopener noreferrer" href="https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal" target="_blank">https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal</a><br />_______________________________________________<br />fpc-pascal maillist  -  <a rel="noopener noreferrer" href="mailto:fpc-pascal@lists.freepascal.org" target="_blank">fpc-pascal@lists.freepascal.org</a><br /><a rel="noopener noreferrer" href="https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal" target="_blank">https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal</a><br /></blockquote></div></blockquote><img src="https://u8034135.ct.sendgrid.net/wf/open?upn=liJK2x9lrhmoNbCyBS0MpxjIPwWmvAfUM4RgDSjskX7nFcRXYX2fLyQoEx3O9ue95UqCxFIA9QZrrCKGcQQC2kBTdrWioJPlJmwrNkQhl2GGaOk8T5Rox8pMbkXXxQTYwMOFOwG6Nwc-2FqGstqwEqVu-2FkjQ7crJJID7Kg9M6VrsHMdp8q-2BbQ6rSm-2BBAQNBoHNWTZo1LtKB8Af7AugcK00F361uTfQNaJmbk1-2FO19FVP6guD7f67GOhYRjsFX8a1RBw1Xaa6X9bkkHUJ-2FMTQ9TyofOvWWSJoY9QwwkNnxkzkXYdpLG4A9ci-2FAJls9YFFpGNNNG7JSIW6R-2FTNyEhvctNGznKUX8RHZvXaBYiZ3R05enbMiyxfruFDL0I-2B0ZYzecWJsPF08SZQ4M-2BI6BygLNBzP6wEvLfy7gdOuE8OitEVsB-2BCy8-2Bxw6yE9Bmjjj882a" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/>