From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31915 invoked by alias); 10 Aug 2012 08:35:37 -0000 Received: (qmail 31840 invoked by uid 22791); 10 Aug 2012 08:35:36 -0000 X-SWARE-Spam-Status: No, hits=-0.4 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from se-got-ex01.semcon.se (HELO mail.semcon.com) (193.15.96.147) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 10 Aug 2012 08:35:22 +0000 Received: from SE-GOT-MB01.semcon.se ([fe80::24d6:bf1b:8ac4:e920]) by SE-GOT-EX01.semcon.se ([fe80::64b8:9854:cae6:ec9%11]) with mapi id 14.02.0247.003; Fri, 10 Aug 2012 10:35:20 +0200 From: =?iso-8859-1?Q?G=F6ran_Steen?= To: David Brown CC: "gcc-help@gcc.gnu.org" Subject: RE: 16-bit int Date: Fri, 10 Aug 2012 08:53:00 -0000 Message-ID: References: <5024C255.7030504@westcontrol.com> In-Reply-To: <5024C255.7030504@westcontrol.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: 2012-08/txt/msg00072.txt.bz2 Thank you for your response. Sorry, this will not help. I want to test the snippets, not change them. Be= sides, I don't know if the compiler that will be used for the 16-bit machin= e will support any of the types you suggest, so I only want to use standard= types. BR /g=F6ran -----Original Message----- From: David Brown [mailto:david@westcontrol.com]=20 Sent: den 10 augusti 2012 10:12 To: G=F6ran Steen Cc: gcc-help@gcc.gnu.org Subject: Re: 16-bit int On 10/08/2012 09:15, G=F6ran Steen wrote: > Thank you for your response. > > I want to make sure that my code snippets, if they are compiled and=20 > run on a machine with 16-bit int, still works. I don't have access to=20 > such a machine, so I want to compile and run them with 16-bit int on=20 > my machine that defaults to 32-bit int. Especially the intermediate=20 > results' size are interesting. What happens if they are truncated to=20 > 16-bit? > The answer here is simple - #include , and use types like int_fas= t16_t. If intermediary results might need 32 bits, cast to int_fast32_t as= needed. On a target with 32-bit ints, both these types will normally be 3= 2-bit (though int_fast16_t could theoretically be 16-bit), and the cast wil= l do nothing. On a target with 16-bit ints, you will get 16-bit and 32-bit= ints respectively. This will give you optimal code for all sizes of target ints, while also be= ing correct on each target. mvh., David > There will not be any problem with library compatibility. > > BR /g=F6ran > > -----Original Message----- From: David Brown=20 > [mailto:david@westcontrol.com] Sent: den 9 augusti 2012 15:37 To: > G=F6ran Steen Cc: gcc-help@gcc.gnu.org Subject: Re: 16-bit int > > On 09/08/2012 13:26, G=F6ran Steen wrote: >> Hi! >> >> I use gcc version 4.3.4, where int is 32-bit variables. Is it=20 >> possible to setup compiler to compile int as 16-bit variables? >> >> With best regards / Med v=E4nlig h=E4lsning / Mit freundlichen Gr=FC=DFe= n /=20 >> Sauda=E7=F5es >> >> G=F6ran Steen > > > The size of an int depends on the target - gcc supports dozens of=20 > targets. Most have 32-bit ints, but some have 16-bit ints and at=20 > least one has a compile-time option to support 8-bit ints (though that=20 > goes against C standards, and is deprecated on current builds). > There are probably also targets with 64-bit ints. > > So step one in asking for help here is to tell us your target. > > Step two is to tell us what you are hoping to achieve. Almost=20 > certainly, there is no way to change the int size - and even if there=20 > happens to be a command-line switch for the given target, it is=20 > probably not a good idea (you'll get in a horrible mess with library=20 > compatibility, for example). And even if it is possible, it is highly=20 > unlikely to be advantageous. Tell us what you really want to achieve=20 > here, and people can give you advice towards that. > > mvh., > > David >