Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 8 Jul 2012 07:50:32 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: ARCH_ALLOWS_UNALIGNED in generic build (was: Build error for generic)

>From: Solar Designer [mailto:solar@...nwall.com]
>
>> #if defined(i386) || defined(__i386__) || defined(__i486__) || \
>> 	defined(__i586__) || defined(__i686__) || defined(__pentium__) ||
>\
>> 	defined(__pentiumpro__) || defined(__pentium4__) || \
>> 	defined(__nocona__) || defined(prescott) || defined(__core2__) ||
>\
>> 	defined(__k6__) || defined(__k8__) || defined(__athlon__) || \
>> 	defined(__amd64) || defined(__amd64__) || \
>> 	defined(__x86_64) || defined(__x86_64__) || defined(_M_IX86) || \
>> 	defined(_M_AMD64) || defined(_M_IA64) || defined(_M_X64) #define
>> ARCH_ALLOWS_UNALIGNED 1 #else #define ARCH_ALLOWS_UNALIGNED 0 #endif
>
>I agree that we should add a check like this to detect.c or to the arch.h
that it outputs.  I find the above set of checks excessive, though -
wouldn't it be sufficient to >check for defined(__i386__) ||
defined(__x86_64__)?  I think one of these is implied by all others.
>For example, when compiling for i686, __i386__ is also defined.

The code block above was taken from the gost.h file.  I do not know all of
the compilers tested. I was not sure if __i386__ would always be defined,
under all builds, for all compilers.  If a smaller check is known to be
adequate, and covering all compilers (I am pretty sure the _M_* have to be
tossed in to get VC).

I think your __i386__ || __x86_64__ may be adequate for most newer gcc, but
I do not think it is overall adequate.  What about x86-solaris?  ICC?
Clang?  VC?   Since it is all 100% pre compiler code, it impacts runtime not
in the least.

NOTE, in gost.h  (and soon to be in jtrswap.h) that above 'mess' boils down
to setting this:

#define CPU_X64  or #define CPU_IA32.   In johnswap, there will also always
be a #define CPU_INTEL_LE  defined.

Once that is done, the CPU_IA32  (or 64) can be used stand alone, as well as
CPU_INTEL_LE

>In md4.c and md5.c, we have:
>
>#if defined(__i386__) || defined(__x86_64__) || defined(__vax__)

Ah-ha. That explains some of the slowdown I get on a VC build. Inadequate
#defines, causing sub optimal execution paths.

>for the same purpose (these files were written outside of JtR initially,
which is why they do not use JtR's ARCH_ALLOWS_UNALIGNED).  I think we
should reuse this same check.
>
>Eventually, we'll also need to add a check for x32, or maybe we can do it
already (need to find out the proper define).

What would be nice, is to have a big fat catch all block (like above) in a
very common header (included by all), then ALL checking for an Intel LE
format is done with 1 or 2 JtR 'controlled' name enumerations (along with
VAX if it is LE, and any other LE)

Jim.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.