From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26069 invoked by alias); 19 May 2010 17:37:45 -0000 Received: (qmail 26039 invoked by uid 22791); 19 May 2010 17:37:43 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from idcmail-mo2no.shaw.ca (HELO idcmail-mo2no.shaw.ca) (64.59.134.9) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 19 May 2010 17:37:38 +0000 Received: from pd5ml2no-ssvc.prod.shaw.ca ([10.0.153.164]) by pd5mo1no-svcs.prod.shaw.ca with ESMTP; 19 May 2010 11:37:36 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=1 a=AudDyf3fWwEA:10 a=ood2b7iyd8MA:10 a=VphdPIyG4kEA:10 a=8nJEP1OIZ-IA:10 a=t0ucBU1Eu6NFLi2zTQywhg==:17 a=3fTejirSnZH7PjhHP-AA:9 a=R_RqVnnVD4GoXU2az-YgB6JS8DUA:4 a=wPNLvfGTeEIA:10 Received: from unknown (HELO [192.168.0.101]) ([174.7.6.208]) by pd5ml2no-dmz.prod.shaw.ca with ESMTP; 19 May 2010 11:37:36 -0600 Message-ID: <4BF421E0.9080009@parvan.net> Date: Wed, 19 May 2010 18:34:00 -0000 From: Reza Roboubi User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Nicholas Sherlock CC: gcc-help@gcc.gnu.org Subject: Re: short pointers (32 bit) in 64 bit apps References: <4BF0FCF3.5080608@parvan.net> <4BF361E4.5090602@parvan.net> <4BF3A75F.3090700@parvan.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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: 2010-05/txt/msg00220.txt.bz2 Nicholas Sherlock wrote: > On 19/05/2010 8:54 p.m., Reza Roboubi wrote: >> Nicholas Sherlock wrote: >>> On 19/05/2010 3:58 p.m., Reza Roboubi wrote: >>>> Do you know what it takes to do it? How much work for a newcomer to get >>>> up to speed with gcc? (Maybe this should go to the developer list?) >>> >>> You would need to write a memory allocator which divides the address >>> space into 4GB (32-bit pages). Then you could create a new malloc >>> routine which has an extra argument to allow you to allocate memory >>> from within a specified 4GB page. That way you can make all of your >>> allocations for a given data structure lie within the same region. >> >> Since we are trying to _compress_ these structs in the first place >> malloc'ing them individually is pointless anyway. We should probably >> have some sort of custom (fixed size) allocator. > > If the pointers only have to refer to memory within the same memory > allocation, and that allocation is smaller than 4GB, that's a > significantly more restricted problem. You wouldn't need a custom memory > allocator, you could just store the difference between the pointer > target and the pointer's location instead of an absolute pointer. That > sounds doable. And that gets your ALU's doing a lot of unneeded additions and subtractions, every time you access such pointers. Reza.