1

Topic: And why not to make a stack it is even cleverer?

Feature for the compiler: here we for example transfer  or we create local  and why if there are no special instructions all that will be dynamic selected by it and with derived objects not to select too in a stack? I.e. all operators new caused in methods of this object if there are no special instructions, will be  in a stack for example by transmission of lines, it is possible then to do without reversal to a heap generally

2

Re: And why not to make a stack it is even cleverer?

Hello, Kingofastellarwar, you wrote: K> a feature for the compiler: K> here we for example transfer  or we create local  and why if there are no special instructions all that will be dynamic selected by it and with derived objects not to select too in a stack? K> i.e. all operators new caused in methods of this object if there are no special instructions, will be  in stack K> for example by transmission of lines, it is possible then to do without generally reversal to a heap Than it are not pleasant to you of reversal to a heap? The stack serial and at separation and the subsequent clearings will be quickly fragmented (faster, than a heap). It is possible to manage one heap without a stack, using any other data structures, - the stack is simply convenient for implementation of nested calls of procedures, and is supported by the processor.

3

Re: And why not to make a stack it is even cleverer?

Hello, Kingofastellarwar, you wrote: K> a feature for the compiler: K> here we for example transfer  or we create local  and why if there are no special instructions all that will be dynamic selected by it and with derived objects not to select too in a stack? Because a stack not the rubber. K> i.e. all operators new caused in methods of this object if there are no special instructions, will be  in stack K> for example by transmission of lines, it is possible then to do without generally reversal to a heap of Implementation of lines and so are able SSO. Generally, it is better to class to know, select storage dynamic, or not.

4

Re: And why not to make a stack it is even cleverer?

Hello, Kingofastellarwar, you wrote: K> a feature for the compiler: K> here we for example transfer  or we create local  and why if there are no special instructions all that will be dynamic selected by it and with derived objects not to select too in a stack? K> i.e. all operators new caused in methods of this object if there are no special instructions, will be  in stack K> for example by transmission of lines, it is possible then to do without generally reversal to heap Welcome to Rust Default - on a stack or in a heap, compiler business - but only while there lives the given function invocation. You want, that the object lived longer - explicitly create Box <T>, Rc <T> or similar - and then the question is descended.

5

Re: And why not to make a stack it is even cleverer?

Hello, Kingofastellarwar, you wrote: K> a feature for the compiler: K> here we for example transfer  or we create local  and why if there are no special instructions all that will be dynamic selected by it and with derived objects not to select too in a stack? K> i.e. all operators new caused in methods of this object if there are no special instructions, will be  in a stack I in the compiler and  and did, combined a stack and a heap in one bottle, superimposing a row of restrictions in one places and a bolt in others: http://thedeemon.livejournal.com/10126.html And in JVM escape analysis it now does for  and, speak, successfully enough.

6

Re: And why not to make a stack it is even cleverer?

Hello, Kingofastellarwar, you wrote: K> for example by transmission of lines, it is possible then to do without generally reversal to a heap Because if a line constant, apparently, it is possible to do without dynamic selection of storage generally. And if it is calculated in process without storage selection under the intermediate states not to manage. And the stack for such arbitrary manipulations with storage not very much approaches.

7

Re: And why not to make a stack it is even cleverer?

Hello, lpd, you wrote: lpd> Than you are not pleasant reversal to a heap? The stack serial and at separation and the subsequent clearings will be quickly fragmented (faster, than a heap). It is possible to manage one heap without a stack, using any other data structures, - the stack is simply convenient for implementation of nested calls of procedures, and is supported by the processor. What is the stack fragmentation?

8

Re: And why not to make a stack it is even cleverer?

Hello, Kingofastellarwar, you wrote: K> a feature for the compiler: K> here we for example transfer  or we create local  and why if there are no special instructions all that will be dynamic selected by it and with derived objects not to select too in a stack? K> i.e. all operators new caused in methods of this object if there are no special instructions, will be  in stack K> for example by transmission of lines, it is possible then to do without generally reversal to a heap so the size of a stack is unknown. How in that case to organize correct operation of a program? The item with. Passing questions  - why all the same with ++ did not give possibility to learn this size? - There is any warranty, what all local static variables (at least on one copy) get into a stack? (That is, whether does the compiler something like the analysis, to  the stack is necessary to contain all these variables, and such stack and selects)?

9

Re: And why not to make a stack it is even cleverer?

Hello, Pzz, you wrote: Pzz> Hello, lpd, you wrote: lpd>> Than you are not pleasant reversal to a heap? The stack serial and at separation and the subsequent clearings will be quickly fragmented (faster, than a heap). It is possible to manage one heap without a stack, using any other data structures, - the stack is simply convenient for implementation of nested calls of procedures, and is supported by the processor. Pzz> that such fragmentation of a stack? If to select a place in a stack, then to make much push, then to release selected on top level  a storage section the place will be empty but remains not  while pop do not return on top level. That is the occupied storage in a stack will be  with empty pieces. It is possible to tell that it is a stack fragmentation.

10

Re: And why not to make a stack it is even cleverer?

Hello, _hum _, you wrote: __> so the size of a stack is unknown. How in that case to organize correct operation of a program? __> the item with. Passing questions  __> - why all the same with ++ did not give possibility to learn this size? __> - there is any warranty, what all local static variables (at least on one copy) get into a stack? (That is, whether does the compiler something like the analysis, to  the stack is necessary to contain all these variables, and such stack and selects)? In storage the compiler and  is engaged in layout not. It platformo - and hardware-dependent procedure. For "bare metal" the programmer himself defines the size of a stack and a heap in a linker-script and can place a stack completely both in a processor cache, and in exterior storage. For acquaintance it is possible to look articles: https://www.opennet.ru/docs/RUS/gnu_ld/gnuld-3.html and https://habrahabr.ru/post/150327/In an operating system the stack and a heap are controlled by the manager of storage of an operating system. Static variables are defined in separate section of storage and do not occupy neither a stack nor a heap, their lifetime is equal lifetime (operation) of the program.

11

Re: And why not to make a stack it is even cleverer?

Hello, Kingofastellarwar, you wrote: K> a feature for the compiler: K> here we for example transfer  or we create local  and why if there are no special instructions all that will be dynamic selected by it and with derived objects not to select too in a stack? K> i.e. all operators new caused in methods of this object if there are no special instructions, will be  in stack K> for example by transmission of lines, it is possible then to do without generally reversal to a heap https://msdn.microsoft.com/ru-ru/library/wb1s57t5.aspx https://msdn.microsoft.com/ru-ru/library/5471dc8s.aspx So to select storage in a stack it is quite possible. And here to do that automatically - there can be problems. If function A installed this mode - whether it operates on function B which is caused from A? If operates - how to be in case B it is caused not from A? If storage is selected in a stack - that will be, if, forgetting about it, to transfer the pointer to it in other flow? Etc.

12

Re: And why not to make a stack it is even cleverer?

Hello, Pavel Dvorkin, you wrote: PD> https://msdn.microsoft.com/ru-ru/library/wb1s57t5.aspx PD> https://msdn.microsoft.com/ru-ru/library/5471dc8s.aspx PD> So to select storage in a stack it is quite possible. And here to do that automatically - there can be problems. PD> if function A installed this mode - whether it operates on function B which is caused from A? If operates - how to be in case B it is caused not from A? PD> If storage is selected in a stack - that will be, if, forgetting about it, to transfer the pointer to it in other flow? PD> etc. a stack - the specific (fast) area of storage intended for storage of temporary variables in local area of visibility (within code curly brackets). For example: void foo () {//the frame 1 on a stack was selected and in the beginning the frame the address of the program code was saved where it is necessary to be returned at an output from function,//and also the code of protection of a stack stack_smashing_protector (http://wiki.osdev.org/Stack_Smashing_Protector) char str [10] can be added; int b; {//the frame 2 on a stack int k was selected; int d;} //the frame 2 was released on a stack, k and d were released (failed)//if (intentionally or through an oversight) in str function memcpy more than 10 byte that it is possible to re-record the address of reset from foo (),//carrying out attack to a stack (to transfer the code to a virus or leaving in undefined behavor, and the best case terminate SIGSEGV)}//the frame 1 was released on a stack, str and b were released (failed) If you noted, the compiler always knows the size of all objects and variables in the unit and, accordingly, allocates them in the stack frame (selects a place under them). For these purposes in the standard With ++ the type std:: array <> which objects similarly With an array it is allocated on a stack, unlike std:: vector <> which data is allocated in a heap has been entered. On this principle static analysis of depth of usage of a stack is under construction. If on what or to the reasons for you the size of an array at a compilation stage is not conducted, its length is calculated in the course of operation, but there is a requirement or other weighty reasons to allocate the data in a stack it is possible to interpose into the code above-stated "control function" a stack _malloca, taking thus on itself all responsibility for consequences of its usage (including the prohibition of possibility static the analysis of depth of usage of a stack). But it too the temporal data living in limits of curly brackets. For the constant data there is a heap and it is not necessary to use storage not for the designated purpose (well unless for fun or for experiments).

13

Re: And why not to make a stack it is even cleverer?

Hello, _smit, you wrote: _> in storage the compiler and  is engaged in layout not. It platformo - and hardware-dependent procedure. _> for "bare metal" the programmer himself defines the size of a stack and a heap in a linker-script... A little myself I will correct, in a linker-script storage which only is labeled will be either for the code, or for the data, including flags RW (is modified) or RO (for reading only), and the beginning of a stack and the heap beginning is assigned appropriated) by the programmer in the start code for bare metal, or application launch system function in OS.

14

Re: And why not to make a stack it is even cleverer?

Hello, Kingofastellarwar, you wrote: K> a feature for the compiler: K> here we for example transfer  or we create local  and why if there are no special instructions all that will be dynamic selected by it and with derived objects not to select too in a stack? K> i.e. all operators new caused in methods of this object if there are no special instructions, will be  in stack K> for example by transmission of lines, it is possible then to do without generally reversal to a heap This feature is called Avoiding/fusing allocations and enters as an optional part of the standard of a C ++ 14. An implementation is allowed to omit a call to a replaceable global allocation function (18.6.1.1, 18.6.1.2). When it does so, the storage is instead provided by the implementation... And generally for redefinition of the mechanism of dynamic selection of storage in With ++ there is a concept . And already there are ready implementations stack  if it would not be desirable to hope for the compiler or it does not support this feature. In About dynamic selection of storage on a stack implemented in the form of VLA.

15

Re: And why not to make a stack it is even cleverer?

Hello, _smit, you wrote: Almost all is true _> _> void foo () _> {//the frame 1 on a stack was selected and in the beginning the frame the address of the program code was saved where it is necessary to be returned at an output from function, _> {//the frame 2 on a stack _> int k was selected; _> int d; _>}//the frame 2 was released on a stack, k and d were released (failed) _>}//the frame 1 was released on a stack, str and b were released (failed) _> Actually at least VC ++ so does not do. Storage for all local variables is led out at an input in function (I think, on the maximum total volume though precisely I do not know, did not check) though variables, of course, "logically" cease to exist at an output on the "}". However storage thus is not released." Conceptually "would be correct to make, as you marked, but in a reality becomes differently. void f () {int a [100]; for (int i = 0; i <100; i ++) a [i] = i; int x = 10; if (x == 10) {int b [100]; for (int i = 0; i <100; i ++) b [i] = i;} } void f () {00EE3C10 push ebp 00EE3C11 mov ebp, esp 00EE3C13 sub esp, 414h//storage selection on all local variables 00EE3C19 push ebx 00EE3C1A push esi 00EE3C1B push edi 00EE3C1C lea edi, [ebp-414h] 00EE3C22 mov ecx, 105h 00EE3C27 mov eax, 0CCCCCCCCh 00EE3C2C rep stos dword ptr es: [edi] int a [100]; for (int i = 0; i <100; i ++) 00EE3C2E mov dword ptr [ebp-1A0h], 0 00EE3C38 jmp f+39h (0EE3C49h) 00EE3C3A mov eax, dword ptr [ebp-1A0h] 00EE3C40 add eax, 1 00EE3C43 mov dword ptr [ebp-1A0h], eax 00EE3C49 cmp dword ptr [ebp-1A0h], 64h 00EE3C50 jge f+57h (0EE3C67h) a [i] = i; 00EE3C52 mov eax, dword ptr [ebp-1A0h] 00EE3C58 mov ecx, dword ptr [ebp-1A0h] 00EE3C5E mov dword ptr a [eax*4], ecx 00EE3C65 jmp f+2Ah (0EE3C3Ah) int x = 10; 00EE3C67 mov dword ptr [x], 0Ah if (x == 10) {00EE3C71 cmp dword ptr [x], 0Ah 00EE3C78 jne f+0A3h (0EE3CB3h) int b [100];//and here it is selected nothing for (int i = 0; i <100; i ++) 00EE3C7A mov dword ptr [ebp-350h], 0 00EE3C84 jmp f+85h (0EE3C95h) 00EE3C86 mov eax, dword ptr [ebp-350h] 00EE3C8C add eax, 1 00EE3C8F mov dword ptr [ebp-350h], eax 00EE3C95 cmp dword ptr [ebp-350h], 64h 00EE3C9C jge f+0A3h (0EE3CB3h) b [i] = i; 00EE3C9E mov eax, dword ptr [ebp-350h] 00EE3CA4 mov ecx, dword ptr [ebp-350h] 00EE3CAA mov dword ptr [ebp+eax*4-344h], ecx 00EE3CB1 jmp f+76h (0EE3C86h)}} 00EE3CB3 push edx 00EE3CB4 mov ecx, ebp 00EE3CB6 push eax 00EE3CB7 lea edx, ds: [0EE3CCCh] 00EE3CBD call _RTC_CheckStackVars@8 (0EE108Ch) 00EE3CC2 pop eax 00EE3CC3 pop edx 00EE3CC4 pop edi 00EE3CC5 pop esi 00EE3CC6 pop ebx 00EE3CC7 mov esp, ebp//and here clearing - esp is recovered on value to an input in function 00EE3CC9 pop ebp 00EE3CCA ret In the remaining quite agrees.

16

Re: And why not to make a stack it is even cleverer?

Hello, Pavel Dvorkin, you wrote: PD> Hello, _smit, you wrote: PD> Almost all is true... PD> Actually at least VC ++ so does not do. Storage for all local variables is led out at an input in function (I think, on the maximum total volume though precisely I do not know, did not check) though variables, of course, "logically" cease to exist at an output on the "}". However storage thus is not released. Yes, all is true, with units slightly got excited, it nevertheless unprofitable operation, operates within the limits of a call of functions. Gcc arrives also, so-called "Calling Convention".

17

Re: And why not to make a stack it is even cleverer?

Hello, _smit, you wrote: _> Yes, all is true, with units slightly got excited, it nevertheless unprofitable operation, operates within the limits of a call of functions. Gcc arrives also, so-called "Calling Convention". Calling convention is another. These are rules of parameter passing of function (from left to right (now is not present already, was in Win16) or from right to left, through a stack and-or registers who clears a stack at an output (causing or caused). To place assignment in a stack under function local variables it is relations has no. Well and a problem not that is unprofitable operation. Now all local variables it is simple offsets from ebp. There such ebp-const it is scattered much. If to select storage at each input in the unit one ebp you will not manage, it is necessary to get the whole manager of storage who will define addresses of variables at i th nesting level of curly brackets taking into account that was on all previous i-1 levels.

18

Re: And why not to make a stack it is even cleverer?

Hello, _smit, you wrote: the Amusing consequence. Here such terrible code void f () {int x = 10; int * p = NULL; if (x == 10) {int b [100]; for (int i = 0; i <100; i ++) b [i] = i; p = b;}//1//2 for (int i = 0; i <100; i ++) printf ("%d\n", p [i]);} truth until between//1 and//2 other code in which storage is led out will not be interposed will work nevertheless.  god somebody from thought that I advise so to write

19

Re: And why not to make a stack it is even cleverer?

Hello, Pavel Dvorkin, you wrote: PD> Hello, _smit, you wrote: PD> the Amusing consequence. Still such observation: http://ideone.com/E7vANn that is the compiler can  stack storage for other variables if lifetime of the previous ended

20

Re: And why not to make a stack it is even cleverer?

Hello, uzhas, you wrote: U> that is the compiler can  stack storage for other variables if lifetime of the previous ended I Think that cannot, and is obliged. Otherwise the memory size can increase in N time without any sense. The algorithm here  should be about following. Let we enter into the nesting level unit then to us the total volume of variables S in units of level 0, 1 is already known... N-1 for this unit. Here from it also it is allocated these variables of the unit of level N. At an output from the unit of level N it is considered this storage of free and if there will be one more unit of level N, we allocate again, since S. The total volume for the unit of level 0 is equal 0 (more precisely, the total of the sizes of those variables which the compiler got under the initiative)

21

Re: And why not to make a stack it is even cleverer?

Hello, Pavel Dvorkin, you wrote: PD> Hello, _smit, you wrote: _>>... Operates within the limits of a call of functions. Gcc arrives also, so-called "Calling Convention". PD> Calling convention is another. These are rules of parameter passing of function (from left to right (now is not present already, was in Win16) or from right to left, through a stack and-or registers who clears a stack at an output (causing or caused). To place assignment in a stack under function local variables it is relations has no. Truly, looked at determination "Calling Convention", indeed. Studied the organization of stack MIPS under documents, similar "MIPS Calling Convention" (https://acm.sjtu.edu.cn/w/images/d/db/M … ummary.pdf), etc. (http://people.ee.duke.edu/~sorin/ece152/lectures/2.4-isa.pdf, http://www.cs.ucsb.edu/~franklin/154/Fa … dout.pdf), requirement plus to SSP, therefore it was postponed in a head that layout of local variables was a calling convention part.

22

Re: And why not to make a stack it is even cleverer?

Hello, Pavel Dvorkin, you wrote: PD> Hello, uzhas, you wrote: U>> that is the compiler can  stack storage for other variables if lifetime of the previous ended PD> I Think that cannot, and is obliged. In an example above it can, but is not obliged. To you if only to argue? PD> differently the memory size can increase in N time without any sense. A phrase without any sense. To me here to be frightened number N?

23

Re: And why not to make a stack it is even cleverer?

Hello, uzhas, you wrote: PD>> I Think that cannot, and is obliged. U> in an example above it can, but is not obliged. To you if only to argue? Yes is not present, it is simple here the stack mechanism of selection, and its this consequence. PD>> differently the memory size can increase in N time without any sense. U> a phrase without any sense. To me here to be frightened number N? At big enough size of local variables and decent N to receive out of the blue stack overflow there where it is possible to manage without it - to be frightened I did not become, but would express authors of the code unflatteringly.

24

Re: And why not to make a stack it is even cleverer?

Hello, Pavel Dvorkin, you wrote: U>> in an example above it can, but is not obliged. To you if only to argue? PD> yes is not present, it is simple here the stack mechanism of selection, and its this consequence. No consequence here is present we look here: http://rextester.com/WVP96955 clang did not begin to splice two stack variables and its this right similar optimization compilers implement owing to the possibilities

25

Re: And why not to make a stack it is even cleverer?

Hello, uzhas, you wrote: U> clang You did not begin to splice two stack variables and its this right is right, and it is wrong