[fpc-pascal] Convert to int64 note

[Ewald]

On 14/07/17 17:19, james at 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