From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18677 invoked by alias); 7 Apr 2006 23:39:26 -0000 Received: (qmail 18668 invoked by uid 22791); 7 Apr 2006 23:39:25 -0000 X-Spam-Check-By: sourceware.org Received: from bay108-f23.bay108.hotmail.com (HELO hotmail.com) (65.54.162.33) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 07 Apr 2006 23:39:23 +0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 7 Apr 2006 16:39:21 -0700 Message-ID: Received: from 65.54.162.200 by by108fd.bay108.hotmail.msn.com with HTTP; Fri, 07 Apr 2006 23:39:17 GMT X-Sender: no_mayl@hotmail.com From: "No Name" To: binutils@sources.redhat.com Bcc: Subject: .code16gcc, i386, and loop/jcc/jmp data-size overrides Date: Sat, 08 Apr 2006 16:01:00 -0000 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_a51_35da_25ec" Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00128.txt.bz2 This is a multi-part message in MIME format. ------=_NextPart_000_a51_35da_25ec Content-Type: text/plain; format=flowed Content-length: 1477 Would it be ok for gas to generate extra size prefixes when compiling with code16gcc? Like that the produced object with 16bit code could run with an EIP > 0xffff. It would seem that the spirit of code16gcc is to be 32bit allover anyway. The attached patch is probably incomplete, "jcxz" should be tweaked also. And maybe the "loop/jcxz" handling is trickier due to suffixes manipulating addr-sizes instead of the data-sizes. * code .L19: movl -8(%ebp), %eax addl 8(%ebp), %eax cmpb $0, (%eax) jne .L21 !!>> jmp .L20 < !!>> e9 68 01 jmp 3b8 < !!>> 66 e9 8a 01 00 00 jmpl 403ec <