From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82589 invoked by alias); 1 Apr 2017 16:47:39 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 82574 invoked by uid 89); 1 Apr 2017 16:47:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=bsp, Recently, x87, 8088 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 01 Apr 2017 16:47:37 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=svr-ies-mbx-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1cuMBc-0004St-P3 from Andrew_Jenner@mentor.com for gcc-patches@gcc.gnu.org; Sat, 01 Apr 2017 09:47:36 -0700 Received: from [IPv6:::1] (137.202.0.87) by svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 1 Apr 2017 17:47:33 +0100 From: Andrew Jenner Subject: [PATCH 0/9] New back end ia16: 16-bit Intel x86 To: GCC Patches Message-ID: <1633e4a5-dc7f-4a75-e431-9539c549cca7@codesourcery.com> Date: Sat, 01 Apr 2017 16:47:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-SW-Source: 2017-04/txt/msg00009.txt.bz2 About 10 years ago, Rask Ingemann Lambertsen sent a patch series to add a 16-bit x86 (i.e. 8088, 8086, 80186 and 80286 CPUs) back end. This work was never committed. Recently I've been doing some work on this back end, and today we released a Sourcery CodeBench Lite distribution based on it (see https://blogs.mentor.com/embedded/blog/2017/04/01/announcing-sourcery-codebench-lite-for-ia16/ ). Given this, I thought it would be a good idea to send these patches upstream today (though obviously if I commit these it won't be until we're in Stage 1 and more testing has been done on the middle-end changes). I have not been able to contact Rask Ingemann Lambertsen, but he does have a copyright assignment for GCC on file (dated 2006-11-16) so I do not believe there are any copyright assignment issues that would block this. On top of the original patch, here is what I have done: * Ported to GCC 6.3. * Switched from reload to LRA. * Added C++ support. * Added startup code, BSP and string functions to Newlib. * Improved prologue/epilogue generation. * Implemented stack usage and sibling calls. * Fixed many bugs. * Improved the testsuite to have better support for 16-bit ports. My intention is to continue to develop this back end. I'm happy to be maintainer of it as an in-tree port or (if the steering committee does not want this port in-tree) as an out-of-tree port. I plan to add further code generation improvements and features including: * Far pointers. * Support for OMF .obj files and DOS .exe files in binutils. * x87 floating point. * Debugging support. * More C library functions (to improve compatibility with other DOS compilers). Contents of the patch set: 1: Top-level config.sub. 2: The port itself. 3: Documentation. 4: libstdc++ changes. 5: libstdc++ testsuite changes. 6: gcc testsuite changes. 7: ira-color.c fix. 8: subreg_get_info fix. 9: c-family/c-cppbuiltin.c fix. Test results are at https://gcc.gnu.org/ml/gcc-testresults/2017-04/msg00088.html To answer some questions that came up last time the port was submitted: * This port is only useful for targetting CPUs prior to the 80386. If you want to generate code for a 32-bit x86 CPU that runs in 16-bit mode (e.g. for a bootloader) the i386 target has the -m16 option for this case. * I'm not interested in changing the name from ia16. I'd have preferred i086 or i86 (by analogy with i386) but I don't feel strongly enough to argue about it or change it. If someone else cares strongly enough about it to write the patches, I'll consider it. * I'm also not interested in merging this port with the i386 back end. The targets are too different, and it would create an excessive maintenance burden for ia16 and (worse) for i386. Andrew