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,46a68619f4362304
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: "Nick Roberts" <nick.roberts@acm.org>
Newsgroups: comp.lang.ada
Subject: Re: Specifying parameter passing convention and place (register)
Date: Thu, 08 Jul 2004 16:29:43 +0100
Message-ID: <opsatrztmfp4pfvb@bram-2>
References: <opsaot0qmdp4pfvb@bram-2> <Z027UNncuT4Q@eisner.encompasserve.org>
 <opsap78nn4p4pfvb@bram-2> <$RVvBAOy5BPi@eisner.encompasserve.org>
 <opsarq03jtp4pfvb@bram-2> <6qg+KjvqRKch@eisner.encompasserve.org>
 <opsascnzjtp4pfvb@bram-2> <6Bv31gVVqUnl@eisner.encompasserve.org>
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: news.uni-berlin.de ObWZMHCJZO+cwOqZ+uNfsw8QZcwDWHewHtzvYK+yAodhIoQ9I=
User-Agent: Opera M2/7.51 (Win32, build 3798)
Xref: g2news1.google.com comp.lang.ada:2122
Date: 2004-07-08T16:29:43+01:00
List-Id: <comp.lang.ada>

On 8 Jul 2004 07:06:15 -0500, Larry Kilgallen <Kilgallen@SpamCop.net>  
wrote:

> ...
> Did you look in section 13.9a of that document ?
> In particular, look for the word MECHANISM.

Aha! Eureka. Sort of.

> Certainly the mechanisms VALUE and REFERENCE are of general use.

Yes indeed, but they say nothing of the passing 'place' (specific  
register, or location in the stack frame, or wherever).

> The mechanism DESCRIPTOR is only for where a large variety of string
> representations are supported on the operating system.  For environments
> where data passed between languages will never include bounded strings,
> bit strings, non-contiguous arrays, then defaulting to your local form
> of DESCRIPTOR for a string starting at offset 1 is adequate.

As far as I'm concerned, the programmer must either specify or discover  
the actual format (in memory) of such parameters, and program (external or  
assembly) accordingly. In almost all cases, the type will be de facto be  
passed by reference, and so the passing place will (to my mind) be the  
place where the address is passed.

> You could add a mechanism called REGISTER,

It noe occurs to me that that would be confusing issues slightly, since a  
mechanism can be by-copy or by-reference, and in either case it can also  
be in-a-register or on-the-stack (or conceivably some other place).

> and if GNAT does this machine code insertion, I am surprised ACT
> has not added such a mechanism.

GNAT uses the GCC inline assembly syntax, which is transferred from GNU C,  
and rather unAdalike. I don't want to replicate it (it would actually be a  
lot of extra work to do so).

I'm very grateful for your help, Larry. All in all, however, I think I  
need something different to suit my own needs.

I think I will have two pragmas:

    pragma Parameter_Mechanism (
       [ENTITY    =>] callable_entity_simple_name,
       [PARAMETER =>] parameter_simple_name [,
       [MECHANISM =>] passing_mechanism] [,
       [PLACE     =>] passing_place] );

    pragma Return_Mechanism (
       [ENTITY    =>] callable_entity_simple_name,
       [MECHANISM =>] passing_mechanism] [,
       [PLACE     =>] passing_place] );

    passing_mechanism ::= BY_COPY | BY_REFERENCE

    passing_place ::= qualified_expression

The callable_entity_simple_name identifies the subprogram or entry. The  
pragma applies to the entity designated (regardless of the name), so  
renamings can be used to isolate one of a set of overloadings.

The qualified expression of a passing place must be of a subtype declared  
in System.Calling. For the IA-32, we might have the following declarations  
in this package:

    type Register_8  is ( AL,  CL,  DL,  BL,  AH,  CH,  DH,  BH); --  8-bit
    type Register_16 is ( AX,  CX,  DX,  BX,  SP,  BP,  SI,  DI); -- 16-bit
    type Register_32 is (EAX, ECX, EDX, EBX, ESP, EBP, ESI, EDI); -- 32-bit
    type Segment_Register is (ES, CS, SS, DS, FS, GS); -- 16-bit

    type Register_64 is
       record
          Upper, Lower: Register_32;
       end record;

    subtype Frame_Offset is Storage_Elements.Storage_Offset;
    -- Parameter or return value is to be located relative to the stack  
frame
    -- pointer (EBP) for a subprogram, or the beginning of the shared data  
area,
    -- for an entry.

In reality these would all be subtypes renaming types declared in another  
package.

Any obvious flaws?

-- 
Nick Roberts