0

Lets say we are defining a variable :

float myFloat{3};

I assume that these steps are done in memory while defining a variable, but I am not certainly sure.

Initial Assume: Memory is consist of addresses and correspond values. And values are kept as binary codes.

1- create binary code(value) for literal 3 in an address1.

2- turn this integer binary code of 3 to float binary code of 3 in the address2. (type conversion)

3- copy this binary code(value) from address2 to the memory part created for myFloat.

Are these steps accurate ? I would like to hear from you. Thanks..

smalcakmak
  • 27
  • 1
  • 2
    How did you come up with these steps? Why do you believe a compiler would need to create a non-`float` literal value of 3 if it knows that it needs one of `float` type? – UnholySheep Sep 16 '22 at 12:37
  • 2
    related: https://stackoverflow.com/questions/15718262/what-exactly-is-the-as-if-rule – 463035818_is_not_an_ai Sep 16 '22 at 12:37
  • 2
    You may inspect the assembly code emitted by your specific compiler, to check what's actually going on. – πάντα ῥεῖ Sep 16 '22 at 12:37
  • 3
    The exact "steps" done by a compiler and the run-time depends quite a lot on when and where the variable is defined. Is it defined in namespace scope? As part of an object? A local variable inside a function? – Some programmer dude Sep 16 '22 at 12:39
  • It is unclear whether you are asking what the compiler is doing or what the runtime is doing – Drew Dormann Sep 16 '22 at 12:49
  • 1
    You can use https://godbolt.org/ to enter your piece of code, choose a compiler and see what the output is. In this particular case you will get a binary representation of the number. There are no run-time steps involved. – Vuk Vojta Sep 16 '22 at 12:53
  • Also, the steps in an optimized release build may be completely different than a debug build. That is an excellent exercise to help understand what optimizing compilers actually do. I would look at the debug build assembly code first - that should give you some warm fuzzies. Then look at the optimized release build - you may be surprised by the differences. – franji1 Sep 16 '22 at 13:06

1 Answers1

0

Conceptually that’s accurate, but with any optimization, the compiler will probably generate the 3.0f value at compile time, making it just a load of that constant to the right stack address. Furthermore, the optimizer may well optimize it out entirely. If the next line says myFloat *= 0.0f; return myFloat;, the compiler will turn the whole function into essentially return 0.0f; although it may spell it in a funny way. Check out Compiler Explorer to get a sense of it.

Ben
  • 9,184
  • 1
  • 43
  • 56
  • 1
    Prvalues don’t have addresses, so at least that part isn’t accurate. – Davis Herring Sep 30 '22 at 03:58
  • Yes, but... At `-O0` there's `.LCPI0_0: .long 0x40400000 # float 3` which is pretty much saying "put the floating-point number 3 somewhere. https://godbolt.org/z/1W8TPoKnr. If I make an explicit `int tmp = 3;` the constant comes in as `mov dword ptr [rbp - 8], 3` https://godbolt.org/z/hzxqsThn9 But of course with `-O3` it just turns into `mov eax, 3; ret`. If I have it return `float`, it still has a constant `0x40400000` https://godbolt.org/z/Kf8s5v9ds – Ben Sep 30 '22 at 17:52
  • That isn’t “conceptually”, though, is it? Neither the optimized nor unoptimized assembly corresponds directly to any coherent conceptual model, so the only one available would seem to be the abstract machine definition. – Davis Herring Sep 30 '22 at 18:43
  • It depends? You are right that the abstract machine may not have those steps. However, a beginner probably hasn’t gotten to the distinction between the abstract machine and real hardware. I find it valuable to understand both. The assembly and physical hardware matters for performance; the abstract machine for correctness. – Ben Oct 01 '22 at 17:44