Re: [fpc-pascal] Convert to int64 note

[Santiago A.]

El 14/07/2017 a las 17:19, ja...@productionautomation.net 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 $ 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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Convert to int64 note

[Ewald]

On 14/07/17 17:19, ja...@productionautomation.net 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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Convert to int64 note

[Reimar Grabowski]

On Fri, 14 Jul 2017 17:58:16 +0200
Mattias Gaertner  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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Convert to int64 note

[Mattias Gaertner]

On Fri, 14 Jul 2017 11:19:53 -0400
 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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Convert to int64 note

[james]

>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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Convert to int64 note

[Mattias Gaertner]

On Fri, 14 Jul 2017 08:04:51 -0400
 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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Convert to int64 note

[james]

>What's the type of each variable?

Last_GS,G_End : longint;
Max_Program_to_Display : Word;

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

El 14/07/2017 a las 1:13, ja...@productionautomation.net 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  -  fpc-pascal@lists.freepascal.org 
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

What's the type of each variable?

--
Saludos

Santiago A.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org 
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Convert to int64 note

[Santiago A.]

El 14/07/2017 a las 1:13, ja...@productionautomation.net 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  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

What's the type of each variable?

-- 
Saludos

Santiago A.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal