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,703c4f68db81387d X-Google-Thread: 109fba,703c4f68db81387d X-Google-Thread: 115aec,703c4f68db81387d X-Google-Thread: f43e6,703c4f68db81387d X-Google-Attributes: gid103376,gid109fba,gid115aec,gidf43e6,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!newshub.sdsu.edu!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!newshosting.com!nx01.iad01.newshosting.com!207.115.63.142.MISMATCH!newscon02.news.prodigy.com!newscon06.news.prodigy.com!prodigy.net!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada,comp.lang.c++,comp.realtime,comp.software-eng Subject: Re: Teaching new tricks to an old dog (C++ -->Ada) Date: 11 Mar 2005 16:37:23 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <4229bad9$0$1019$afc38c87@news.optusnet.com.au> <1110032222.447846.167060@g14g2000cwa.googlegroups.com> <871xau9nlh.fsf@insalien.org> <3SjWd.103128$Vf.3969241@news000.worldonline.dk> <87r7iu85lf.fsf@insalien.org> <1110052142.832650@athnrd02> <1110284070.410136.205090@o13g2000cwo.googlegroups.com> <395uqaF5rhu2mU1@individual.net> <112rs0bdr2aftdf@corp.supernews.com> <1inxxr988rxgg$.1w9dedak41k89.dlg@40tude.net> <112s1r0rf0o8nca@corp.supernews.com> NNTP-Posting-Host: shell01-e.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1110577045 5166 69.38.147.31 (11 Mar 2005 21:37:25 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Fri, 11 Mar 2005 21:37:25 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:9177 comp.lang.c++:45219 comp.realtime:1314 comp.software-eng:4882 Date: 2005-03-11T16:37:23-05:00 List-Id: CTips writes: > Dmitry A. Kazakov wrote: > > > On Tue, 08 Mar 2005 13:33:33 -0500, CTips wrote: > > > >>How easy is it to build an arena allocator in Ada? > > It is trivial: > > type Object is ...; > > type Object_Ptr is access Object; > > for Object_Ptr'Storage_Pool use My_Arena; > > Here you are: > > Ptr : Object_Ptr := new Object; -- This allocates it in My_Arena > > And how is My_Arena defined? Is it just a blob of memory? Or is it a > "class" that can invoke sbrk (or whatever) when it needs to? Dmitry showed how to *use* an arena allocator. You (CTips) seem to be asking how to write the code of the allocator itself. Yes, it's ``a "class" that can invoke sbrk (or whatever)''. That is, the code for Allocate and Deallocate are written by the programmer to do whatever is necessary, and are called automatically by "new" and "Unchecked_Deallocation". (Unchecked_Deallocation is like free.) The "arena" allocator can of course do what it likes -- allocate from a blob of memory, or allocate small pieces out of large chunks, or request more memory from the OS (if there *is* an OS), etc. I'm a little confused about what you (CTips) are asking. Maybe you could clarify a bit... > > Note that Object can still be allocated on the stack or in any other > > pool: > > type Object_Universal_Ptr is access all Object; > > This : Object; > > -- This allocates it on the stack > > That : Object_Universal_Ptr := new Object; > > -- This will be in the(a) default pool (in the heap) > > > >> Given a processor with load-word-locked and store-word-conditional, > >> how would I build an atomic increment function? > > Why should I have atomic increment function? Ada has native concurrency > > support. But if somebody would need that extremely low level thing as > > atomic integers, then: > > protected type Atomic_Integer is > > procedure Increment; > > private > > Value : Integer; > > end Atomic_Integer; > > -- Implementation > > protected body Atomic_Integer is > > procedure Increment is > > begin > > Value := Value + 1; > > end Increment; > > end Atomic_Integer; > > > > Will that generate: > L0: > lwlock temp,&Value > add temp,temp,1 > stwcond temp,&Value > if( failed ) goto L0; > or will it generate something much more heavy-weight. It will generate something much more heavy-weight, but portable, in most Ada compilers. If you want access to machine instructions, you use machine code inserts, but of course you then lose portability. I don't know of any Ada compiler that's smart enough to compile the above into the most efficient code on machines that *do* have those atomic instructions. I thought this discussion was about C++ vs. Ada. Both allow machine-code inserts. And (of course) machine-code is not portable. I don't see any difference there. - Bob