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
next prev parent 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: linkBe 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.