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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ead02e7101c0c023,start X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-02-27 18:54:02 PST Path: supernews.google.com!sn-xit-03!supernews.com!freenix!isdnet!newsfeed.icl.net!newspeer.clara.net!news.clara.net!news5-gui.server.ntli.net!ntli.net!news11-gui.server.ntli.net.POSTED!not-for-mail Message-ID: <3A9CD67C.9B15C417@linuxchip.demon.co.uk> From: Dr Adrian Wrigley X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.14-5.0smp i686) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Problems with large records (GNAT) [continued] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 28 Feb 2001 02:44:12 -0800 NNTP-Posting-Host: 62.253.132.124 X-Complaints-To: abuse@ntlworld.com X-Trace: news11-gui.server.ntli.net 983328208 62.253.132.124 (Wed, 28 Feb 2001 02:43:28 GMT) NNTP-Posting-Date: Wed, 28 Feb 2001 02:43:28 GMT Organization: ntl Cablemodem News Service Xref: supernews.google.com comp.lang.ada:5327 Date: 2001-02-28T02:44:12-08:00 List-Id: Hi all! You might remember a while back I had a problem with 'Size failing on large types, using GNAT (3.12p Intel Linux (Red Hat 6.2)). I never managed to solve that problem, and made do with keeping all my records under 256MB (!). This time, I have come across another manifestation of the problem, which appears rather strange. The locations for different elements in a record are the same. In the example code below, the elements First and Last are stored in the same place. (you can verify this using 'Access on the two elements). I wish to use large records mapped into memory using the "mmap" call, and obtain fast, random access to all the elements. Subsequent runs of the program can use the same data. This is an order of magnitude faster (sometimes two) than non-mmap solutions I tried. I'm wary of rewriting the code significantly, because the same problem may occur in the new code. Maybe some linked structure could do it, but then it would always need to be loaded in the same place. Any ideas/comments? Does this example work with other compilers on 32-bit architectures? How can I work out how much storage to allocate, when 'Size and 'Max_Size_In_Storage_Elements can't handle it? In this example, the code generates the wrong answer silently. I dont like that... ----------- with Text_IO; with Interfaces.C; procedure Dum is Size : Integer := 256*1024*1024 - 1; type Big_T is array (1 .. Size) of Float; type Item_T is record First : Float; Item : Big_T; Last : Float; end record; type Item_A is access all Item_T; function Malloc (Size : Interfaces.C.Size_t) return Item_A; pragma Import (C, Malloc, "malloc"); X : Item_A; begin X := Malloc (Interfaces.C.Size_T (Size * Float'Size + 2*Float'Size)); -- Hmmmm X.First := 3.14159; X.Last := 2.71828; Text_IO.Put_Line ("First is " & Float'Image (X.First) & " last is " & Float'Image (X.Last)); end Dum; ---------- $ gnatmake dum $ dum First is 2.71828E+00 last is 2.71828E+00 $ ---------- Dr Adrian Wrigley