From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,e56fd2619c02e35a X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Received: by 10.68.38.134 with SMTP id g6mr33488309pbk.6.1317206594186; Wed, 28 Sep 2011 03:43:14 -0700 (PDT) Path: lh7ni6575pbb.0!nntp.google.com!news1.google.com!postnews.google.com!i23g2000yqm.googlegroups.com!not-for-mail From: Ludovic Brenta Newsgroups: comp.lang.ada Subject: Re: 64 bit codes Date: Wed, 28 Sep 2011 03:36:24 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <4e817fdb$0$7615$9b4e6d93@newsspool1.arcor-online.net> <213da3b7-f9d0-4a7d-b215-9992ee0f1a02@f6g2000vbm.googlegroups.com> <2a797a9e-f0e3-4fbe-8f40-b6787b4e2879@o11g2000yqc.googlegroups.com> <4e82ee92$0$6573$9b4e6d93@newsspool3.arcor-online.net> NNTP-Posting-Host: 153.98.68.197 Mime-Version: 1.0 X-Trace: posting.google.com 1317206594 15621 127.0.0.1 (28 Sep 2011 10:43:14 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 28 Sep 2011 10:43:14 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: i23g2000yqm.googlegroups.com; posting-host=153.98.68.197; posting-account=pcLQNgkAAAD9TrXkhkIgiY6-MDtJjIlC User-Agent: G2/1.0 X-HTTP-Via: ICAP/1.0 192.168.152.4 X-Google-Web-Client: true X-Google-Header-Order: HUALESRCVNK X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101206 Red Hat/3.6-2.el5 Firefox/3.6.13,gzip(gfe) Xref: news1.google.com comp.lang.ada:18182 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2011-09-28T03:36:24-07:00 List-Id: Georg Bauhaus wrote on comp.lang.ada: > On 27.09.11 17:49, Bill Findlay wrote: >> So, while your caveats are of course valid, there certainly are workload= s >> that benefit greatly from working in 64 bits. > > IBM confirms: > > "64 bit register use in 32 bit applications: GCC will exploit the > =A0availability of 64 bit registers in 32 bit applications when compiling > =A0with -m31 -mzarch. This provides a significant performance gain for 32 > =A0bit applications built this way. The versions of the Linux Kernel, > =A0GNU Binutils, GNU C Library and GDB as documented here provide the > =A0support required by this GCC feature." > > http://www.ibm.com/developerworks/linux/linux390/toolchain.html > > I hadn't known that there are 31-bit systems and correspondingly, > a -m31 switch for GCC. Wow. S/370-XA (introduced 1983) and subsequent IBM mainframes had 31-bit address and 32-bit data buses. The addresses were really 32-bit, of course, but one bit is reserved to distinguish 31-bit addresses from 24-bit (!) addresses for compatibility with the earlier S/360 and S/ 370 architectures. Each process thus has a 2 GiB address space. The entire system can have much more than that in physical RAM, of course. The mainframes moved to full 64-bit support (z/Architecture) in 2000 but the 31-bit/24-bit mode still exists for backward compatibility. The quote from IBM clearly applies only to these later (current) mainframes, as the earlier ones did not even have 64-bit registers. Hence the requirement for "-mzarch" in addition to the "-m31". BTW, I never disputed that the use of 64-bit registers improved performance. What I claimed was this performance gain might be offset, in whole or in part, by losses in cache hit rates and higher memory bandwidth requirements. Sun Microsystems moved to full 64-bit support as early as 1995 but used to recommend that applications be compiled in 32-bit mode, unless they required more than 4 GiB of memory, for this reason. The kernel was of course 64-bit. -- Ludovic Brenta.