Searched hist:q (Results 1 - 25 of 605) sorted by relevance

1234567891011>>

/src/usr.bin/make/unit-tests/
H A Dopt-query.exp1.4 Wed Aug 17 20:10:29 GMT 2022 rillig make: fix exit status for '-q' (since 1994)

1.3 Wed Aug 17 20:05:41 GMT 2022 rillig tests/make: demonstrate wrong exit status for '-q' (since 1994)

Reported by Jeroen Ruigrok van der Werven via private mail.

1.2 Wed Aug 19 05:13:18 GMT 2020 rillig make(1): add test for the -q option

H A Dopt-query.mk1.7 Thu Aug 18 05:37:05 GMT 2022 rillig tests/make: fix test for option '-q' in ATF mode

When running 'make test' in usr.bin/make, MAKE is set to '$PWD/make',
and when that file is used as a dependency, everything works as
expected.

When running the tests via ATF, MAKE is set to simply 'make', based on
argv[0]. Using 'make' as a dependency searches in the current directory
but not in /usr/bin, so the file is not found, which makes the
"up-to-date" target out of date.

Switch the dependeny from ${MAKE} to ${MAKEFILE}, as that file does not
involve any $PATH magic and is also guaranteed to be older than the
'up-to-date' file that is created while running the test.

1.6 Wed Aug 17 20:10:29 GMT 2022 rillig make: fix exit status for '-q' (since 1994)

1.5 Wed Aug 17 20:05:41 GMT 2022 rillig tests/make: demonstrate wrong exit status for '-q' (since 1994)

Reported by Jeroen Ruigrok van der Werven via private mail.

1.3 Wed Aug 19 05:13:18 GMT 2020 rillig make(1): add test for the -q option

/src/bin/ksh/
H A Demacs-gen.sh1.4 Sat Oct 25 22:18:15 GMT 2008 apb branches: 1.4.62;
In shell scripts run during the build, add a SED variable, defaulting
to "sed". SED=${TOOL_SED:Q} should be passed in the environment to
override this.

1.3 Sun Oct 19 22:10:04 GMT 2008 apb In shell scripts invoked during a build, and in crunchgen, use ${AWK}
instead of plain "awk". The Makefiles that invoke these scripts
or programs will pass AWK=${HOST_AWK:Q}.

H A Dmkman1.3 Sun Oct 19 22:10:04 GMT 2008 apb branches: 1.3.62;
In shell scripts invoked during a build, and in crunchgen, use ${AWK}
instead of plain "awk". The Makefiles that invoke these scripts
or programs will pass AWK=${HOST_AWK:Q}.

/src/sys/dev/usb/
H A Dauvitek_board.c1.2 Tue Dec 28 04:02:33 GMT 2010 jmcneill branches: 1.2.6;
Hauppauge HVR-850 analog should be identical to HVR-950Q, so support it too
1.1 Mon Dec 27 15:42:11 GMT 2010 jmcneill add driver for the Auvitek AU0828 USB video controllers's analog video
capture functions:

auvitek0 at uhub6 port 2: AU0828
video0 at auvitek0: WinTV HVR-950Q
uaudio0 at auvitek0 port 2 configuration 1 interface 1
uaudio0: vendor 0x2040 product 0x7200, rev 2.00/0.05, addr 2
uaudio0: audio rev 1.00
audio1 at uaudio0: full duplex, playback, capture, independent
H A Dauvitekreg.h1.1 Mon Dec 27 15:42:11 GMT 2010 jmcneill branches: 1.1.6;
add driver for the Auvitek AU0828 USB video controllers's analog video
capture functions:

auvitek0 at uhub6 port 2: AU0828
video0 at auvitek0: WinTV HVR-950Q
uaudio0 at auvitek0 port 2 configuration 1 interface 1
uaudio0: vendor 0x2040 product 0x7200, rev 2.00/0.05, addr 2
uaudio0: audio rev 1.00
audio1 at uaudio0: full duplex, playback, capture, independent

/src/sys/lib/libgnuefi/
H A DMakefile.inc1.5 Sun May 27 01:14:50 GMT 2018 christos - Introduce :q modifier for make variables and make it double escape $'s so
that passing variables to recursive makes with :q works as expected.
- Revert :Q to work as before.
- Adjust makefiles that use recursive make to use :q

Discussed on tech-toolchain@
XXX: pullup 8

1.5 Sun May 27 01:14:50 GMT 2018 christos - Introduce :q modifier for make variables and make it double escape $'s so
that passing variables to recursive makes with :q works as expected.
- Revert :Q to work as before.
- Adjust makefiles that use recursive make to use :q

Discussed on tech-toolchain@
XXX: pullup 8

1.5 Sun May 27 01:14:50 GMT 2018 christos - Introduce :q modifier for make variables and make it double escape $'s so
that passing variables to recursive makes with :q works as expected.
- Revert :Q to work as before.
- Adjust makefiles that use recursive make to use :q

Discussed on tech-toolchain@
XXX: pullup 8

1.5 Sun May 27 01:14:50 GMT 2018 christos - Introduce :q modifier for make variables and make it double escape $'s so
that passing variables to recursive makes with :q works as expected.
- Revert :Q to work as before.
- Adjust makefiles that use recursive make to use :q

Discussed on tech-toolchain@
XXX: pullup 8

/src/sys/arch/acorn32/stand/lib/
H A DMakefile.inc1.4 Sun May 27 01:14:50 GMT 2018 christos - Introduce :q modifier for make variables and make it double escape $'s so
that passing variables to recursive makes with :q works as expected.
- Revert :Q to work as before.
- Adjust makefiles that use recursive make to use :q

Discussed on tech-toolchain@
XXX: pullup 8

1.4 Sun May 27 01:14:50 GMT 2018 christos - Introduce :q modifier for make variables and make it double escape $'s so
that passing variables to recursive makes with :q works as expected.
- Revert :Q to work as before.
- Adjust makefiles that use recursive make to use :q

Discussed on tech-toolchain@
XXX: pullup 8

1.4 Sun May 27 01:14:50 GMT 2018 christos - Introduce :q modifier for make variables and make it double escape $'s so
that passing variables to recursive makes with :q works as expected.
- Revert :Q to work as before.
- Adjust makefiles that use recursive make to use :q

Discussed on tech-toolchain@
XXX: pullup 8

1.4 Sun May 27 01:14:50 GMT 2018 christos - Introduce :q modifier for make variables and make it double escape $'s so
that passing variables to recursive makes with :q works as expected.
- Revert :Q to work as before.
- Adjust makefiles that use recursive make to use :q

Discussed on tech-toolchain@
XXX: pullup 8

/src/sys/dev/pcmcia/
H A DMakefile.pcmciadevs1.2 Sun Oct 19 22:05:23 GMT 2008 apb Use ${TOOL_AWK} instead of ${AWK} or plain "awk" in make commands.
Pass AWK=${TOOL_AWK:Q} to shell scripts that use awk.
/src/sys/dev/podulebus/
H A DMakefile.podules1.2 Sun Oct 19 22:05:23 GMT 2008 apb Use ${TOOL_AWK} instead of ${AWK} or plain "awk" in make commands.
Pass AWK=${TOOL_AWK:Q} to shell scripts that use awk.

/src/sys/dev/videomode/
H A DMakefile.videomode1.2 Sun Oct 19 22:05:23 GMT 2008 apb Use ${TOOL_AWK} instead of ${AWK} or plain "awk" in make commands.
Pass AWK=${TOOL_AWK:Q} to shell scripts that use awk.

/src/sys/arch/hppa/spmath/
H A DMakefile.inc1.10 Sun May 27 01:14:50 GMT 2018 christos - Introduce :q modifier for make variables and make it double escape $'s so
that passing variables to recursive makes with :q works as expected.
- Revert :Q to work as before.
- Adjust makefiles that use recursive make to use :q

Discussed on tech-toolchain@
XXX: pullup 8

1.10 Sun May 27 01:14:50 GMT 2018 christos - Introduce :q modifier for make variables and make it double escape $'s so
that passing variables to recursive makes with :q works as expected.
- Revert :Q to work as before.
- Adjust makefiles that use recursive make to use :q

Discussed on tech-toolchain@
XXX: pullup 8

1.10 Sun May 27 01:14:50 GMT 2018 christos - Introduce :q modifier for make variables and make it double escape $'s so
that passing variables to recursive makes with :q works as expected.
- Revert :Q to work as before.
- Adjust makefiles that use recursive make to use :q

Discussed on tech-toolchain@
XXX: pullup 8

1.10 Sun May 27 01:14:50 GMT 2018 christos - Introduce :q modifier for make variables and make it double escape $'s so
that passing variables to recursive makes with :q works as expected.
- Revert :Q to work as before.
- Adjust makefiles that use recursive make to use :q

Discussed on tech-toolchain@
XXX: pullup 8

1.8 Mon Jan 25 18:55:25 GMT 2016 christos use :Q to quote variables properly.

/src/sys/crypto/aes/arch/x86/
H A Dfiles.aessse21.1 Mon Jun 29 23:47:54 GMT 2020 riastradh New SSE2-based bitsliced AES implementation.

This should work on essentially all x86 CPUs of the last two decades,
and may improve throughput over the portable C aes_ct implementation
from BearSSL by

(a) reducing the number of vector operations in sequence, and
(b) batching four rather than two blocks in parallel.

Derived from BearSSL'S aes_ct64 implementation adjusted so that where
aes_ct64 uses 64-bit q[0],...,q[7], aes_sse2 uses (q[0], q[4]), ...,
(q[3], q[7]), each tuple representing a pair of 64-bit quantities
stacked in a single 128-bit register. This translation was done very
naively, and mostly reduces the cost of ShiftRows and data movement
without doing anything to address the S-box or (Inv)MixColumns, which
spread all 64-bit quantities across separate registers and ignore the
upper halves.

Unfortunately, SSE2 -- which is all that is guaranteed on all amd64
CPUs -- doesn't have PSHUFB, which would help out a lot more. For
example, vpaes relies on that. Perhaps there are enough CPUs out
there with PSHUFB but not AES-NI to make it worthwhile to import or
adapt vpaes too.

Note: This includes local definitions of various Intel compiler
intrinsics for gcc and clang in terms of their __builtin_* &c.,
because the necessary header files are not available during the
kernel build. This is a kludge -- we should fix it properly; the
present approach is expedient but not ideal.

1.1 Mon Jun 29 23:47:54 GMT 2020 riastradh New SSE2-based bitsliced AES implementation.

This should work on essentially all x86 CPUs of the last two decades,
and may improve throughput over the portable C aes_ct implementation
from BearSSL by

(a) reducing the number of vector operations in sequence, and
(b) batching four rather than two blocks in parallel.

Derived from BearSSL'S aes_ct64 implementation adjusted so that where
aes_ct64 uses 64-bit q[0],...,q[7], aes_sse2 uses (q[0], q[4]), ...,
(q[3], q[7]), each tuple representing a pair of 64-bit quantities
stacked in a single 128-bit register. This translation was done very
naively, and mostly reduces the cost of ShiftRows and data movement
without doing anything to address the S-box or (Inv)MixColumns, which
spread all 64-bit quantities across separate registers and ignore the
upper halves.

Unfortunately, SSE2 -- which is all that is guaranteed on all amd64
CPUs -- doesn't have PSHUFB, which would help out a lot more. For
example, vpaes relies on that. Perhaps there are enough CPUs out
there with PSHUFB but not AES-NI to make it worthwhile to import or
adapt vpaes too.

Note: This includes local definitions of various Intel compiler
intrinsics for gcc and clang in terms of their __builtin_* &c.,
because the necessary header files are not available during the
kernel build. This is a kludge -- we should fix it properly; the
present approach is expedient but not ideal.

1.1 Mon Jun 29 23:47:54 GMT 2020 riastradh New SSE2-based bitsliced AES implementation.

This should work on essentially all x86 CPUs of the last two decades,
and may improve throughput over the portable C aes_ct implementation
from BearSSL by

(a) reducing the number of vector operations in sequence, and
(b) batching four rather than two blocks in parallel.

Derived from BearSSL'S aes_ct64 implementation adjusted so that where
aes_ct64 uses 64-bit q[0],...,q[7], aes_sse2 uses (q[0], q[4]), ...,
(q[3], q[7]), each tuple representing a pair of 64-bit quantities
stacked in a single 128-bit register. This translation was done very
naively, and mostly reduces the cost of ShiftRows and data movement
without doing anything to address the S-box or (Inv)MixColumns, which
spread all 64-bit quantities across separate registers and ignore the
upper halves.

Unfortunately, SSE2 -- which is all that is guaranteed on all amd64
CPUs -- doesn't have PSHUFB, which would help out a lot more. For
example, vpaes relies on that. Perhaps there are enough CPUs out
there with PSHUFB but not AES-NI to make it worthwhile to import or
adapt vpaes too.

Note: This includes local definitions of various Intel compiler
intrinsics for gcc and clang in terms of their __builtin_* &c.,
because the necessary header files are not available during the
kernel build. This is a kludge -- we should fix it properly; the
present approach is expedient but not ideal.

1.1 Mon Jun 29 23:47:54 GMT 2020 riastradh New SSE2-based bitsliced AES implementation.

This should work on essentially all x86 CPUs of the last two decades,
and may improve throughput over the portable C aes_ct implementation
from BearSSL by

(a) reducing the number of vector operations in sequence, and
(b) batching four rather than two blocks in parallel.

Derived from BearSSL'S aes_ct64 implementation adjusted so that where
aes_ct64 uses 64-bit q[0],...,q[7], aes_sse2 uses (q[0], q[4]), ...,
(q[3], q[7]), each tuple representing a pair of 64-bit quantities
stacked in a single 128-bit register. This translation was done very
naively, and mostly reduces the cost of ShiftRows and data movement
without doing anything to address the S-box or (Inv)MixColumns, which
spread all 64-bit quantities across separate registers and ignore the
upper halves.

Unfortunately, SSE2 -- which is all that is guaranteed on all amd64
CPUs -- doesn't have PSHUFB, which would help out a lot more. For
example, vpaes relies on that. Perhaps there are enough CPUs out
there with PSHUFB but not AES-NI to make it worthwhile to import or
adapt vpaes too.

Note: This includes local definitions of various Intel compiler
intrinsics for gcc and clang in terms of their __builtin_* &c.,
because the necessary header files are not available during the
kernel build. This is a kludge -- we should fix it properly; the
present approach is expedient but not ideal.

1.1 Mon Jun 29 23:47:54 GMT 2020 riastradh New SSE2-based bitsliced AES implementation.

This should work on essentially all x86 CPUs of the last two decades,
and may improve throughput over the portable C aes_ct implementation
from BearSSL by

(a) reducing the number of vector operations in sequence, and
(b) batching four rather than two blocks in parallel.

Derived from BearSSL'S aes_ct64 implementation adjusted so that where
aes_ct64 uses 64-bit q[0],...,q[7], aes_sse2 uses (q[0], q[4]), ...,
(q[3], q[7]), each tuple representing a pair of 64-bit quantities
stacked in a single 128-bit register. This translation was done very
naively, and mostly reduces the cost of ShiftRows and data movement
without doing anything to address the S-box or (Inv)MixColumns, which
spread all 64-bit quantities across separate registers and ignore the
upper halves.

Unfortunately, SSE2 -- which is all that is guaranteed on all amd64
CPUs -- doesn't have PSHUFB, which would help out a lot more. For
example, vpaes relies on that. Perhaps there are enough CPUs out
there with PSHUFB but not AES-NI to make it worthwhile to import or
adapt vpaes too.

Note: This includes local definitions of various Intel compiler
intrinsics for gcc and clang in terms of their __builtin_* &c.,
because the necessary header files are not available during the
kernel build. This is a kludge -- we should fix it properly; the
present approach is expedient but not ideal.

1.1 Mon Jun 29 23:47:54 GMT 2020 riastradh New SSE2-based bitsliced AES implementation.

This should work on essentially all x86 CPUs of the last two decades,
and may improve throughput over the portable C aes_ct implementation
from BearSSL by

(a) reducing the number of vector operations in sequence, and
(b) batching four rather than two blocks in parallel.

Derived from BearSSL'S aes_ct64 implementation adjusted so that where
aes_ct64 uses 64-bit q[0],...,q[7], aes_sse2 uses (q[0], q[4]), ...,
(q[3], q[7]), each tuple representing a pair of 64-bit quantities
stacked in a single 128-bit register. This translation was done very
naively, and mostly reduces the cost of ShiftRows and data movement
without doing anything to address the S-box or (Inv)MixColumns, which
spread all 64-bit quantities across separate registers and ignore the
upper halves.

Unfortunately, SSE2 -- which is all that is guaranteed on all amd64
CPUs -- doesn't have PSHUFB, which would help out a lot more. For
example, vpaes relies on that. Perhaps there are enough CPUs out
there with PSHUFB but not AES-NI to make it worthwhile to import or
adapt vpaes too.

Note: This includes local definitions of various Intel compiler
intrinsics for gcc and clang in terms of their __builtin_* &c.,
because the necessary header files are not available during the
kernel build. This is a kludge -- we should fix it properly; the
present approach is expedient but not ideal.

/src/share/man/man8/man8.x68k/
H A Dloadbsd.81.7 Sat Dec 23 20:15:19 GMT 2023 andvar Update documentation with -q and -N options.

1.6 Sat Dec 23 19:13:55 GMT 2023 andvar Remove obsolete -d flag from documentation.

P.S. -q and -N flags need to be added.

/src/sys/dev/i2c/
H A Dau8522reg.h1.1 Mon Dec 27 15:42:11 GMT 2010 jmcneill branches: 1.1.6;
add driver for the Auvitek AU0828 USB video controllers's analog video
capture functions:

auvitek0 at uhub6 port 2: AU0828
video0 at auvitek0: WinTV HVR-950Q
uaudio0 at auvitek0 port 2 configuration 1 interface 1
uaudio0: vendor 0x2040 product 0x7200, rev 2.00/0.05, addr 2
uaudio0: audio rev 1.00
audio1 at uaudio0: full duplex, playback, capture, independent

H A Dxc5kreg.h1.1 Mon Dec 27 15:42:11 GMT 2010 jmcneill branches: 1.1.6;
add driver for the Auvitek AU0828 USB video controllers's analog video
capture functions:

auvitek0 at uhub6 port 2: AU0828
video0 at auvitek0: WinTV HVR-950Q
uaudio0 at auvitek0 port 2 configuration 1 interface 1
uaudio0: vendor 0x2040 product 0x7200, rev 2.00/0.05, addr 2
uaudio0: audio rev 1.00
audio1 at uaudio0: full duplex, playback, capture, independent

H A Dxc5kvar.h1.1 Mon Dec 27 15:42:11 GMT 2010 jmcneill branches: 1.1.6;
add driver for the Auvitek AU0828 USB video controllers's analog video
capture functions:

auvitek0 at uhub6 port 2: AU0828
video0 at auvitek0: WinTV HVR-950Q
uaudio0 at auvitek0 port 2 configuration 1 interface 1
uaudio0: vendor 0x2040 product 0x7200, rev 2.00/0.05, addr 2
uaudio0: audio rev 1.00
audio1 at uaudio0: full duplex, playback, capture, independent

H A Dau8522var.h1.1 Mon Dec 27 15:42:11 GMT 2010 jmcneill branches: 1.1.2; 1.1.6;
add driver for the Auvitek AU0828 USB video controllers's analog video
capture functions:

auvitek0 at uhub6 port 2: AU0828
video0 at auvitek0: WinTV HVR-950Q
uaudio0 at auvitek0 port 2 configuration 1 interface 1
uaudio0: vendor 0x2040 product 0x7200, rev 2.00/0.05, addr 2
uaudio0: audio rev 1.00
audio1 at uaudio0: full duplex, playback, capture, independent
/src/sys/dev/isapnp/
H A DMakefile.isapnpdevs1.2 Sun Oct 19 22:05:22 GMT 2008 apb Use ${TOOL_AWK} instead of ${AWK} or plain "awk" in make commands.
Pass AWK=${TOOL_AWK:Q} to shell scripts that use awk.
/src/sys/arch/ia64/stand/efi/libefi/
H A DMakefile.inc1.5 Sun May 27 01:14:50 GMT 2018 christos - Introduce :q modifier for make variables and make it double escape $'s so
that passing variables to recursive makes with :q works as expected.
- Revert :Q to work as before.
- Adjust makefiles that use recursive make to use :q

Discussed on tech-toolchain@
XXX: pullup 8

1.5 Sun May 27 01:14:50 GMT 2018 christos - Introduce :q modifier for make variables and make it double escape $'s so
that passing variables to recursive makes with :q works as expected.
- Revert :Q to work as before.
- Adjust makefiles that use recursive make to use :q

Discussed on tech-toolchain@
XXX: pullup 8

1.5 Sun May 27 01:14:50 GMT 2018 christos - Introduce :q modifier for make variables and make it double escape $'s so
that passing variables to recursive makes with :q works as expected.
- Revert :Q to work as before.
- Adjust makefiles that use recursive make to use :q

Discussed on tech-toolchain@
XXX: pullup 8

1.5 Sun May 27 01:14:50 GMT 2018 christos - Introduce :q modifier for make variables and make it double escape $'s so
that passing variables to recursive makes with :q works as expected.
- Revert :Q to work as before.
- Adjust makefiles that use recursive make to use :q

Discussed on tech-toolchain@
XXX: pullup 8

/src/share/man/man3/
H A D__alignof__.31.5 Thu Apr 14 06:56:28 GMT 2011 wiz No need to use \*[q], use plain double quotes instead.

H A Doffsetof.31.5 Thu Apr 14 06:56:28 GMT 2011 wiz No need to use \*[q], use plain double quotes instead.

/src/sys/dev/mca/
H A DMakefile.mcadevs1.2 Sun Oct 19 22:05:22 GMT 2008 apb Use ${TOOL_AWK} instead of ${AWK} or plain "awk" in make commands.
Pass AWK=${TOOL_AWK:Q} to shell scripts that use awk.

/src/sys/crypto/aes/
H A Daes.h1.2 Mon Jun 29 23:47:54 GMT 2020 riastradh New SSE2-based bitsliced AES implementation.

This should work on essentially all x86 CPUs of the last two decades,
and may improve throughput over the portable C aes_ct implementation
from BearSSL by

(a) reducing the number of vector operations in sequence, and
(b) batching four rather than two blocks in parallel.

Derived from BearSSL'S aes_ct64 implementation adjusted so that where
aes_ct64 uses 64-bit q[0],...,q[7], aes_sse2 uses (q[0], q[4]), ...,
(q[3], q[7]), each tuple representing a pair of 64-bit quantities
stacked in a single 128-bit register. This translation was done very
naively, and mostly reduces the cost of ShiftRows and data movement
without doing anything to address the S-box or (Inv)MixColumns, which
spread all 64-bit quantities across separate registers and ignore the
upper halves.

Unfortunately, SSE2 -- which is all that is guaranteed on all amd64
CPUs -- doesn't have PSHUFB, which would help out a lot more. For
example, vpaes relies on that. Perhaps there are enough CPUs out
there with PSHUFB but not AES-NI to make it worthwhile to import or
adapt vpaes too.

Note: This includes local definitions of various Intel compiler
intrinsics for gcc and clang in terms of their __builtin_* &c.,
because the necessary header files are not available during the
kernel build. This is a kludge -- we should fix it properly; the
present approach is expedient but not ideal.

1.2 Mon Jun 29 23:47:54 GMT 2020 riastradh New SSE2-based bitsliced AES implementation.

This should work on essentially all x86 CPUs of the last two decades,
and may improve throughput over the portable C aes_ct implementation
from BearSSL by

(a) reducing the number of vector operations in sequence, and
(b) batching four rather than two blocks in parallel.

Derived from BearSSL'S aes_ct64 implementation adjusted so that where
aes_ct64 uses 64-bit q[0],...,q[7], aes_sse2 uses (q[0], q[4]), ...,
(q[3], q[7]), each tuple representing a pair of 64-bit quantities
stacked in a single 128-bit register. This translation was done very
naively, and mostly reduces the cost of ShiftRows and data movement
without doing anything to address the S-box or (Inv)MixColumns, which
spread all 64-bit quantities across separate registers and ignore the
upper halves.

Unfortunately, SSE2 -- which is all that is guaranteed on all amd64
CPUs -- doesn't have PSHUFB, which would help out a lot more. For
example, vpaes relies on that. Perhaps there are enough CPUs out
there with PSHUFB but not AES-NI to make it worthwhile to import or
adapt vpaes too.

Note: This includes local definitions of various Intel compiler
intrinsics for gcc and clang in terms of their __builtin_* &c.,
because the necessary header files are not available during the
kernel build. This is a kludge -- we should fix it properly; the
present approach is expedient but not ideal.

1.2 Mon Jun 29 23:47:54 GMT 2020 riastradh New SSE2-based bitsliced AES implementation.

This should work on essentially all x86 CPUs of the last two decades,
and may improve throughput over the portable C aes_ct implementation
from BearSSL by

(a) reducing the number of vector operations in sequence, and
(b) batching four rather than two blocks in parallel.

Derived from BearSSL'S aes_ct64 implementation adjusted so that where
aes_ct64 uses 64-bit q[0],...,q[7], aes_sse2 uses (q[0], q[4]), ...,
(q[3], q[7]), each tuple representing a pair of 64-bit quantities
stacked in a single 128-bit register. This translation was done very
naively, and mostly reduces the cost of ShiftRows and data movement
without doing anything to address the S-box or (Inv)MixColumns, which
spread all 64-bit quantities across separate registers and ignore the
upper halves.

Unfortunately, SSE2 -- which is all that is guaranteed on all amd64
CPUs -- doesn't have PSHUFB, which would help out a lot more. For
example, vpaes relies on that. Perhaps there are enough CPUs out
there with PSHUFB but not AES-NI to make it worthwhile to import or
adapt vpaes too.

Note: This includes local definitions of various Intel compiler
intrinsics for gcc and clang in terms of their __builtin_* &c.,
because the necessary header files are not available during the
kernel build. This is a kludge -- we should fix it properly; the
present approach is expedient but not ideal.

1.2 Mon Jun 29 23:47:54 GMT 2020 riastradh New SSE2-based bitsliced AES implementation.

This should work on essentially all x86 CPUs of the last two decades,
and may improve throughput over the portable C aes_ct implementation
from BearSSL by

(a) reducing the number of vector operations in sequence, and
(b) batching four rather than two blocks in parallel.

Derived from BearSSL'S aes_ct64 implementation adjusted so that where
aes_ct64 uses 64-bit q[0],...,q[7], aes_sse2 uses (q[0], q[4]), ...,
(q[3], q[7]), each tuple representing a pair of 64-bit quantities
stacked in a single 128-bit register. This translation was done very
naively, and mostly reduces the cost of ShiftRows and data movement
without doing anything to address the S-box or (Inv)MixColumns, which
spread all 64-bit quantities across separate registers and ignore the
upper halves.

Unfortunately, SSE2 -- which is all that is guaranteed on all amd64
CPUs -- doesn't have PSHUFB, which would help out a lot more. For
example, vpaes relies on that. Perhaps there are enough CPUs out
there with PSHUFB but not AES-NI to make it worthwhile to import or
adapt vpaes too.

Note: This includes local definitions of various Intel compiler
intrinsics for gcc and clang in terms of their __builtin_* &c.,
because the necessary header files are not available during the
kernel build. This is a kludge -- we should fix it properly; the
present approach is expedient but not ideal.

1.2 Mon Jun 29 23:47:54 GMT 2020 riastradh New SSE2-based bitsliced AES implementation.

This should work on essentially all x86 CPUs of the last two decades,
and may improve throughput over the portable C aes_ct implementation
from BearSSL by

(a) reducing the number of vector operations in sequence, and
(b) batching four rather than two blocks in parallel.

Derived from BearSSL'S aes_ct64 implementation adjusted so that where
aes_ct64 uses 64-bit q[0],...,q[7], aes_sse2 uses (q[0], q[4]), ...,
(q[3], q[7]), each tuple representing a pair of 64-bit quantities
stacked in a single 128-bit register. This translation was done very
naively, and mostly reduces the cost of ShiftRows and data movement
without doing anything to address the S-box or (Inv)MixColumns, which
spread all 64-bit quantities across separate registers and ignore the
upper halves.

Unfortunately, SSE2 -- which is all that is guaranteed on all amd64
CPUs -- doesn't have PSHUFB, which would help out a lot more. For
example, vpaes relies on that. Perhaps there are enough CPUs out
there with PSHUFB but not AES-NI to make it worthwhile to import or
adapt vpaes too.

Note: This includes local definitions of various Intel compiler
intrinsics for gcc and clang in terms of their __builtin_* &c.,
because the necessary header files are not available during the
kernel build. This is a kludge -- we should fix it properly; the
present approach is expedient but not ideal.

1.2 Mon Jun 29 23:47:54 GMT 2020 riastradh New SSE2-based bitsliced AES implementation.

This should work on essentially all x86 CPUs of the last two decades,
and may improve throughput over the portable C aes_ct implementation
from BearSSL by

(a) reducing the number of vector operations in sequence, and
(b) batching four rather than two blocks in parallel.

Derived from BearSSL'S aes_ct64 implementation adjusted so that where
aes_ct64 uses 64-bit q[0],...,q[7], aes_sse2 uses (q[0], q[4]), ...,
(q[3], q[7]), each tuple representing a pair of 64-bit quantities
stacked in a single 128-bit register. This translation was done very
naively, and mostly reduces the cost of ShiftRows and data movement
without doing anything to address the S-box or (Inv)MixColumns, which
spread all 64-bit quantities across separate registers and ignore the
upper halves.

Unfortunately, SSE2 -- which is all that is guaranteed on all amd64
CPUs -- doesn't have PSHUFB, which would help out a lot more. For
example, vpaes relies on that. Perhaps there are enough CPUs out
there with PSHUFB but not AES-NI to make it worthwhile to import or
adapt vpaes too.

Note: This includes local definitions of various Intel compiler
intrinsics for gcc and clang in terms of their __builtin_* &c.,
because the necessary header files are not available during the
kernel build. This is a kludge -- we should fix it properly; the
present approach is expedient but not ideal.

/src/sys/arch/atari/stand/tostools/aptck/
H A DMakefile1.4 Sun Oct 19 22:05:21 GMT 2008 apb Use ${TOOL_AWK} instead of ${AWK} or plain "awk" in make commands.
Pass AWK=${TOOL_AWK:Q} to shell scripts that use awk.

Completed in 63 milliseconds

1234567891011>>