News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

.code or .data section

Started by emre_tinaztepe, July 20, 2007, 11:10:42 PM

Previous topic - Next topic

Jimg

As in the original thread question, I changed a static library lib containing only a grid control I have been working on.  I moved everything from the initialized data section, .data, to the .code section, and sure enough, when loading the control in an app, the exe is 512 bytes smaller.

Tipidy

That's interesting to know that if you store your data in the .code section and not the .data section the exe file will be smaller when compiled and linked  :dance:, I guess that's why virus writers to this  :naughty:.

hutch--

It only works on very small files which don't write back over their existing data. At best you can save 512 bytes but once an app gets over a minimal size the gains are very few. You usually do better using Pelle's linker and a section merge after.

The virus guys use it to concentrate their code in one place so they don't have to find the .DATA section and find a space in it to write to.
Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php

Synfire

[off topic]
Quote from: Tipidy on August 28, 2007, 07:18:33 PMI guess that's why virus writers to this  :naughty:.

Hutch is right, virus writers have an alternate reason. If you think about what viruses do, they infect, which means their code needs to be portable between the applications which they are infecting. Those virus writers concentrate the code so it's much more portable. I had a gig a few years ago coming up with signatures and those little buggers can be crafty by design.
[/off topic]

Some of you are seeing just the good side of this (the size optimization) but there is a reason I said this is a bad practice. It's fine for read operations but once you start putting data that's going to be written to in your code section, you're going to get some speed penalties. I suggest you profile your code regularly if you do this because in some cases you won't get the penalties, then you'll make a few small changes and bam! You're hit with almost 10x speed reduction. I'm still unsure why it does it, but it usually happened to me when I was messing with pointers. So best suggestion is just not to do it, put writable data somewhere else (the Heap maybe).

Tedd

In most cases you can (should) place your 'data' in the .const section - except, of course, if you plan to modify it. The const data will be stored in the same section as the names of the imported dlls+functions, so it won't actually create an extra section. Generally this produces the same size exe as if you put the data into the code section, but with the protection and separation from being in a different section.

The slow down caused by modifying data in the code section is the same as that caused by self-modifying code (as far as the processor is concerned, any modification in the code section is a code modification). So, the cache-line must be flushed and read in again (even though it's a 'data' modification, it's on a code cache-line, so it needs to be kept coherrent. And if you happen to be executing from there at the time... poor you :bdg
No snowflake in an avalanche feels responsible.

emre_tinaztepe

 I do not write viriis but I know i could! ( the reply is for those curious guys!) I am trying to create my own PE format which i will use for my compression program. It s a challenge for my class!!!

Is that enough?

By the way, thanks to all repliers and sorry for late replying:) I was in the graduation ceremony of my school "Turkish Military Academy" :) And this is my first reply as a second lieutenant:):):)