2017-11-17 00:07:55 +00:00
|
|
|
// -*- mode: rust; -*-
|
|
|
|
|
//
|
|
|
|
|
// This file is part of curve25519-dalek.
|
2018-07-05 00:24:41 +00:00
|
|
|
// Copyright (c) 2016-2018 Isis Lovecruft, Henry de Valence
|
2017-11-17 00:07:55 +00:00
|
|
|
// See LICENSE for licensing information.
|
|
|
|
|
//
|
|
|
|
|
// Authors:
|
|
|
|
|
// - Isis Agora Lovecruft <isis@patternsinthevoid.net>
|
|
|
|
|
// - Henry de Valence <hdevalence@hdevalence.ca>
|
|
|
|
|
|
2018-01-26 02:00:27 +00:00
|
|
|
//! Pluggable implementations for different architectures.
|
2017-11-17 00:07:55 +00:00
|
|
|
//!
|
|
|
|
|
//! The naming of the `u32` and `u64` modules is somewhat unfortunate,
|
|
|
|
|
//! since these are also the names of primitive types. Since types have
|
|
|
|
|
//! a different namespace than modules, this isn't a problem to the
|
|
|
|
|
//! compiler, but it could cause confusion.
|
|
|
|
|
//!
|
|
|
|
|
//! However, it's unlikely that the names of those modules would be
|
|
|
|
|
//! brought into scope directly, instead of used as
|
|
|
|
|
//! `backend::u32::field` or similar. Unfortunately we can't use
|
|
|
|
|
//! `32bit` since identifiers can't start with letters, and the backends
|
|
|
|
|
//! do use `u32`/`u64`, so this seems like a least-bad option.
|
|
|
|
|
|
2018-07-20 21:43:31 +00:00
|
|
|
#[cfg(not(any(feature = "u32_backend", feature = "u64_backend", feature = "avx2_backend")))]
|
|
|
|
|
compile_error!(
|
|
|
|
|
"no curve25519-dalek backend cargo feature enabled! \
|
|
|
|
|
please enable one of: u32_backend, u64_backend, avx2_backend"
|
|
|
|
|
);
|
|
|
|
|
|
2018-05-15 00:35:34 +00:00
|
|
|
#[cfg(feature = "u32_backend")]
|
2017-11-17 00:07:55 +00:00
|
|
|
pub mod u32;
|
|
|
|
|
|
2018-05-15 00:35:34 +00:00
|
|
|
#[cfg(feature = "u64_backend")]
|
2017-11-17 00:07:55 +00:00
|
|
|
pub mod u64;
|
|
|
|
|
|
2018-06-18 20:30:45 +00:00
|
|
|
#[cfg(all(feature = "avx2_backend", target_feature = "avx2"))]
|
2017-11-17 21:25:38 +00:00
|
|
|
pub mod avx2;
|
|
|
|
|
|