Jorgon, the main point isn't speed, but protecting code section against bad pointers etc.. and even more important, enforcing that constant data is _constant_.

It's true that code/data mixing has a LOT to do with speed to - also on P4. http://groups.google.com and have a look for "a common belief or a wrong C[++] compiler?", a fair bit down discussing implementations of the IDEA algorithm.

Iirc there was a 33x speed penalty on P4 for having code and data within the same 1kb page.
Posted on 2004-10-17 12:49:32 by f0dder
It's true that code/data mixing has a LOT to do with speed to - also on P4
Well on my P4 machine it made no difference at all, nor on my AMD64 machine. So what's going on?
Posted on 2004-10-17 13:22:30 by jorgon
Guess it might depend on what you're doing? You did read-only operations with your code? I wonder if there's any good reasons to keep code and data in one big segment.. seems to be enough reasons to avoid it.
Posted on 2004-10-17 13:26:06 by f0dder
As mentioned in my help file snippet, it is inappropriate to try to write to data within a "code" section. I am talking here only about read-only code. I don't believe it is any slower on a P4 or AMD64, not on my tests anyway.
Posted on 2004-10-17 16:08:09 by jorgon
Much of the advantage of FLAT memory model is the freedom from ancient segmented architecture and the assumptions that went with segments. Often sections are confused with segments and argued using the same set of asumptions yet it is a matter of fact that code and data live in the same memory address area as each other in FLAT memory model.

There are times when there are advantages in seperating data and code yet this has often been due to compiler design trailing well behind hardware capacity. When you have years of compiler design based on code and data seperation, such bad habits take a long time to break.

In terms of application design, it is often wise to keep data in an entirely different place to executable code and this can be an external file yet there are methods of embedding massive quantities of data in a code section that have large performance advantages if managed properly.

It may be common in current compiler designs to keep a single code and a single data section but there is nothing in the PE specification to prevent an advanced compiler from writing multiple iterleaved sections of code and data and resources.

I have not fully digested the technical data that Jeremy referred to with AMD 64 bit hardware but I would suggest that hardware design appears to be going even further away from the need to seperate code and data. What is probably the case is that compiler designers WANT to write RISC style compilers when the world of computing keeps going in the direction of x86 CISC.

Compiler design will need to keep up with current hardware rather than continue to desire junk that was out of date 10 years ago. It means that they will have to start thinking in hardware specific terms to get the full performance from emerging hardware rather than multiport RISC hardware.

Regards,

hutch at movsd dot com
Posted on 2004-10-17 18:04:42 by hutch--
Try writing something intelligible?
Posted on 2004-10-17 18:43:32 by f0dder
f0dder, could you please be a bit more specific?
Posted on 2004-10-18 04:38:31 by japheth
There are the "correctness" issues, as to whether or not it is good practice whether or not data should be embedded within the code, and there are speed issues.

The correctness issue isn't one I can really comment on (I do all the wrong things in all the places I feel like, so it'd be hypocracy :wink: ). As for the speed issue, I can tell you that if data is in the code section you have effectively wasted part of the cache at the very least, this will probably have very little effect on any of the type of hobbled bits of code we put together to test this issue, and probably doesn't have a massive effect on execution speed. But the issue does arise as f0dder said, when you write to the data while it's in the code section. The dirty flags for the cache aren't updated in the code cache, only in the data cache, so the data cache is properly maintained, but the code cache isn't. It takes the processor a huge amount of time to realise this error, and will destroy the performance of your algorithm.

Read-only data is O.K. but even then it'll reduce the effectiveness of your cache.

Mirno
Posted on 2004-10-18 07:26:22 by Mirno
hutch--, compiler designers being stuck in the RISC mindset might partly be due to learning on RISC processors at the university level. It is strange how pervasive the idea of optimization at the lowlevel being superfluous is - like improvement beyond the compiler would be rare or impossibly hard to achieve.
Posted on 2004-10-18 10:53:14 by bitRAKE
Little off topic maybe should be under another thread but for now ....

"MASM cannot resolve forward references to data."

From Jump Street i wonder about masm minor issues. I figure that it would at lease help to protect a program written with it no matter how small that protection is.

Just because of masm so called faults it would be harder to be step-on than a program written with fasm or most any other assembler provided you knew how to deal with or at lease understand masm issues.

Any dissembler/debugger would have to work a little bit harder in an attempt to crack because it has only one way to go while tripping over masm s**t as well as my just to boot.

Is there even remote possibility that my theory was right?

Please ( J ) do break my heart if possible.


And yes. You can put data nearly anywhere but where do it all end up at when you dump it. Is it in one pile as it should be or scarier all over the place (under that piece of code that you did not want to lead the world too the password or whatever)
Posted on 2004-10-19 00:50:04 by cmax