11-11-2009 02:11 PM
Hey menchar -
The basic reason the reason the crash occurs is that the compiler and linker need to have an agreement about alignment. In our case, they do not. The compiler emits instructions regarding the data segment, text segment, etc. of the image that assume 16 byte alignment, but when the linker actually creates the image, it ensures everything (the data segment, the text segment, etc.) is 8 byte aligned. This should also explain the semi-randomness of crashes you are seeing. Because the linker ensures 8 byte alignment, you basically have a 50% chance that things are going to work.
NickB
National Instruments
11-11-2009 02:51 PM
Nick -
Thanks, I think 😉
That would explain the behavior - if it gets built once with proper alignment, then it's good to go.
The reason for the string initialization problem is that the Intel compiler uses special uP instructions optimized for string manipulation.
I guess I'm surprised that the CVI linker doesn't support 16 byte alignment.
Is there any way to tell it to do so?
Is there any way to use, say, the Visual Studio linker in release mode?
Do you have any feel for the meaning, if any, of the base address used for the application, you can set it in the build options window.
Is the CVI linker the lccWin-32 linker? Is there any way to set a lonker argument to cause it to 16 byte align?
Thanks.
Menchar
11-11-2009 06:20 PM
menchar -
Unfortunately, there is no way to tell the CVI linker to enforce 16 byte alignment, and there is no way to use someone else's linker from within the CVI environment. You've demonstrated some of the limitations this strict enforcement, and while it is unlikely there will be a change for this in the near term, it is something that the development team will investigate.
The base address of the application - as I think you know - simply determines where the image is laid down in the process' virtual address space. As you've guessed, this can greatly affect the size of the contiguous memory block you can allocate. However, not only does the base address of your executable change the theoretical size of the largest contiguous block you can allocate, but all dll's you are dependent upon change this as well. Once they've been mapped into the virtual address space (which you have less control over because relocations are more probable) the largest contiguous block is further limited.
The default setting in CVI is to load the executable with a base address at the 4MB logical memory location. This is primarily convention, because back in the days of Win 95 the space below 4MB was reserved by the OS. Now, because of this convention, other dll's, including OS dll's, avoid this address so that relocation of your executable should not be necessary. While it is rare that an exe would need to be relocated, the sacrifice of 4MB is probably worth it to maintain the convention, as well as a relatively high level of control over where your executable is loaded.
NickB
National Instruments
11-11-2009 06:41 PM
Nick -
Thanks for the reply.
Well, these restrictions seriously limit the value of using an opimizing compiler with CVI. It's a pity, too, because of the tremendous improvement a good compiler like the Intel can make performance wise on the newer x86 micros. I'm seeing hundred-fold or more speed improvements over the release mode CVI compiler, especially when vectorization is used.
The alignment issue, along with the restriction on the use of compiler optimized libraries, really puts a damper on an otherwise good thing.
I guess I could simply rebuild the application until it aligns (which it seems to do every time on the first build using the release compiler after CVI startup).
Do all of these issues go away with 64 bit CVI, or will similar issues continue to exist? Will we be able to use the Intel compiler on 64 bit CVI?
Menchar
11-23-2009 05:48 PM
Nick or anyone who may know -
Does the same 8 / 16 byte alignment problem exist when I use the Visual Studio C++ compiler? If I use the VCPP "8" compiler with "optimize for speed" selected (using the VCPP template provided by NI in the CVI 9.0.1 release) do I have the same alignment issue?
I found the VCPP 8 compiler (the one that comes with Visual Studio 2005) to be faster even than the Intel 11.1 compiler when not using the O3 optimizations.
But, I dont want to use the VCPP compiler if I am going to have the same linking issue as with the Intel compiler.
It would be kindof weird if the NI-provided VCPP template had this problem, but I thought I'd ask.
Thanks.
Menchar