Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 58501 invoked from network); 6 Feb 2009 02:17:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 6 Feb 2009 02:17:43 -0000 Received: (qmail 49549 invoked by uid 500); 6 Feb 2009 02:17:42 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 49516 invoked by uid 500); 6 Feb 2009 02:17:42 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 49505 invoked by uid 99); 6 Feb 2009 02:17:42 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Feb 2009 18:17:42 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of xiaofeng.li@gmail.com designates 209.85.220.17 as permitted sender) Received: from [209.85.220.17] (HELO mail-fx0-f17.google.com) (209.85.220.17) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Feb 2009 02:17:34 +0000 Received: by fxm10 with SMTP id 10so746666fxm.12 for ; Thu, 05 Feb 2009 18:17:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=p+/DeEmXmJd9RsikL+vg62chis6Ed8aVm0tQN0KSnn0=; b=BWJOFvSgmNYTwc7uiJy+zc0MhKdjUwxunfjbIL3zlCEoJD1VJizcilbjCNqhR3NpUm E8KUhCqxpEVV+T21vlrVgSGoJBLcbDCygTcpv5fif+RPA/vc9xp35XiYGdDq1ZzszIqZ 64tO9i6LI+CgAK8OH9HdNI8sqUWh371HPHs84= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=YvLTdjuBi/lOe+mp58yNqEmxoBLSkhqgs86Ox7yHocvZV2MuP0zE/+RzTiJ5zCWtKG bH5ypxQxbOracKFoGI2cFO+drKgHr58yezSJM087+rI8r0DyhGn4H7Y868gs6QQyBNuY FH3X9jLrJIDWuW2/8MVl0+wgfE/y35KleA0gQ= MIME-Version: 1.0 Received: by 10.181.20.13 with SMTP id x13mr390077bki.164.1233886633606; Thu, 05 Feb 2009 18:17:13 -0800 (PST) In-Reply-To: <255079590902050020y6aae262cw69843f1ed3a6093b@mail.gmail.com> References: <255079590811021952l458ebaban7c9ec20849b39867@mail.gmail.com> <9623c9a50811022021i332c19fen95d732c7b49aa745@mail.gmail.com> <255079590811022200v1df41e69o6f28d3384a00949b@mail.gmail.com> <255079590902050020y6aae262cw69843f1ed3a6093b@mail.gmail.com> Date: Fri, 6 Feb 2009 10:17:13 +0800 Message-ID: <9623c9a50902051817m2d878470j28ba3666a2c495cb@mail.gmail.com> Subject: Re: discussion for H5022 From: Xiao-Feng Li To: dev@harmony.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Does newImmOpnd() generate 64bit imm? Thanks, xiaofeng On Thu, Feb 5, 2009 at 4:20 PM, xiaoming gu wrote: > I did some tests on 64-bit Windows and found sizeof(POINTER_SIZE_INT)=8. So > I think no truncation happens. And I could NOT find the code mentioned in > [1] and maybe it is because of some rollback. What's your opinion? > > Xiaoming > > [1] - https://issues.apache.org/jira/browse/HARMONY-5022 > > On Mon, Nov 3, 2008 at 2:00 PM, xiaoming gu wrote: > >> So in 64-bit platform with compressed pointer, the base address for heap is >> still 64-bit but the offset is 32-bit. >> >> Got it. Thanks. -Xiaoming >> >> >> On Mon, Nov 3, 2008 at 12:21 PM, Xiao-Feng Li wrote: >> >>> Xiaoming, I think this work is only related with X86-64, the 64bit >>> machine. In a 32bit platform, there is no such concept of 64-bit base >>> address. In 64-bit platform with compressed pointer, we have a base >>> address and a 32-bit offset for one pointer. >>> >>> Thanks, >>> xiaofeng >>> >>> On Mon, Nov 3, 2008 at 11:52 AM, xiaoming gu >>> wrote: >>> > Hi, guys. I'm studying H5022 - incorrect codegeneration of compressed >>> obj >>> > arithmetics[1]. In my understanding, the problem is that current JIT >>> casts >>> > heap base address from 64-bit to 32-bit compulsorily in IA32 but that >>> > address must be in 64-bit even in a 32-bit platform. If I catch the >>> point of >>> > this jira correctly, I'll try to delete the casts in >>> > Ia32InstCodeSelector.cpp recently. Any comment? Thanks. >>> > >>> > Xiaoming >>> > >>> > [1] - https://issues.apache.org/jira/browse/HARMONY-5022 >>> > >>> >>> >>> >>> -- >>> http://xiao-feng.blogspot.com >>> >> >> > > > -- > China Runtime Technologies Lab, > SSG/SSD/MRTC, Intel > -- Managed Runtime Technology Center, Intel