Re: [pcre-dev] [PATCH] JIT support with Intel compiler, old…

Top Page
Delete this message
Author: Daniel Richard G
Date:  
To: Zoltán Herczeg
CC: pcre-dev
Subject: Re: [pcre-dev] [PATCH] JIT support with Intel compiler, older Solaris
On Thu, 15 Nov 2012, Zoltán Herczeg wrote:

> Hi Daniel,
>
> Could you split the patch into two:


Okay, I'll work on that.

> 1) Older solaris support
>
> I think an #if based soultion could work here:
>
> #if defined(old_solaris)
> asm for old solaris
> #else
> original code
> #endif


Only problem is, it's not clear how the assembly should refer to local
variables ("from" and "to"). I was reviewing this article...

     http://dsc.sun.com/solaris/articles/x86_assembly_lang.html


...which describes different approaches, and their caveats (e.g.
optimization). Search for occurrences of "local" in the text to find these
quickly.

> Or it would be even better, if you could find a system call for cache
> flush, and get rid the assembly code in the old solaris case.


I looked and looked, but Solaris does not appear to provide this.

> This may be supported there:
>
> http://man-wiki.net/index.php/2:cacheflush


"This system call is only available on MIPS based systems." :-(

> (The typos could be added to this patch, it should be the smaller)


Got it.

> 2) Intel C compiler
>
> The cpuid on 64 bit should be look like this:
>
> #if defined (__MSC_VER)
> #if _MSC_VER >= 1400
> __cpuid();
> #else
> #error An implementation of CPUID is required.
> #endif
> #elif GCC, IntelC etc.
> AT&T syntax with __asm__
> #endif


Why not provide an Intel-syntax equivalent of the AT&T assembly instead of
an error? There may be other 64-bit compilers that aren't handled by the
above cases.

> The ABI is the Application Binary Interface. It tells how a binary
> function calls another. Which registers are saved, which are not, how
> the arguments are passed (these are called calling conventions).
>
> On x86/32 many calling conventions are used. stdcall, ccall, fastcall.
> SLJIT supports two types: the stdcall and the GCC style fastcall (when
> SLJIT_X86_32_FASTCALL is defined), which is also used by msvc. E.g.
> borland C compiler uses another type of fastcall, but it supports MS
> style fast calls, so SLJIT_CALL is defined as __msfastcall, and
> SLJIT_X86_32_FASTCALL is defined as 1. (Fast call is usually faster than
> standard call, since it passes the first two arguments in ecx:edx).
> Thus, getting rid of __stdcall just cause crashes. You need to find
> which calling types are supported by ICC, and use either the standard or
> the GCC style fastcall type.


ICC supports at least cdecl and stdcall, according to

     http://software.intel.com/sites/products/documentation/studio/composer/en-us/2011Update/compiler_c/bldaps_cls/common/bldaps_calling_conv.htm


In what instances should __stdcall be used? At the very least, this
keyword appears to be Win32-specific, so it should probably not appear
outside the defined(_WIN32) cpp case.

Anyway, I still get segfaults on 32-bit (x86) Linux with the Intel
compiler whether I use stdcall or cdecl (but not as badly as fastcall).
Would it help if I provided you with built code from this compiler, so you
can see exactly what it's putting out?


--Daniel


--
Daniel Richard G. || danielg@??? || Software Developer
Teragram Linguistic Technologies (a division of SAS)
http://www.teragram.com/