Convert to int64 note

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Convert to int64 note

Zaaphod
I've been trying to get my programs to compile without any warnings or notes, but I keep getting this one:

promill.pas(2137,42) Hint: Converting the operands to "Int64" before doing the subtract could prevent overflow errors.

I get it a lot, but this is the line the above example is from:

Last_GS:=G_End-(Max_Program_To_Display-1);

Can someone please explain that this hint means and how I would convert the operands to "Int64" as recommended?

James

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Convert to int64 note

Santiago A.
El 14/07/2017 a las 1:13, [hidden email] escribió:

> I've been trying to get my programs to compile without any warnings or notes, but I keep getting this one:
>
> promill.pas(2137,42) Hint: Converting the operands to "Int64" before doing the subtract could prevent overflow errors.
>
> I get it a lot, but this is the line the above example is from:
>
> Last_GS:=G_End-(Max_Program_To_Display-1);
>
> Can someone please explain that this hint means and how I would convert the operands to "Int64" as recommended?
>
> James
>
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

What's the type of each variable?

--
Saludos

Santiago A.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Convert to int64 note

Zaaphod
>What's the type of each variable?

Last_GS,G_End : longint;
Max_Program_to_Display : Word;

-----Original Message-----
From: fpc-pascal [mailto:[hidden email]] On Behalf Of Santiago A.
Sent: Friday, July 14, 2017 7:00 AM
To: [hidden email]
Subject: Re: [fpc-pascal] Convert to int64 note

El 14/07/2017 a las 1:13, [hidden email] escribió:

> I've been trying to get my programs to compile without any warnings or notes, but I keep getting this one:
>
> promill.pas(2137,42) Hint: Converting the operands to "Int64" before doing the subtract could prevent overflow errors.
>
> I get it a lot, but this is the line the above example is from:
>
> Last_GS:=G_End-(Max_Program_To_Display-1);
>
> Can someone please explain that this hint means and how I would convert the operands to "Int64" as recommended?
>
> James
>
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

What's the type of each variable?

--
Saludos

Santiago A.

_______________________________________________
fpc-pascal maillist  -  [hidden email] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Convert to int64 note

Michael Van Canneyt


On Fri, 14 Jul 2017, [hidden email] wrote:

>> What's the type of each variable?
>
> Last_GS,G_End : longint;
> Max_Program_to_Display : Word;
>
> -----Original Message-----
> From: fpc-pascal [mailto:[hidden email]] On Behalf Of Santiago A.
> Sent: Friday, July 14, 2017 7:00 AM
> To: [hidden email]
> Subject: Re: [fpc-pascal] Convert to int64 note
>
> El 14/07/2017 a las 1:13, [hidden email] escribió:
>> I've been trying to get my programs to compile without any warnings or notes, but I keep getting this one:
>>
>> promill.pas(2137,42) Hint: Converting the operands to "Int64" before doing the subtract could prevent overflow errors.
>>
>> I get it a lot, but this is the line the above example is from:
>>
>> Last_GS:=G_End-(Max_Program_To_Display-1);
>>
>> Can someone please explain that this hint means and how I would convert the operands to "Int64" as recommended?
It means that if for example
   G_End = -Maxint
then Last_GS can get a value that falls outside the valid integer range.

If you declare Last_GS as int64, you should not get the warning.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Convert to int64 note

Mattias Gaertner
In reply to this post by Zaaphod
On Fri, 14 Jul 2017 08:04:51 -0400
<[hidden email]> wrote:

> >What's the type of each variable?  
>
> Last_GS,G_End : longint;
> Max_Program_to_Display : Word;

Last_GS:=G_End-(longint(Max_Program_To_Display)-1);

Mattias
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Convert to int64 note

Zaaphod
In reply to this post by Santiago A.
>If you declare Last_GS as int64, you should not get the warning.

I declared both Last_GS and G_End as int64, leaving Max_Program_to_Display as a word and still get the warning.  If I also make Max_Program_to_Display int64, then I do not get the warning.   I believe it's due to the -1. If Max_Program_To_Display was a 0 then subtracting 1 from it would be out of range from a word for that portion of the formula, even though the end result would fit in Last_GS

>Last_GS:=G_End-(longint(Max_Program_To_Display)-1);
This aso fixes the warning if I leave all my variables alone.  If I understand this correctly in this case longint() is a function that returns a longint variable to be used in the calculation, so when it does the -1 it's ok it that part of the formula ends up being negative.

So now my question is, which is the best method to use?  My thinking with declaring Max_Program_To_Display as a word was that this value has no meaning if it is negative, and actually a word is way too generous for this value, a byte would be overkill.  Last_GS and G_End could be very large, so that's the reason for the longint.  So I can either declare Max_Program_to_Dispalay as a longint and use more memory for that variable, or use a longint() function in my formula and that calculation would have one more function to process, or turn off the warnings but then there could be a condition where I could get an out of range result during the computation even though the final result would have been in range.. but this happens sometimes so I would rather fix it to never happen.

I'm from the old school way of thinking that programs should use as little memory and be as efficient as possible, after all some of my computers only had 4K of RAM,  but I'm wondering if that has become irrelevant with modern computers.
Does it really matter anymore how much memory I use up with variables?   Maybe I should just declare all whole number variables as int64 and all decimal numbers as Double and not worry about how much memory I use, after all I have gigabytes of ram to use now, not 64K blocks of ram that each turbo pascal unit had to fit into.  Even if I had 1 million int64 variables and 1 million double variables, that would only end up being 18MB of memory, not much of dent in 1GB... and most pcs have more than 1GB of RAM.  

I suppose it would take longer to process all formulas with int64 and double variables compared to using smaller variables, but then again processor speed is also very fast now, so should I even be bothered with it?

I'm curious what the general method is now?  

James


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Convert to int64 note

Mattias Gaertner
On Fri, 14 Jul 2017 11:19:53 -0400
<[hidden email]> wrote:

>[...]
> >Last_GS:=G_End-(longint(Max_Program_To_Display)-1);  
> This aso fixes the warning if I leave all my variables alone.  If I understand this correctly in this case longint() is a function that returns a longint variable to be used in the calculation, so when it does the -1 it's ok it that part of the formula ends up being negative.

longint is type. longint() is a typecast.

Mattias
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Convert to int64 note

Reimar Grabowski
On Fri, 14 Jul 2017 17:58:16 +0200
Mattias Gaertner <[hidden email]> wrote:

> longint is type. longint() is a typecast.
Thx, now you ruined my amazingly funny response which would have delighted the list members for the whole weekend perhaps even up to the middle of next week.
It was so hilarious that every random three words of it would have been an instant viral meme but you couldn't wait for 5 minutes longer to put your plain, boring facts in everyones face. Thanks, again.

And then you don't even answer the question of the TC.
Now I have to do it for you:

Dear James,

use typecasting, it's good.

R.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Convert to int64 note

Ewald-2
In reply to this post by Zaaphod
On 14/07/17 17:19, [hidden email] wrote:

>> If you declare Last_GS as int64, you should not get the warning.
>
> I declared both Last_GS and G_End as int64, leaving Max_Program_to_Display as a word and still get the warning.  If I also make Max_Program_to_Display int64, then I do not get the warning.   I believe it's due to the -1. If Max_Program_To_Display was a 0 then subtracting 1 from it would be out of range from a word for that portion of the formula, even though the end result would fit in Last_GS
>
>> Last_GS:=G_End-(longint(Max_Program_To_Display)-1);
> This aso fixes the warning if I leave all my variables alone.  If I understand this correctly in this case longint() is a function that returns a longint variable to be used in the calculation, so when it does the -1 it's ok it that part of the formula ends up being negative.
>
> So now my question is, which is the best method to use?  My thinking with declaring Max_Program_To_Display as a word was that this value has no meaning if it is negative, and actually a word is way too generous for this value, a byte would be overkill.  Last_GS and G_End could be very large, so that's the reason for the longint.  So I can either declare Max_Program_to_Dispalay as a longint and use more memory for that variable, or use a longint() function in my formula and that calculation would have one more function to process, or turn off the warnings but then there could be a condition where I could get an out of range result during the computation even though the final result would have been in range.. but this happens sometimes so I would rather fix it to never happen.
>
> I'm from the old school way of thinking that programs should use as little memory and be as efficient as possible, after all some of my computers only had 4K of RAM,  but I'm wondering if that has become irrelevant with modern computers.
> Does it really matter anymore how much memory I use up with variables?   Maybe I should just declare all whole number variables as int64 and all decimal numbers as Double and not worry about how much memory I use, after all I have gigabytes of ram to use now, not 64K blocks of ram that each turbo pascal unit had to fit into.  Even if I had 1 million int64 variables and 1 million double variables, that would only end up being 18MB of memory, not much of dent in 1GB... and most pcs have more than 1GB of RAM.  
>
> I suppose it would take longer to process all formulas with int64 and double variables compared to using smaller variables, but then again processor speed is also very fast now, so should I even be bothered with it?
>
> I'm curious what the general method is now?

There are a couple of things to take into account here:
        - Your target processor and it's native integer size
        - Aligned access is *much* faster than unaligned access
        - If you really need to work with words of different sizes,
          typecasting is your friend :-)

Now, since aligned access is so much better, it would be a very sane choice of the compiler to align all local variables on the stack (I don't know if FPC does this, but I strongly suspect it does). This means that a single byte will occupy the same size as an integer. So you actually win no space on the stack. Same goes for records and arrays, unless they are declared as 'packed' with a {$PACKRECORDS 1} directive next to it (the 1 is the alignment). Those arrays and records can be very handy to read/write data from/to a file, socket, stream, shared memory, pipe, ... But are a performance killer.

So on modern processors, you probably win nothing at all regarding size.

Then, the speed of the calculations. Of course there is the fact that you simply have less bits to process, which would suggest a speed improvement. However a processor could simply use 64-bit arithmetic and simply mask the output for you. I don't know what the case is there.

Mostly I use the smaller types for a variety of very basic range limitations: when I declare something as a byte, its value can never be larger than 255, which can come in handy at times. Think about a lookuptable for a CRC calculation unit for example.

--
Ewald
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Convert to int64 note

Santiago A.
In reply to this post by Zaaphod
El 14/07/2017 a las 17:19, [hidden email] escribió:
If you declare Last_GS as int64, you should not get the warning.
I declared both Last_GS and G_End as int64, leaving Max_Program_to_Display as a word and still get the warning.  If I also make Max_Program_to_Display int64, then I do not get the warning.   I believe it's due to the -1. If Max_Program_To_Display was a 0 then subtracting 1 from it would be out of range from a word for that portion of the formula, even though the end result would fit in Last_GS
Using your way, (Max_Program_To_Display-1) is calculated first. Since the variable is type word, it would make word calculation, with word range. In such case, if Max_Program_To_Display is zero, you would get an underflow (and with no bounds checks, you could get $FFFF that would be even worse).


      
Last_GS:=G_End-(longint(Max_Program_To_Display)-1);
This aso fixes the warning if I leave all my variables alone.  If I understand this correctly in this case longint() is a function that returns a longint variable to be used in the calculation, so when it does the -1 it's ok it that part of the formula ends up being negative.

So now my question is, which is the best method to use?  My thinking with declaring Max_Program_To_Display as a word was that this value has no meaning if it is negative, and actually a word is way too generous for this value, a byte would be overkill.

If negative has no sense, I would declare it word, or byte and cast it to a signed integer if you need for internal calculations as have been said. Declaring it word, you have made the compiler to give you heads-up about a potential problem, then you can decide to check before if Max_Program_To_Display is zero or double check there is nothing wrong there. Other way it would have passed unnoticed and could bite you latter in unexpected ways and points of execution, making you hunt for a long time a weir bug.

I wouldn't worry too much about declaring it word or byte. I think that because of performance, the compiler may align in a word (compiler gurus will tell better).
In fact, I would forget about internal format and declare a new type in the range of valid values i.e
type
 TMaxprogram=0..53;
and let the compiler decide what internal format to use.

In the conversion I would use "integer" instead of "longint"
Last_GS:=G_End-(integer(Max_Program_To_Display)-1);
"Integer" is the optimal integer format for that architecture, probably "longint", but I would use "integer" anyway.

My two cents.
-- 
Saludos

Santiago A.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Loading...