From: "Ihar 'Philips' Filipau" <filia@softhome.net>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: nasm over gas?
Date: Mon, 08 Sep 2003 14:03:21 +0200 [thread overview]
Message-ID: <3F5C7009.4030004@softhome.net> (raw)
In-Reply-To: <tcVB.rs.3@gated-at.bofh.it>
Eric W. Biederman wrote:
> insecure <insecure@mail.od.ua> writes:
>> movl $0, 20(%esp)
>> movl $1000000, %edi <----
>> movl $1000000, 16(%esp) <----
>> movl $0, 12(%esp)
>>
>>No sane human will do that.
>>main:
>> movl $1000000, %edi
>> movl %edi, 16(%esp) <-- save 4 bytes
>> movl %ebp, 12(%esp) <-- save 4 bytes
>> movl $.LC27, 8(%esp)
>>
>>And this is only from a cursory examination.
>
> Actually it is no as simple as that. With the instruction that uses
> %edi following immediately after the instruction that populates it you cannot
> execute those two instructions in parallel. So the code may be slower. The
> exact rules depend on the architecture of the cpu.
>
It will depend on arch CPU only in case if you have unlimited i$ size.
Servers with 8MB of cache - yes it is faster.
Celeron with 128k of cache - +4bytes == higher probability of i$ miss
== lower performance.
>
>>What gives you an impression that anyone is going to rewrite linux in asm?
>>I _only_ saying that compiler-generated asm is not 'good'. It's mediocre.
>>Nothing more. I am not asm zealot.
>
>
> I think I would agree with that statement most compiler-generated assembly
> code is mediocre in general. At the same time I would add most human
> generated assembly is poor, and a pain to maintain.
>
> If you concentrate on those handful of places where you need to
> optimize that is reasonable. Beyond that there simply are not the
> developer resources to do good assembly. And things like algorithmic
> transformations in assembly are an absolute nightmare. Where they are
> quite simple in C.
>
> And if the average generated code quality bothers you enough with C
> the compiler can be fixed, or another compiler can be written that
> does a better job, and the benefit applies to a lot more code.
>
e.g. C-- project: something like C, where you can operate with
registers just like another variables. Under DOS was producing .com
files witout any overhead: program with only 'int main() { return 0; }'
was optimized to one byte 'ret' ;-) But sure it was not complete C
implementation.
Sure I would prefere to have nasm used for kernel asm parts - but
obviously gas already became standard.
P.S. Add having good macroprocessor for assembler is a must: CPP is
terribly stupid by design. I beleive gas has no preprocessor comparable
to masm's one? I bet they are using C's cpp. This is degradation: macros
is the major feature of any translator I was working with. They can save
you a lot of time and make code much more cleaner/readable/mantainable.
CPP is just too dumb for asm...
Good old times, when people were responsible to _every_ byte of their
programmes... Yeh... Memory/programmers are cheap nowadays...
next parent reply other threads:[~2003-09-08 12:01 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <rZQN.83u.21@gated-at.bofh.it>
[not found] ` <saVL.7lR.1@gated-at.bofh.it>
[not found] ` <soFo.16a.1@gated-at.bofh.it>
[not found] ` <ssJa.6M6.25@gated-at.bofh.it>
[not found] ` <tcVB.rs.3@gated-at.bofh.it>
2003-09-08 12:03 ` Ihar 'Philips' Filipau [this message]
2003-09-08 13:53 ` nasm over gas? Richard B. Johnson
2003-09-08 16:10 ` Jamie Lokier
2003-09-08 16:17 ` Jamie Lokier
2003-09-08 16:45 ` Ihar 'Philips' Filipau
2003-09-08 16:58 ` Jamie Lokier
2003-09-08 17:59 ` William Lee Irwin III
[not found] ` <uw6d.3hD.35@gated-at.bofh.it>
[not found] ` <uxED.5Rz.9@gated-at.bofh.it>
[not found] ` <uYbM.26o.3@gated-at.bofh.it>
[not found] ` <uZUr.4QR.25@gated-at.bofh.it>
[not found] ` <v4qU.3h1.27@gated-at.bofh.it>
[not found] ` <vog2.7k4.23@gated-at.bofh.it>
2003-09-13 23:57 ` stack alignment in the kernel was " Andi Kleen
2003-09-14 13:54 ` Jamie Lokier
2003-09-14 14:13 ` Andi Kleen
2003-09-14 15:56 ` Jamie Lokier
2003-09-14 22:27 ` Jan Hubicka
[not found] <tt0q.6Rc.17@gated-at.bofh.it>
[not found] ` <tt0r.6Rc.19@gated-at.bofh.it>
[not found] ` <tt0r.6Rc.21@gated-at.bofh.it>
[not found] ` <tt0r.6Rc.23@gated-at.bofh.it>
[not found] ` <tt0r.6Rc.25@gated-at.bofh.it>
[not found] ` <tt0q.6Rc.15@gated-at.bofh.it>
[not found] ` <tyCN.6RD.13@gated-at.bofh.it>
2003-09-08 20:08 ` Ihar 'Philips' Filipau
[not found] <snJB.8dk.25@gated-at.bofh.it>
[not found] ` <snTm.8qD.41@gated-at.bofh.it>
[not found] ` <sTpW.18Z.19@gated-at.bofh.it>
[not found] ` <teE5.2XZ.9@gated-at.bofh.it>
2003-09-08 12:07 ` Ihar 'Philips' Filipau
2003-09-05 13:57 John Bradford
2003-09-05 15:39 ` Mehmet Ceyran
2003-09-06 20:24 ` David B. Stevens
-- strict thread matches above, loose matches on Subject: below --
2003-09-05 12:25 John Bradford
2003-09-05 12:25 ` Fruhwirth Clemens
2003-09-06 22:08 ` Herbert Poetzl
2003-09-07 20:40 ` Fruhwirth Clemens
2003-09-05 13:20 ` Richard B. Johnson
2003-09-05 12:21 John Bradford
2003-09-04 10:42 Fruhwirth Clemens
2003-09-04 12:32 ` Antonio Vargas
2003-09-04 13:44 ` Yann Droneaud
2003-09-04 14:05 ` Richard B. Johnson
2003-09-04 14:21 ` Sean Neakums
2003-09-04 14:33 ` Richard B. Johnson
2003-09-04 15:09 ` Yann Droneaud
2003-09-04 14:55 ` Yann Droneaud
2003-09-05 21:16 ` George Anzinger
2003-09-04 14:57 ` Michael Frank
2003-09-04 15:43 ` Fruhwirth Clemens
2003-09-04 22:28 ` insecure
2003-09-05 12:59 ` Michael Frank
2003-09-05 17:28 ` insecure
2003-09-05 17:45 ` Jörn Engel
2003-09-06 17:18 ` insecure
2003-09-07 18:49 ` Eric W. Biederman
2003-09-07 19:30 ` Jamie Lokier
2003-09-09 21:37 ` insecure
2003-09-09 21:34 ` insecure
2003-09-11 11:07 ` Ricardo Bugalho
2003-09-12 15:26 ` insecure
2003-09-12 17:27 ` Ricardo Bugalho
2003-09-12 22:17 ` Jörn Engel
2003-09-13 19:25 ` Jamie Lokier
2003-09-13 19:51 ` Jörn Engel
2003-09-11 14:03 ` Eric W. Biederman
2003-09-11 17:05 ` Jamie Lokier
2003-09-09 20:56 ` Pavel Machek
2003-09-05 13:27 ` Jesse Pollard
2003-09-05 23:51 ` Aaron Lehmann
2003-09-06 1:41 ` Valdis.Kletnieks
2003-09-04 14:56 ` Yann Droneaud
2003-09-05 11:42 ` Jörn Engel
2003-09-05 12:04 ` Fruhwirth Clemens
2003-09-05 12:37 ` Jörn Engel
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=3F5C7009.4030004@softhome.net \
--to=filia@softhome.net \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).