From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1YOpnA-0005lS-He for mharc-grub-devel@gnu.org; Fri, 20 Feb 2015 10:47:00 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39551) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YOpn8-0005lH-GH for grub-devel@gnu.org; Fri, 20 Feb 2015 10:46:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YOpn7-0001Qa-Ix for grub-devel@gnu.org; Fri, 20 Feb 2015 10:46:58 -0500 Received: from mail-we0-x22b.google.com ([2a00:1450:400c:c03::22b]:46990) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YOpn7-0001QL-CL for grub-devel@gnu.org; Fri, 20 Feb 2015 10:46:57 -0500 Received: by wevm14 with SMTP id m14so6270363wev.13 for ; Fri, 20 Feb 2015 07:46:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=2VB0T918NKwofMyb5Pd+iFZkidzbspJvTxCPCDDwMKE=; b=JJWKsmClleAqopF/7jDBMaIuCc4nr01BThe0l/arqwfSu2QnynzfBE8d/IlTCajhEO xT0R6DVRDFEunh9oIO+JlEUXcxBGlcFrylc4BOfzDvdZTZKj2ikyKiSOfHRXs1Y7MoHJ dQgQdOCXVNvbVWd+TiwZfBFKCXtlCFyDoDvvrU3NTwqrufRBz4dZPKALsEY0TCiYObqs qAO4HFpmgl6TAoUneUim20eWfzFYfQve4L4OSg14ZtixyPMWjONzRjNixB21757VP2Kd UwGcuWMymOONNrjL27YLaZY1kc2ZpseKfdL5Jq/+jfq7V1k0HtQTiksow+Ypjy1tv3ay pnCA== X-Received: by 10.180.91.43 with SMTP id cb11mr16910971wib.16.1424447216737; Fri, 20 Feb 2015 07:46:56 -0800 (PST) Received: from ?IPv6:2620:0:105f:fd00:202:52ff:fe61:c42e? ([2620:0:105f:fd00:202:52ff:fe61:c42e]) by mx.google.com with ESMTPSA id kr5sm37642135wjc.1.2015.02.20.07.46.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Feb 2015 07:46:55 -0800 (PST) Message-ID: <54E756EE.1030401@gmail.com> Date: Fri, 20 Feb 2015 16:46:54 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: David Woodhouse Subject: Re: clang .code16 with -Os producing larger code that it needs to References: <54E74B9D.8090605@gmail.com> <1424446685.5437.52.camel@infradead.org> In-Reply-To: <1424446685.5437.52.camel@infradead.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UWCN5tJKco8ck8T05xLMxIuHA9BWGkjRs" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c03::22b Cc: The development of GRUB 2 , llvmdev@cs.uiuc.edu X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 15:47:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UWCN5tJKco8ck8T05xLMxIuHA9BWGkjRs Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 20.02.2015 16:38, David Woodhouse wrote: > On Fri, 2015-02-20 at 15:58 +0100, Vladimir '=CF=86-coder/phcoder' Serb= inenko > wrote: >> When experimenting with compiling GRUB2 with clang using integrated as= , >> I found out that it generates a 16-bit code bigger than gas counterpar= t >> and result gets too big for size constraints of bootsector. This was >> traced mainly to 2 problems. >=20 > ... >=20 >> 32-bit access to 16-bit addresses. >> clang: >> 7cbc: 67 66 8b 1d 5c 7c 00 00 addr32 mov 0x7c5c,%ebx >> gas: >> 7cbc: 66 8b 1e 5c 7c mov 0x7c5c,%ebx >=20 >> 32-bit jump. >> clang: >> + 7cb5: 66 0f 83 07 01 00 00 jae 7dc3 >> gas: >> - 7cb5: 0f 83 0a 01 jae 7dc3 >=20 > To a large extent, those are the *same* problem. We don't know that it'= s > eventually going to fit into a 16-bit offset, so we emit it with a fixu= p > record which can cope with 32 bits. >=20 All labels are local to the source file. If I use %eax instead of %ebx in first example I get the short code. For the second example how does clang detect that offset fits into one byte for issuing EB XX sequence which is issued in resulting file in several places. Can we use the same mechanism to detect when issuing 16-bit reference and keep 32-bit one for external references? > Arguably, the jump is *particularly* gratuitous in many cases... but in= > 'big real' mode is the IP *really* limited to 16 bits? >=20 > We could make it default to 16-bit, as gas does. But then we'd be > screwed in the cases where we really *do* need 32-bit. >=20 > What we actually need to do is implement handling for the explicit > addr32 prefix. Then we can do what gas does and default to 16-bit but > *also* have a way to do 32-bit when it's needed. >=20 --UWCN5tJKco8ck8T05xLMxIuHA9BWGkjRs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iF4EAREKAAYFAlTnVu4ACgkQmBXlbbo5nOvtxAEAipsJVZ0rjDUFU07jkfqYWTCI CN7WmM95UXvYQFSB6+EA/3I661Ntm2+mAnSCkzRVbMgqb77kJDeZraIxwcMyet2B =i4uC -----END PGP SIGNATURE----- --UWCN5tJKco8ck8T05xLMxIuHA9BWGkjRs--