[PATCH] set mpi limb for all amd64 targets

Mike Frysinger vapier at gentoo.org
Mon Sep 17 20:31:30 CEST 2012


On Monday 17 September 2012 09:19:15 Werner Koch wrote:
> On Sat, 15 Sep 2012 02:30, vapier at gentoo.org said:
> > no idea what you mean.  all the mainline toolchain packages support it
> > now as does the kernel.
> 
> Search for x32 on LWN to see what I mean.  IIRC, the x32 ABI was
> specified by Intel for use on certain embedded systems.

no, not really.  it works on any 64bit cpu since it just uses different types 
of sizes and generates slightly different instructions (to use 32bit regs 
rather than 64bit regs).  it was designed to shrink bloat since the vast 
majority of applications out there don't need more than 4GiB of RAM.  yes, 
this ends up improving performance on embedded systems and making the part 
more competitive against ARM, but a good number (maybe even a majority) of 
laptops today don't have more than 4GiB of RAM either.

although if you're dismissive of "embedded systems", i guess you're also 
dismissive of ARM too ?

> It is questionable there are any benefits for standard 84 bit CPUs.

guess you mean 64bit.  all x86 64bit intel/amd64 processors are "standard" and 
can run the x32 ABI.

> > it doesn't have a unique one: x86_64-linux-gnu
> 
> Which defines the amd64 ABI and not the x32.

it doesn't specify just the amd64 ABI anymore.

> As I said it will likely work to define the
> MPI limb size to 64 bit instead of directly to "unsigned long".  However
> we are mixing two ABIs here which is not a good idea unless it can be
> proofed that there are no problems.

w/this patch, `make check` passes for both libgcrypt and gnupg.  no idea what 
you're looking for exactly ... i hate to state the obvious, but it is 
literally impossible to prove a negative.

> And as you reported there are problems mixing the two ABIs.

don't know what you're referring to here.  i'm not mixing them, i'm just 
running x32.

> What about using "./configure --disable-asm" as a workaround?

i'm not interested in workarounds.  if i was, i wouldn't be posting patches to 
*fix* the problem.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20120917/0af62b51/attachment.pgp>


More information about the Gcrypt-devel mailing list