All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>,
	Kees Cook <keescook@chromium.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Paul Mackerras <paulus@samba.org>,
	linux-hardening@vger.kernel.org,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Subject: Re: mainline build failure of powerpc allmodconfig for prom_init_check
Date: Mon, 18 Jul 2022 15:55:51 -0700	[thread overview]
Message-ID: <CAHk-=wjWez4jFa1sbkhMqGktFPDMvd3kojibwFyTkGOL2xrp5w@mail.gmail.com> (raw)
In-Reply-To: <20220718220839.GF25951@gate.crashing.org>

On Mon, Jul 18, 2022 at 3:12 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> Assembler language is unforgiving.  It isn't easy to write, and most
> mistakes will not be diagnosed.  If the assmbler language makes it
> easier to read the code, that makes it more likely correct code will be
> written, and that correct code will be written in less time.

What's your argument? That it's unforgiving, so it has to be
unreadable and easy to make mistakes in too?

You can get the order of operands wrong, and it will still build -
just to completely the wrong thing.

> > Oddities, yes ("$" as a prefix for register? Alpha asm is also very
> > odd), but nothing *quite* as broken as "simple constants have entirely
> > different meanings depending on the exact instruction and argument
> > position".
>
> What is broken about that?  It makes everything very consistent, and
> very readable.  Sigils are just nasty, and having the register names the
> same as valid symbol names is also problematic.

Oh, I agree that sigils are good to make the type clear. So '%r4' is
better than 'r4' because the latter could be ambiguous and you could
have a symbol 'r4'.

But just '4' is plain garbage.  There's no "could be ambiguous" about it.

Type checking matters. Not just in C. In asm too.

The reason '$0' is odd because it's *just* a sigil and a number.

Which certainly is not unusual in itself, but it reads like it's a
number to me. Not just because of x86 gas ('$' means 'immediate'), but
Z80 ('$' means HEX), or at least 'Nth argument' (shell).

And yeah, alpha got it from MIPS, afaik.

And presumably MIPS got it from "we're hacking up the simplest
assembler we can".

> > The human-written asm files have those #define's in headers just to
> > make things slightly more legible, because apparently the assembler
> > doesn't even *accept* the sane names.
>
> That was true a long time ago.  And the "#define r0 0" thing caused
> quite a few bugs itself btw.

Those #define's still exist. Look it up.

And yes, they are horrible, and they are wrong, and they shouldn't exist.

               Linus

WARNING: multiple messages have this Message-ID (diff)
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Kees Cook <keescook@chromium.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Paul Mackerras <paulus@samba.org>,
	linux-hardening@vger.kernel.org,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Subject: Re: mainline build failure of powerpc allmodconfig for prom_init_check
Date: Mon, 18 Jul 2022 15:55:51 -0700	[thread overview]
Message-ID: <CAHk-=wjWez4jFa1sbkhMqGktFPDMvd3kojibwFyTkGOL2xrp5w@mail.gmail.com> (raw)
In-Reply-To: <20220718220839.GF25951@gate.crashing.org>

On Mon, Jul 18, 2022 at 3:12 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> Assembler language is unforgiving.  It isn't easy to write, and most
> mistakes will not be diagnosed.  If the assmbler language makes it
> easier to read the code, that makes it more likely correct code will be
> written, and that correct code will be written in less time.

What's your argument? That it's unforgiving, so it has to be
unreadable and easy to make mistakes in too?

You can get the order of operands wrong, and it will still build -
just to completely the wrong thing.

> > Oddities, yes ("$" as a prefix for register? Alpha asm is also very
> > odd), but nothing *quite* as broken as "simple constants have entirely
> > different meanings depending on the exact instruction and argument
> > position".
>
> What is broken about that?  It makes everything very consistent, and
> very readable.  Sigils are just nasty, and having the register names the
> same as valid symbol names is also problematic.

Oh, I agree that sigils are good to make the type clear. So '%r4' is
better than 'r4' because the latter could be ambiguous and you could
have a symbol 'r4'.

But just '4' is plain garbage.  There's no "could be ambiguous" about it.

Type checking matters. Not just in C. In asm too.

The reason '$0' is odd because it's *just* a sigil and a number.

Which certainly is not unusual in itself, but it reads like it's a
number to me. Not just because of x86 gas ('$' means 'immediate'), but
Z80 ('$' means HEX), or at least 'Nth argument' (shell).

And yeah, alpha got it from MIPS, afaik.

And presumably MIPS got it from "we're hacking up the simplest
assembler we can".

> > The human-written asm files have those #define's in headers just to
> > make things slightly more legible, because apparently the assembler
> > doesn't even *accept* the sane names.
>
> That was true a long time ago.  And the "#define r0 0" thing caused
> quite a few bugs itself btw.

Those #define's still exist. Look it up.

And yes, they are horrible, and they are wrong, and they shouldn't exist.

               Linus

  reply	other threads:[~2022-07-18 22:56 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-14  8:55 mainline build failure of powerpc allmodconfig for prom_init_check Sudip Mukherjee (Codethink)
2022-07-14  8:55 ` Sudip Mukherjee (Codethink)
2022-07-17  9:12 ` Sudip Mukherjee
2022-07-17  9:12   ` Sudip Mukherjee
2022-07-17 14:44   ` Linus Torvalds
2022-07-17 14:44     ` Linus Torvalds
2022-07-17 19:54     ` Segher Boessenkool
2022-07-17 19:54       ` Segher Boessenkool
2022-07-18  3:52       ` Michael Ellerman
2022-07-18  3:52         ` Michael Ellerman
2022-07-18 14:56         ` Segher Boessenkool
2022-07-18 14:56           ` Segher Boessenkool
2022-07-17 20:25     ` Sudip Mukherjee
2022-07-17 20:25       ` Sudip Mukherjee
2022-07-17 20:29       ` Linus Torvalds
2022-07-17 20:29         ` Linus Torvalds
2022-07-17 20:38         ` Sudip Mukherjee
2022-07-17 20:38           ` Sudip Mukherjee
2022-07-17 20:56           ` Linus Torvalds
2022-07-17 20:56             ` Linus Torvalds
2022-07-17 20:56         ` Segher Boessenkool
2022-07-17 20:56           ` Segher Boessenkool
2022-07-17 21:11           ` Linus Torvalds
2022-07-17 21:11             ` Linus Torvalds
2022-07-17 21:45             ` Segher Boessenkool
2022-07-17 21:45               ` Segher Boessenkool
2022-07-18  1:38               ` Linus Torvalds
2022-07-18  1:38                 ` Linus Torvalds
2022-07-18  4:41   ` Michael Ellerman
2022-07-18  4:41     ` Michael Ellerman
2022-07-18  7:51     ` David Laight
2022-07-18  7:51       ` David Laight
2022-07-18 13:44     ` [PATCH] powerpc/64s: Disable stack variable initialisation for prom_init Michael Ellerman
2022-07-18 13:44       ` Michael Ellerman
2022-07-18 15:03       ` Sudip Mukherjee
2022-07-18 15:03         ` Sudip Mukherjee
2022-07-18 18:34       ` Linus Torvalds
2022-07-18 18:34         ` Linus Torvalds
2022-07-27 12:02       ` Michael Ellerman
2022-07-18 19:06     ` mainline build failure of powerpc allmodconfig for prom_init_check Linus Torvalds
2022-07-18 19:06       ` Linus Torvalds
2022-07-18 22:08       ` Segher Boessenkool
2022-07-18 22:08         ` Segher Boessenkool
2022-07-18 22:55         ` Linus Torvalds [this message]
2022-07-18 22:55           ` Linus Torvalds
2022-07-19 13:35       ` Michael Ellerman
2022-07-19 13:35         ` Michael Ellerman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHk-=wjWez4jFa1sbkhMqGktFPDMvd3kojibwFyTkGOL2xrp5w@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=keescook@chromium.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    --cc=segher@kernel.crashing.org \
    --cc=sudipm.mukherjee@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.