Building WINE with Intel ICC for Linux

[Steven Edwards]

Hello,
I was able to build WINE with the Intel Compiler for Linux. Intel
allows free usage for non-comercial works so I figured I would check
and see if changing compilers would yield better performance. According
to Intels site it is supposed to give a 15 to 30% speed boost in
applications. I was able to compile WINE with only about a 10 line
patch. Somehow some of of the inline asm is already getting defined by
icc. I am having some problems running graphical applications and maybe
it is related to the code I had to disable. If anyone else wants to
test I figure this might be a good tool to have if you are porting a
Winelib application and want a large performance speed up.

I was able to get all of WINE to build but was not able to run any
graphical applications due to the crash show in the attached crash.log 
I was however able to run quite a few console applications including
regresion tests which showed failures quite a few failures.

If anyone is interested in building WINE with the Intel Compiler I will
be happy to test a bit but I dont have a lot of time to put in to it.
Attached is my hack.diff and the log from trying to run regedit.

1. Download ICC and run icsvar.sh
2. apply the following patch
3. Configure wine with ./configure CC=icc
4. recompile WINE.

Thanks
Steven

__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover

[Mike Hearn]

> +//__ASM_GLOBAL_FUNC( NtCurrentTeb, ".byte 0x64\n\tmovl 0x18,%eax\n\tret" );
> -__ASM_GLOBAL_FUNC( wine_get_fs, "movw %fs,%ax\n\tret" )
> +//__ASM_GLOBAL_FUNC( wine_get_fs, "movw %fs,%ax\n\tret" )
>  __ASM_GLOBAL_FUNC( wine_get_gs, "movw %gs,%ax\n\tret" )
>  __ASM_GLOBAL_FUNC( wine_get_ss, "movw %ss,%ax\n\tret" )
> -__ASM_GLOBAL_FUNC( wine_set_fs, "movl 4(%esp),%eax\n\tmovw %ax,%fs\n\tret" )
> +//__ASM_GLOBAL_FUNC( wine_set_fs, "movl 4(%esp),%eax\n\tmovw %ax,%fs\n\tret" )
> 0x40b5b7d8 (DefResolution [xfont.c] in X11DRV.DLL): addb        %al,%fs:0x0(%eax)

No surprise it crashes, this code is setting something in the TEB which
you commented out. Wine won't get anywhere when missing such critical
functions: being able to set and access the TEB is vital for nearly all
Wine functions. For Wine on ICC to be useful that must be fixed.

thanks -mike

[Steven Edwards]

--- Mike Hearn  wrote:
> No surprise it crashes, this code is setting something in the TEB
> which
> you commented out. Wine won't get anywhere when missing such critical
> functions: being able to set and access the TEB is vital for nearly
> all
> Wine functions. For Wine on ICC to be useful that must be fixed.

Ok thats what I thought but if I dont comment that code out then I get
link errors saying that the functions are already defined. Why would
these functions already be there?

Thanks
Steven

__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover

[Eric Pouech]

Steven Edwards a écrit :
> --- Mike Hearn  wrote:
> > No surprise it crashes, this code is setting something in the TEB
> > which
> > you commented out. Wine won't get anywhere when missing such critical
> > functions: being able to set and access the TEB is vital for nearly
> > all
> > Wine functions. For Wine on ICC to be useful that must be fixed.
>
> Ok thats what I thought but if I dont comment that code out then I get
> link errors saying that the functions are already defined. Why would
> these functions already be there?

why I don't understand is why you __GNUC__ defined in your compilation 
process. it sounds odd that ICC would set it
A+

[Warren Turkal]

Eric Pouech wrote:
> why I don't understand is why you __GNUC__ defined in your compilation
> process. it sounds odd that ICC would set it

I believe that ICC attempts to be fully compatible with the GNU C dialect of
C.

wt

[Steven Edwards]

Hi,
--- Warren Turkal  wrote:
> Eric Pouech wrote:
> > why I don't understand is why you __GNUC__ defined in your
>
> compilation
> > process. it sounds odd that ICC would set it
>
> I believe that ICC attempts to be fully compatible with the GNU C
> dialect of
> C.

Yes from what I understand it even support GCC extentions. It seems it
might not possibly be setting __GNUC__ right. How does GCC define this?
Is it __GNUC__=3 ?

Thanks
Steven

__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/

[Eric Pouech]

Steven Edwards a écrit :
> Hi,
> --- Warren Turkal  wrote:
> > Eric Pouech wrote:
> > > why I don't understand is why you __GNUC__ defined in your
> >
> > compilation
> > > process. it sounds odd that ICC would set it
> >
> > I believe that ICC attempts to be fully compatible with the GNU C
> > dialect of
> > C.
>
> Yes from what I understand it even support GCC extentions. It seems it
> might not possibly be setting __GNUC__ right. How does GCC define this?
> Is it __GNUC__=3 ?

the real issue is that gcc and icc handle differently extern inline 
foo(), when we actually define foo() as non inline (for inclusion in 
import table for example): icc handles as gcc the case where the non 
inline form is a real C function, but fails for a full assembly form.
But, it doesn't seem icc (for Linux) support the stdcall calling 
convention, which is a real showstopper

A+