Naming Constants

[Clyde]

I wonder if anyone knows, if a Constant variable, is automatically named as an Integer or Float without the prefixes being typed.

For example:

Code: [Select]

Const PI = 3.141593

Just that i've looked through quite a lot of example source code, and there isn't any reference to it being Const As Double Pi=3.141593
And wondered if it is neccassary. This might appear to be a dumb question, but as i've noticed it a bit was curious.

Cheers and thanks for your time,
Clyde.

[Stonemonkey]

Consts aren't stored in the same way that variables are, as a program is compiled the values of constants are written into the code. If the code requires that a const is an integer it's written as an integer in the code, if it's required as a single/double then the appropriate floating point representation is written in to the code to be used in that case.

in the following code:

Code: [Select]

const v=3.5

dim i as integer,f as single,d as double

i=v
f=v
d=v

the integer representation  of v is written directly into the asm code and the single and double fp representations are too but in a slightly different way to integers (only because the fpu registers work slightly differently to the general purpose registers).

The compiler really takes care of that for you.

[Clyde]

Thanks so much for the explanation matey.

Cheers,
Clyde.

[Stonemonkey]

np clyde. Done a little more investigation into this and found some strange things that the compiler does even though it doesn't make any difference to what i've said above.

if v=3.5 i get the code (I've added some comments to this at ###)

Code: [Select]

.section .text
.balign 16

.globl _main
_main:
push ebp
mov ebp, esp
and esp, 0xFFFFFFF0
call ___main
push dword ptr [ebp+12]
push dword ptr [ebp+8]
call _fb_Init@8
call _fb_CallCTORS
.Lt_0001:

###load as double from Lt_0003
fld qword ptr [Lt_0003]

###store as integer in 'i'
fistp dword ptr [_I]

###load again as double from Lt_0003
fld qword ptr [Lt_0003]

###store as single in 'f'
fstp dword ptr [_F]

###push the double value onto the stack
push dword ptr [Lt_0003]
push dword ptr [Lt_0003+4]

###pop the double value off the stack into 'd'
pop dword ptr [_D+4]
pop dword ptr [_D]

.Lt_0002:
push 0
call _fb_End@4
mov esp, ebp
pop ebp
ret
#global initialized constants

.section .data
.balign 16
.balign 8

###stored as double
Lt_0003: .double 3.5
#global non-initialized vars

.section .bss
.balign 16
.balign 4
.lcomm _I,4
.balign 4
.lcomm _F,4
.balign 8
.balign 8
.lcomm _D,8


but if i make v=57 i get

Code: [Select]

.section .text
.balign 16

.globl _main
_main:
push ebp
mov ebp, esp
and esp, 0xFFFFFFF0
call ___main
push dword ptr [ebp+12]
push dword ptr [ebp+8]
call _fb_Init@8
call _fb_CallCTORS
.Lt_0001:

###move the integer value of 57 in to 'i'
mov dword ptr [_I], 57

###push the single value on to the stack
push dword ptr [Lt_0003]

###pop the single value off the stack and in to 'f'
pop dword ptr [_F]

###push the double value on to the stack
push dword ptr [Lt_0004]
push dword ptr [Lt_0004+4]

###pop the double value off the stack and in to 'd'
pop dword ptr [_D+4]
pop dword ptr [_D]

.Lt_0002:
push 0
call _fb_End@4
mov esp, ebp
pop ebp
ret
#global initialized constants

.section .data
.balign 16
.balign 4

###single float
Lt_0003: .float 57
.balign 8

###double float
Lt_0004: .double 57
#global non-initialized vars

.section .bss
.balign 16
.balign 4
.lcomm _I,4
.balign 4
.lcomm _F,4
.balign 8
.balign 8
.lcomm _D,8

Anyone got any explanation of the differences in behaviour there?

[Rbz]

I just cant see what's wrong 

Seems to me that FB compiler are taking care about it.

[Clyde]

My two pennies worth, what version of Freebasic are you using. And they did release new headers a few days back.
Quite possibly there's a fix in those, unless you havent allready got them.

[Stonemonkey]

Yeah, it takes care of it but it uses different methods depending on what the value in v is which just seems a bit strange.

[Rbz]

What I can see is when you choose an integer, compiler just need to create an another variable (Lt_0004) to load your integer into float
 

[Stonemonkey]

what i was wondering was when v=3.5 the integer is dealt with like:

Code: [Select]

###load as double from Lt_0003
fld qword ptr [Lt_0003]

###store as integer in 'i'
fistp dword ptr [_I]

and when v=57 it's like:

Code: [Select]

###move the integer value of 57 in to 'i'
mov dword ptr [_I], 57

thinking that int(3.5)=4 shouldn't the first case just be:

Code: [Select]

###move the integer value of 4 in to 'i'
mov dword ptr [_I], 4

since it's a const and isn't going to change.

[Rbz]

Oh, now I understand, well I'm with you, seems a bit strange.  Â  


[EDIT]

Code: [Select]

###load as double from Lt_0003
fld qword ptr [Lt_0003]

###store as integer in 'i'
fistp dword ptr [_I]



[EDIT2]

Ah jeez, I must be blind, you're right StoneMonkey

fistp rounds 3.5 to 4
or 3.4 to 3

[Stonemonkey]

fistp rounds to the nearest integer, in the case of 3.5 it is rounded up to 4. What I'm wondering is why doesn't the compiler do that at compile time rather than convert from double to integer each time the const is used in code?

[Stonemonkey]

Anyway, back to the original question. The only thing i can see to watch out for would be if you're using a constant in a lot of integer calculations make sure the constant is a whole number otherwise there'll be a lot of needless float to int conversions going on.