comp.lang.ada
 help / color / mirror / Atom feed
From: adambeneschan@gmail.com
Subject: Re: How To Pass Large Object Arguments
Date: Mon, 25 Nov 2013 08:53:56 -0800 (PST)
Date: 2013-11-25T08:53:56-08:00	[thread overview]
Message-ID: <299eb9f2-d5be-4fcd-a340-b4c28b28c1b8@googlegroups.com> (raw)
In-Reply-To: <sqadnfc3IfFSNQzPnZ2dnUVZ_jydnZ2d@giganews.com>

On Saturday, November 23, 2013 11:20:53 PM UTC-8, FritzVonBraun wrote:
> Hello all,
> 
> 
> 
> I am fairly new to Ada and I am wondering how I should pass large 
> parameters to subprograms like arrays or records that contain other 
> components like vectors or lists.
> 
> I did a lot of reading but wasnt able to find a definite answer. the 
> general consensus I got from Barne's book and various blogs and 
> whitepapers from Universities was that in theory IN parameters are 
> copied but the compiler manufacturer is free to implement a reference to 
> the original object and so on. So basically what I found out there is no 
> concrete rule that says "parameter of that size or greater are passed by 
> reference internally"
> 
> So my question is, is there a de facto standard at least? What does Gnat 
> do in such cases? (In all honesty, my programs will never run on 
> anything but Gnat, so other compilers don't really matter to me). I am 
> considering passing objects that I think are too big for a copy 
> operation through an access parameter, but that would basically 
> contradict the principle of problem orientation instead of machine 
> orientation. I would really rather be able to handle these situations 
> without having to worry about the underlying mechanism myself.

The RM has some rules about how certain types are to be passed.  Elementary types are always passed by copy; those are types that essentially aren't broken down into subcomponents, i.e. numbers, enumerations, access types.  This is true even for IN OUT parameters; the value will be passed by copy, and a new value will be copied back after the procedure or function returns.  Tagged types, tasks, protected types, other limited types, and any record or array containing one of those, are always passed by reference.  This is true even for IN parameters.  If the "vectors" or "lists" you're referring to are types in one of the Ada.Containers packages, then they will be passed by reference since Ada.Containers.Vectors.Vector is defined to be a tagged type, and I think that's true for all the other containers.

But for records and arrays that don't fall into one of those categories, it's up to the compiler.  And the compiler's decision may depend on the target processor.  One of our compilers (for a particular RISC-ish target) would pass any record up to four 32-bit words by copy, in registers.  However, for a Pentium, which has very few registers, an implementation like this wouldn't make sense, and there's no point in copying a record to the stack if it isn't required by the language.

So for record and array types that aren't specified by the RM, you shouldn't worry about the parameter passing mechanism, and let the compiler decide what it thinks the best way is.  You should also write code in a way that assumes either one or the other mechanism could be used.  That is, if you call Foo(Param => X) where X's type is some record type, and somewhere while Foo is running, something happens that causes a field in X to be modified, Foo itself may or may not notice that that field has changed if it accesses Param.Field.  (And that's true even if X is passed by reference, since the compiler could generate code that "knows" Param.Field won't change, since it can't tell whether the actual record will change behind its back.)  

                                -- Adam


  parent reply	other threads:[~2013-11-25 16:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-24  7:20 How To Pass Large Object Arguments FritzVonBraun
2013-11-24 11:12 ` Ludovic Brenta
2013-11-24 12:45 ` Peter C. Chapin
2013-11-25 10:59 ` Georg Bauhaus
2013-11-25 11:09 ` AdaMagica
2013-11-25 16:53 ` adambeneschan [this message]
2013-11-25 17:05   ` sbelmont700
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox