[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <02e901cd5d08$43089590$c919c0b0$@net>
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.
