I heard that sometimes (often?) compilers put the data to code section
and vice versa (code to data section) though it is generally not good
and 'can even degrade performance' - but why they do that was not explained
does maybe someone know something about that?
Other than hearing this, have you also read it somewhere on the interwebs? Perhaps you can post a link to such a claim, so we can know exactly what you are talking about?
I'm not super knowledgeable in this area, perhaps someone can illuminate me -- aren't the code and data sections mostly throwbacks to the 16bit segmented memory days?
I recall that when I learned to program in a compilable version of QuickBASIC (v4.5 for those who remember) they actually had instructions for setting the code and data segments that were active. One of the major optimizations I discovered in one of my programs once, was that the structure of my map rendering was causing me to jump all over memory and even across data segments -- which was obviously horrible. When I fixed it, I went from 5fps to 50fps, in a tight rendering loop where blitting should have been the bottleneck.
Other than hearing this, have you also read it somewhere on the interwebs? Perhaps you can post a link to such a claim, so we can know exactly what you are talking about?
alright, the first source is in agner fog objconv instruction
You can really put anything you want in sections of the executable, it's all just bytes anyway. The sections can be called anything also. The only difference is the flags that the OS uses to allocate the memory. Pure data sections could for example be allocated as non-executable or read-only.
This is the function that Windows uses to allocate memory when it loads executables, it might give you some hints about this.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366887(v=vs.85).aspx
I'm not sure what he's on about when he says that data in the code section could give you performance issues. The data needs to be somewhere, and I don't see why loading it from one arbitrary memory address would be worse than doing it from another arbitrary address. It might even be beneficial to have it near the code, because the jump table data would likely end up in the same memory page as the code that uses it... But I'm not sure, so don't qote me on that. But the compiler writers are usually not morons, so it would be pretty safe to bet that they know what they are doing.
not always sometimes compilers do a really weak stuff...
i also sont know what he mean about this performance issues,
though i must say that year ot two years ago i was calling the data - i mean i wrote the procedures right in machine code in my prog like
I'm not super knowledgeable in this area, perhaps someone can illuminate me -- aren't the code and data sections mostly throwbacks to the 16bit segmented memory days?
I recall that when I learned to program in a compilable version of QuickBASIC (v4.5 for those who remember) they actually had instructions for setting the code and data segments that were active. One of the major optimizations I discovered in one of my programs once, was that the structure of my map rendering was causing me to jump all over memory and even across data segments -- which was obviously horrible. When I fixed it, I went from 5fps to 50fps, in a tight rendering loop where blitting should have been the bottleneck.
no, you mixing old 640K ds: cs: stuff here...
i am moving about .data and .code sections in program image,
which are later mapped into a ram memory where ram pages are also mapped as "executable" "data" "readolny data" etc - and i wonder on the details of this here
and when counting the execution times it was much slower than
executing it in normal code section - i dont know what was a reason of that but it worked but had a speed penalty sadly
Headers
Code Section (the headers designate this section as Execute+Read)
Function 0
Instructions
Optional: NOP or INT3 padding
Optional: Case mapping table (and optional padding to the next pointer-sized boundary)
Optional: Case block pointers (and optional padding to the next 16 byte boundary)
Function 1
Instructions
...ETC...
Initialized Data Section(s) (the headers designate these section(s) as Read+Write or just Read)
Data!
Import Section (readonly after the loader finishes with it)
Data!
Export Section (readonly after the loader finishes with it)
Data!
Relocation Section (discarded after the loader finishes with it)
Data!
Resource Section (readonly)
Data!
(etc...)
