From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Fabrice Popineau Newsgroups: gmane.emacs.devel Subject: Re: Windows 64 port Date: Tue, 21 Feb 2012 00:11:26 +0100 Message-ID: References: <20120219211800.0000558f@unknown> <834numv7js.fsf@gnu.org> <4F428780.8070902@cs.ucla.edu> <4F42B076.4030702@cs.ucla.edu> <83sji5te78.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=00151747ba061af0be04b96d6b6a X-Trace: dough.gmane.org 1329795913 10550 80.91.229.3 (21 Feb 2012 03:45:13 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 21 Feb 2012 03:45:13 +0000 (UTC) Cc: Paul Eggert , emacs-devel@gnu.org, ajmr@ilovetortilladepatatas.com To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 21 04:45:11 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Rzgf6-00049f-N1 for ged-emacs-devel@m.gmane.org; Tue, 21 Feb 2012 04:45:08 +0100 Original-Received: from localhost ([::1]:50635 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rzgf4-0003W9-Tx for ged-emacs-devel@m.gmane.org; Mon, 20 Feb 2012 22:45:06 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:41115) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzcOd-0005kX-8C for emacs-devel@gnu.org; Mon, 20 Feb 2012 18:11:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RzcOc-0001WO-2A for emacs-devel@gnu.org; Mon, 20 Feb 2012 18:11:51 -0500 Original-Received: from mail-bk0-f41.google.com ([209.85.214.41]:35558) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzcOZ-0001W9-Vb; Mon, 20 Feb 2012 18:11:48 -0500 Original-Received: by bkty12 with SMTP id y12so5984461bkt.0 for ; Mon, 20 Feb 2012 15:11:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=Y8wM3r9gpPaw31t7LnugfAVRF3TSQWZu5jntJSM8qVI=; b=dRqljPfv5vYnPzSJhbjsSaM+Fe4X4aLDU7HdbWKXHc5x8fO+IskhlMKihWWuNiGVPw Q7bh/ipUMlLAGfcqhcn8kFj1tIb4m/9HxU+t2NiIvOQhL+aLRAeGwMkAH0diNSw0+dr9 kHFvx/mG6CRBAwOY9P0KpXnUvXd5Ufs/+8t0s= Original-Received: by 10.204.129.208 with SMTP id p16mr9929274bks.131.1329779506343; Mon, 20 Feb 2012 15:11:46 -0800 (PST) Original-Received: by 10.204.60.3 with HTTP; Mon, 20 Feb 2012 15:11:26 -0800 (PST) In-Reply-To: <83sji5te78.fsf@gnu.org> X-Google-Sender-Auth: qI2OXcTEuroS-DhpiqOWlfx4HCg X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.214.41 X-Mailman-Approved-At: Mon, 20 Feb 2012 22:45:02 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:148690 Archived-At: --00151747ba061af0be04b96d6b6a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'll check this patch again before the end of the week since we don't seem to be in a hurry. All I can say for sure is that in several places the compiler (not gcc, but msvc) inserted sign extent instructions. I tracked them down to mismatches between ints and intptr_t or ptrdiff_t. I fixed them by removing all compiler warnings of this kind. I also had to convert all DWORD uses for adresses to DWORD_PTR (MS recommended way of dealing with 32/64 bits). For the record and to make sure everyone is aware of it, compiling with msvc for x64, you get : C:\Temp>long short 2 int 4 long 4 long long 8 void* 8 The only difference with x86 is the size of the pointer which is 4 bytes (obviously). Regards, Fabrice 2012/2/20 Eli Zaretskii > > Date: Mon, 20 Feb 2012 12:43:34 -0800 > > From: Paul Eggert > > CC: Eli Zaretskii , AJMR >, > > emacs-devel@gnu.org > > > > Ideally any changes for Windows 64 would be only to the > > Windows-specific part of the code, so that we don't need to worry > > about its effect on GNU hosts. > > gmalloc.c and ralloc.c must be exceptions from this rule, for obvious > reasons. (Though the 64-bit Windows build probably is, or will be, > the only 64-bit platform to use these two.) > > I'd also take a very good look at all the EMACS_UINT uses, and a few > `long's and `unsigned long's in regex.c. > --=20 Fabrice Popineau ----------------------------- SUPELEC D=E9partement Informatique 3, rue Joliot Curie 91192 Gif/Yvette Cedex Tel direct : +33 (0) 169851950 Standard : +33 (0) 169851212 ------------------------------ --00151747ba061af0be04b96d6b6a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'll check this patch again before the end of the week since we don'= ;t seem to be in a hurry.

All I can say for sure is that= in several places the compiler (not gcc, but msvc)
inserted sign= extent instructions. I tracked them down to mismatches between ints and in= tptr_t
or ptrdiff_t. I fixed them by removing all compiler warnings of this k= ind.
I also had to convert all DWORD uses for adresses to DWORD_P= TR (MS recommended
way of dealing with 32/64 bits).

For the record and to make sure everyone is aware of it, com= piling with msvc for x64, you get :

C:\Temp&g= t;long
short 2
int 4
long 4
long lo= ng 8
void* 8

The only difference with x86 is= the size of the pointer which is 4 bytes (obviously).

=
Regards,

Fabrice


2012/2/20 Eli Zaretskii &l= t;eliz@gnu.org>
> Date: Mon, 20 Feb 2012 12:43:34 -0800
> From: Paul Eggert <eggert@cs.= ucla.edu>
> CC: Eli Zaretskii <eliz@gnu.org= >, AJMR <ajmr@ilov= etortilladepatatas.com>,
> =A0emacs-devel@gnu.org
>
> Ideally any changes for Windows 64 would be only to the
> Windows-specific part of the code, so that we don't need to worry<= br> > about its effect on GNU hosts.

gmalloc.c and ralloc.c must be exceptions from this rule, for obvious=
reasons. =A0(Though the 64-bit Windows build probably is, or will be,
the only 64-bit platform to use these two.)

I'd also take a very good look at all the EMACS_UINT uses, and a few `long's and `unsigned long's in regex.c.



--
Fabrice Popi= neau
-----------------------------
SUPELEC
D=E9part= ement Informatique
3, rue Joliot Curie
91192 Gif/Yvette= Cedex
Tel direct : +33 (0) 169851950
Standard : +33 (0) 169851212<= /div>
------------------------------


--00151747ba061af0be04b96d6b6a--