From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19386 invoked by alias); 26 Jan 2008 20:12:22 -0000 Received: (qmail 19369 invoked by uid 22791); 26 Jan 2008 20:12:20 -0000 X-Spam-Check-By: sourceware.org Received: from mail-3.netbauds.net (HELO mail-3.netbauds.net) (78.33.0.242) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 26 Jan 2008 20:11:48 +0000 Received: from host86-128-22-237.range86-128.btcentralplus.com ([86.128.22.237]:48084 "EHLO odin.home.darrylmiles.org" smtp-auth: "darryl" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: rhost-flags-OK-OK-OK-FAIL) by mail-3.netbauds.net with ESMTPSA id S3463586AbYAZULp (ORCPT ); Sat, 26 Jan 2008 20:11:45 +0000 Message-ID: <479B9400.4040208@netbauds.net> Date: Mon, 28 Jan 2008 03:12:00 -0000 From: Darryl Miles User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Ian Lance Taylor CC: PRC , gcc-help Subject: Re: Why does gcc produce an unnecessary `nop' instruction? References: <200801251222137454465@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2008-01/txt/msg00274.txt.bz2 Ian Lance Taylor wrote: > "PRC" writes: > >> The assembly code produced by gcc is: >> ----------------------------------------------- >> 800650b0 : >> 800650b0: 3c048006 lui a0,0x8006 >> 800650b4: 0801964b j 8006592c >> 800650b8: 24846128 addiu a0,a0,24872 >> 800650bc: 00000000 nop >> ----------------------------------------------- >> The `nop' instruction seems useless at all here. > > It's probably caused by requested alignment of the next function. > Note that nop is just the value 0. > > To see whether gcc is actually generating the nop, use the > --save-temps option when you compile, and look at the .s file. If you > don't see the nop there, it's coming from something other than gcc. My argument here is that inserting padding should be done by the linker not by the compiler/assembler. The only thing the compiler/assembler should provide in the object code is a padding hint. The hint should also be graded from "weak hint" to "strong hint" to "mandatory hint/requirement". Where a "weak hint" is used when no explicit padding requirement has been set by the programmer, we're just getting the best practice padding offer by the compiler for the architecture. At the moment we're forced to accept this down our throats because the stupid compiler/assembler forced "nop" instructions onto the tail of object code, once its in .text its set in stone. Where a "strong hint" is what a programmer would get if he specified a hint but this maybe overwritten during linking and would not cause a linking error to occur. Where a "mandatory hint/requirement" is what a programmer would specify where the linking process must error if the padding requirement could not be met. I would go so far to say that padding between function/blocks inside .text should also emit hint information to allow the linker to strip and reorder code within objects. It would need to record the nature of the padding (i.e. the reason it was inserted, intra-function-padding, end-of-object-padding, pre-variable-alignment-padding, post-variable-alignment-padding, etc...). Maybe this information could be added to the reloc table, offset, length, strength-of-padding, reason-of-padding. All padding (or the minimum amount of padding) that can not be removed for fear of generating alignment exception is not considered padding for the purpose of this email. That type of padding has a genuine purpose to ensure valid and correct execution at runtime. It is only the extraneous padding that is inserted to improve performance can could be removed from the target architecture without causing runtime exceptions to occur. At some future date it would be nice if the linker could re-order object code and sub-blocks in object code and all variables so that the most compact use of memory was possible, or the most compact .text segment was possible in cases where we really do not care about the performance hit but we do care about the overall code size. This leads into having a runtime profiler take a look at the usage of your application and re-order everything it can to make the memory foot print smaller and the locality of variables/code better. Darryl