[openssl-users] PerlASM for x64

[Richard Levitte]

In message <98f571de-f47e-6259-f1ac-792ebed3ed54 at wisemo.com> on Thu, 27 Dec 2018 10:12:34 +0100, Jakob Bohm <jb-openssl at wisemo.com> said:

> On 24/12/2018 19:08, Richard Levitte wrote:
> > In message <3fc4d543-d71a-8c22-566a-d902c4f7da03 at gmail.com> on Mon, 24
> > Dec 2018 13:17:51 +0100, Gisle Vanem <gisle.vanem at gmail.com> said:
> >
> >> Richard Levitte wrote:
> >>
> >>>> I experimented some more. I figured the "auto" does not work.
> >>>> But this works:
> >>>>     perl crypto\aes\asm\aesni-x86_64.pl nasm > tmp-file.s
> >>>>     diff tmp-file.s crypto\aes\aesni-x86_64.asm
> >>>>
> >>>> No diffs.
> >>>>
> >>>> Why does the the generation of .asm-files be so damn hard to
> >>>> figure out? Some cmd-line help to show what "auto" does would
> >>>> be nice.
> >>> The "auto" flavor takes note of the output file extension.  .asm vs .s
> >>> in this case.
> >> Thank, but it was a typo in my 1st email. The correct command was
> >> with a redirect:
> >>    set ASM=nasm
> >>    f:\util\StrawberryPerl\perl\bin\perl crypto\aes\asm\aesni-x86_64.pl
> >>    auto > tmp-file.s
> > That isn't a correct use of the script.  All of the assembler perl
> > scripts expect the output file as last argument, and the x86_64 ones
> > do look at the output file and determines that if the extension is
> > '.asm', nasm assembler is expected, otherwise you will get gas
> > assembler.  So if you redirect, the result is, mildly put, undefined.
> >
> > Thank you, though...  it is time the assembler stuff gets documented,
> > and I think I'm in a fairly good position to do so.  I will not
> > promise that it will happen fast, but it is in my backlog.
> As a trivial (and easily audited first patch) perhaps make the
> common code error out with a usage message to STDERR if the
> command line makes no sense (no output file, wrong argument
> count, auto with unrecognized file extension).  Ideally this
> would be in the common perl module(s), not in individual
> assembler files.

Ideas differ from one person to another, and there are ideas on
flexibility based on intimate knowledge of these modules that are
contrary to the more strict interpretation you desire.  Also, and
we've argued this back and forth quite a bit, there's the idea of the
modules being usable without dependence on other modules (apart from
the xlate module that they pipe to).

These modules have worked this way for quite a while (apart from
standardising on having the last argument be the output file at all
times, that actually varied between assembler modules before 1.1.0),
and while I agree with you that these modules are a bit too flexible
(please take note of this before thinking that I'm arguing against
you!), changing them need to be done carefully.

> Remember that keeping every patch easily audited by the wider
> community is essential to the trustworthiness of OpenSSL, the
> great reformatting a while back was a major mistake in this
> regard.

Regarding the great reformatting, this may be argued 'til hell freezes
over.  One of the things we considered was that the old source format
was arcane, didn't exist anywhere else, and wasn't even well supported
by the project team members (there was code inserted in more common
formats, most often the usual 4 space indent BSD format).  The current
format has much better recognision and is easy to support in editors
and current formatters.  So as "mistake" goes, keeping the old source
code format could have been regarded as one just as much.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/