Rough proposal to make some generic types static

Rough proposal to make some generic types static

[Victor Porton]

What in the RM signifies that Enum_Type (below) is not a static scalar
type?

We should work on an amendment for a future version of Ada to make
Enum_Type static.

Is it difficult to implement this?

Rationale is that the below code is useful in practice.

gnatmake -q -c -gnatc -u -P/home/porton/Projects/redland-bindings/ada/test.gpr -XRUNTIME=full -XMODE=Install rdf-auxilary.adb
rdf-auxilary.adb:7:25: non-static expression used for modular type bound
rdf-auxilary.adb:7:38: size attribute is only static for static scalar type (RM 4.9(7,8))

-- rdf.ads
package RDF is
end RDF;

-- rdf-auxilary.ads
with Interfaces.C;

package RDF.Auxilary is

   generic
      type Enum_Type is (<>);
   package Convert_Enum is
      function To_C(Argument: Enum_Type) return Interfaces.C.int;
      function From_C(Argument: Interfaces.C.int) return Enum_Type;
   end;

end RDF.Auxilary;

-- rdf-auxilary.adb
with Ada.Unchecked_Conversion;

package body RDF.Auxilary is

   package body Convert_Enum is

      type Small is mod 2**(Enum_Type'Size);

      function To_C_Internal is
        new Ada.Unchecked_Conversion (Source => Enum_Type, Target => Small);

      function From_C_Internal is
        new Ada.Unchecked_Conversion (Source => Small, Target => Enum_Type);

      function To_C(Argument: Enum_Type) return Interfaces.C.int is
      begin
         return Interfaces.C.int(To_C_Internal(Argument));
      end;

      function From_C(Argument: Interfaces.C.int) return Enum_Type is
      begin
         return From_C_Internal(Small(Argument));
      end;

   end;

end RDF.Auxilary;


-- 
Victor Porton - http://portonvictor.org

Re: Rough proposal to make some generic types static

[Victor Porton]

Victor Porton wrote:

> What in the RM signifies that Enum_Type (below) is not a static scalar
> type?

I've found: RM 4.9 26/3:

"A static scalar subtype is an unconstrained scalar subtype whose type is 
not a descendant of a formal type, or ..."

Why this rule? Can it be relaxed?

> We should work on an amendment for a future version of Ada to make
> Enum_Type static.
> 
> Is it difficult to implement this?
> 
> Rationale is that the below code is useful in practice.
> 
> gnatmake -q -c -gnatc -u
> -P/home/porton/Projects/redland-bindings/ada/test.gpr -XRUNTIME=full
> -XMODE=Install rdf-auxilary.adb rdf-auxilary.adb:7:25: non-static
> expression used for modular type bound rdf-auxilary.adb:7:38: size
> attribute is only static for static scalar type (RM 4.9(7,8))
> 
> -- rdf.ads
> package RDF is
> end RDF;
> 
> -- rdf-auxilary.ads
> with Interfaces.C;
> 
> package RDF.Auxilary is
> 
>    generic
>       type Enum_Type is (<>);
>    package Convert_Enum is
>       function To_C(Argument: Enum_Type) return Interfaces.C.int;
>       function From_C(Argument: Interfaces.C.int) return Enum_Type;
>    end;
> 
> end RDF.Auxilary;
> 
> -- rdf-auxilary.adb
> with Ada.Unchecked_Conversion;
> 
> package body RDF.Auxilary is
> 
>    package body Convert_Enum is
> 
>       type Small is mod 2**(Enum_Type'Size);
> 
>       function To_C_Internal is
>         new Ada.Unchecked_Conversion (Source => Enum_Type, Target =>
>         Small);
> 
>       function From_C_Internal is
>         new Ada.Unchecked_Conversion (Source => Small, Target =>
>         Enum_Type);
> 
>       function To_C(Argument: Enum_Type) return Interfaces.C.int is
>       begin
>          return Interfaces.C.int(To_C_Internal(Argument));
>       end;
> 
>       function From_C(Argument: Interfaces.C.int) return Enum_Type is
>       begin
>          return From_C_Internal(Small(Argument));
>       end;
> 
>    end;
> 
> end RDF.Auxilary;
> 
> 
-- 
Victor Porton - http://portonvictor.org

Re: Rough proposal to make some generic types static

[Niklas Holsti]

On 14-07-21 23:54 , Victor Porton wrote:
> Victor Porton wrote:
> 
>> What in the RM signifies that Enum_Type (below) is not a static scalar
>> type?

(Just as a reminder: Enum_Type is a formal type in a generic:

   generic
      type Enum_Type is (<>);
   ...
)

> I've found: RM 4.9 26/3:
> 
> "A static scalar subtype is an unconstrained scalar subtype whose type is 
> not a descendant of a formal type, or ..."
> 
> Why this rule? Can it be relaxed?

As I understand it, this rule (and others similar to it) allow compilers
to create "shared code" generics, that is, to compile a generic unit
into a single set of machine code that works for all instances of the
generic, thus reducing code size at the cost of possibly increasing
execution time.

One compiler using shared code generics is Janus/Ada from RR Software.

>> We should work on an amendment for a future version of Ada to make
>> Enum_Type static.
>>
>> Is it difficult to implement this?

It would probably make it impossible or very hard to compile shared code
for generic units.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Rough proposal to make some generic types static

[Victor Porton]

Niklas Holsti wrote:

> On 14-07-21 23:54 , Victor Porton wrote:
>> Victor Porton wrote:
>> 
>>> What in the RM signifies that Enum_Type (below) is not a static scalar
>>> type?
> 
> (Just as a reminder: Enum_Type is a formal type in a generic:
> 
>    generic
>       type Enum_Type is (<>);
>    ...
> )
> 
>> I've found: RM 4.9 26/3:
>> 
>> "A static scalar subtype is an unconstrained scalar subtype whose type is
>> not a descendant of a formal type, or ..."
>> 
>> Why this rule? Can it be relaxed?
> 
> As I understand it, this rule (and others similar to it) allow compilers
> to create "shared code" generics, that is, to compile a generic unit
> into a single set of machine code that works for all instances of the
> generic, thus reducing code size at the cost of possibly increasing
> execution time.

Really? How a compiler may create shared code when a formal scalar type may 
be of different sizes in different instantiations?

It seems for me, that it is anyway impossible to (efficiently) create 
"shared code" generics with formal scalar types.

So, I think my proposal remains in force.

> One compiler using shared code generics is Janus/Ada from RR Software.
> 
>>> We should work on an amendment for a future version of Ada to make
>>> Enum_Type static.
>>>
>>> Is it difficult to implement this?
> 
> It would probably make it impossible or very hard to compile shared code
> for generic units.

-- 
Victor Porton - http://portonvictor.org

Re: Rough proposal to make some generic types static

[Adam Beneschan]

On Monday, July 21, 2014 1:44:21 PM UTC-7, Victor Porton wrote:
> What in the RM signifies that Enum_Type (below) is not a static scalar
> type?
> 
> We should work on an amendment for a future version of Ada to make
> Enum_Type static?
> 
> Is it difficult to implement this?
> 
> Rationale is that the below code is useful in practice.
> 

Generics in the Ada language are designed so that they can be implemented either by "macro expansion" or "code sharing" [1].  In macro expansion, every time you instantiate a generic, the compiler treats it as if you had written all the code, substituting actual for formal types; the compiler thus generates code for each instantiation.  In code sharing, the compiler generates the code for the generic *once*, when it sees the generic; when you instantiate the generic, the compiler arranges things so that all the information it needs to know about the actual types is passed as parameters.

Using code sharing, it is not feasible for the compiler to generate code for a modular type if it doesn't know the type size in advance.  (Or at least that was the thinking when the decision was made to require the modulus to be static.  It may actually be possible to generate reasonably efficient code when the modulus is specifically of the form 2**N, where N is non-static.)

But, anyway, that's the rationale.

                                -- Adam


[1] Note that the language specification doesn't actually refer to those two models.  So if someone came up with a third model that would obey all the Ada rules, that would be legal also.

Re: Rough proposal to make some generic types static

[Niklas Holsti]

On 14-07-22 00:32 , Victor Porton wrote:
> Niklas Holsti wrote:
> 
>> On 14-07-21 23:54 , Victor Porton wrote:
>>> Victor Porton wrote:
>>>
>>>> What in the RM signifies that Enum_Type (below) is not a static scalar
>>>> type?
>>
>> (Just as a reminder: Enum_Type is a formal type in a generic:
>>
>>    generic
>>       type Enum_Type is (<>);
>>    ...
>> )
>>
>>> I've found: RM 4.9 26/3:
>>>
>>> "A static scalar subtype is an unconstrained scalar subtype whose type is
>>> not a descendant of a formal type, or ..."
>>>
>>> Why this rule? Can it be relaxed?
>>
>> As I understand it, this rule (and others similar to it) allow compilers
>> to create "shared code" generics, that is, to compile a generic unit
>> into a single set of machine code that works for all instances of the
>> generic, thus reducing code size at the cost of possibly increasing
>> execution time.
> 
> Really?

Yes.

> How a compiler may create shared code when a formal scalar type may 
> be of different sizes in different instantiations?

Perhaps Randy Brukardt can explain how Janus/Ada does it.

There used to be other code-sharing Ada compilers -- TLD-Ada for the
MIL-1750 processors comes to mind -- but as the memory sizes available
in embedded systems increased, the "macro generic" approach became more
popular.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Rough proposal to make some generic types static

[Victor Porton]

Adam Beneschan wrote:

> On Monday, July 21, 2014 1:44:21 PM UTC-7, Victor Porton wrote:
>> What in the RM signifies that Enum_Type (below) is not a static scalar
>> type?
>> 
>> We should work on an amendment for a future version of Ada to make
>> Enum_Type static?
>> 
>> Is it difficult to implement this?
>> 
>> Rationale is that the below code is useful in practice.
>> 
> 
> Generics in the Ada language are designed so that they can be implemented
> either by "macro expansion" or "code sharing" [1].  In macro expansion,
> every time you instantiate a generic, the compiler treats it as if you had
> written all the code, substituting actual for formal types; the compiler
> thus generates code for each instantiation.  In code sharing, the compiler
> generates the code for the generic *once*, when it sees the generic; when
> you instantiate the generic, the compiler arranges things so that all the
> information it needs to know about the actual types is passed as
> parameters.

I am not an expert in compiler optimization, but it looks anyway impossible 
for me to make efficient shared code for formal scalar types of possibly 
different sizes.

So, if I understand correctly, it cannot work this way anyway, and allowing 
static formal scalar types would not make this optimization worse.

> Using code sharing, it is not feasible for the compiler to generate code
> for a modular type if it doesn't know the type size in advance.  (Or at
> least that was the thinking when the decision was made to require the
> modulus to be static.  It may actually be possible to generate reasonably
> efficient code when the modulus is specifically of the form 2**N, where N
> is non-static.)
> 
> But, anyway, that's the rationale.
> 
>                                 -- Adam
> 
> 
> [1] Note that the language specification doesn't actually refer to those
> [two models.  So if someone came up with a third model that would obey all
> [the Ada rules, that would be legal also.

-- 
Victor Porton - http://portonvictor.org

Re: Rough proposal to make some generic types static

[Adam Beneschan]

On Monday, July 21, 2014 2:44:35 PM UTC-7, Victor Porton wrote:
> Adam Beneschan wrote:

> I am not an expert in compiler optimization, but it looks anyway impossible 
> for me to make efficient shared code for formal scalar types of possibly 
> different sizes.

Some users care more about code space than execution time.  There are lots of systems out there where memory space is severely limited.  And I think that was part of the intended market when Ada was designed.

                             -- Adam

Re: Rough proposal to make some generic types static

[Victor Porton]

Adam Beneschan wrote:

> On Monday, July 21, 2014 2:44:35 PM UTC-7, Victor Porton wrote:
>> Adam Beneschan wrote:
> 
>> I am not an expert in compiler optimization, but it looks anyway
>> impossible for me to make efficient shared code for formal scalar types
>> of possibly different sizes.
> 
> Some users care more about code space than execution time.  There are lots
> of systems out there where memory space is severely limited.  And I think
> that was part of the intended market when Ada was designed.

I do not say that sharing code is not useful. I say that (in my opinion) it 
is just too hard to implement (efficiently enough) in certain cases, such as 
when we have a formal scalar type, because its size in bytes may vary.

If it does not work anyway, we do not lose dismissing it.

-- 
Victor Porton - http://portonvictor.org

Re: Rough proposal to make some generic types static

[Shark8]

On 21-Jul-14 15:54, Adam Beneschan wrote:
> There are lots of systems out there where memory space is severely limited.
> And I think that was part of the intended market when Ada was designed.

The other case where shared-generics can be useful is where you need to 
verify the output-objects of the compiler... being able to do this once 
for all instantiations would be a win in the long run.

Re: Rough proposal to make some generic types static

[Randy Brukardt]

"Victor Porton" <porton@narod.ru> wrote in message 
news:lqk0t0$29n$1@speranza.aioe.org...
> Niklas Holsti wrote:
>> On 14-07-21 23:54 , Victor Porton wrote:
..
>>> I've found: RM 4.9 26/3:
>>>
>>> "A static scalar subtype is an unconstrained scalar subtype whose type 
>>> is
>>> not a descendant of a formal type, or ..."
>>>
>>> Why this rule? Can it be relaxed?
>>
>> As I understand it, this rule (and others similar to it) allow compilers
>> to create "shared code" generics, that is, to compile a generic unit
>> into a single set of machine code that works for all instances of the
>> generic, thus reducing code size at the cost of possibly increasing
>> execution time.

There are other reasons as well. Since "static" isn't declared, you'd be 
able to break the contract model of generics by using the type in the body 
as static. If the actual isn't static, the instantiation would have to be 
rejected -- but how could the compiler know? The body may not have been 
compiled yet.

In general, Ada using "assume-the-worst" rules in generic bodies, and this 
is one such rule.

Also, note that outside of the instance, the formal type can act as 
static -- the rule you note only applies within the generic unit.

> Really? How a compiler may create shared code when a formal scalar type 
> may
> be of different sizes in different instantiations?

Lots of work. :-)

Actually, it's not that hard. As I recall from classes back at the 
University of Wisconsin, there is no (programming) problem that can't be 
solved with a level of indirection.

> It seems for me, that it is anyway impossible to (efficiently) create
> "shared code" generics with formal scalar types.

Not at all true. Partly because there is no such thing as a formal scalar 
type. :-) For the individual kinds of formal scalars (discrete, float, etc.) 
you do all of the operations using the size of the largest type; so long as 
that type is efficient on the target processor, there's little issue.

The problems come from formal arrays and from formal derived types, but 
those are used rarely and thus highly efficient solutions aren't needed.

> So, I think my proposal remains in force.

You certainly have a way of making enemies around here. The rules in the 
standard have good reasons in almost all cases, and one has

Anyway, you'd have to solve the generic contract problems first. One way 
would be to have a "static" aspect on the formal, which would require the 
actual to be static and that would allow the formal to be used as static. 
That would put staticness into the contract. But it would be unusual 
(staticness is not part of the contract in any part of Ada, for better or 
worse), and it would require a fairly important problem to make such a 
change. (In addition, it would be over my dead body, but forget that for the 
moment.)

I don't think your problem rises to that level. The only reason for writing 
a generic like the one your showed is if your compiler is not properly 
matching the behavior of enumeration matching for convention C. In such a 
case, you'd be best off writing each such package separately, because it 
means that there is no obvious correlation between what the C (or C++) 
compiler is doing and the type declaration. You'll have to match up the 
modular types with the enumerations.

For instance, Janus/Ada would potentially use 24-bit types for the modular 
type; I doubt that any C or C++ compiler would do that. The generic wouldn't 
work reliably even if it compiled.

                                                 Randy.



>> One compiler using shared code generics is Janus/Ada from RR Software.
>>
>>>> We should work on an amendment for a future version of Ada to make
>>>> Enum_Type static.
>>>>
>>>> Is it difficult to implement this?
>>
>> It would probably make it impossible or very hard to compile shared code
>> for generic units.
>
> -- 
> Victor Porton - http://portonvictor.org 

Re: Rough proposal to make some generic types static

[Randy Brukardt]

"Victor Porton" <porton@narod.ru> wrote in message 
news:lqk1k5$3r1$1@speranza.aioe.org...
...
> I am not an expert in compiler optimization, but it looks anyway 
> impossible
> for me to make efficient shared code for formal scalar types of possibly
> different sizes.

(1) you're wrong, and (2) there's nothing in the Ada standard that requires 
code to be efficient! If there was, some constructs would be impossible (ATC 
comes to mind).

                        Randy.

Re: Rough proposal to make some generic types static

[Randy Brukardt]

"Victor Porton" <porton@narod.ru> wrote in message 
news:lqk2ej$3r1$4@speranza.aioe.org...
> Adam Beneschan wrote:
>
>> On Monday, July 21, 2014 2:44:35 PM UTC-7, Victor Porton wrote:
>>> Adam Beneschan wrote:
>>
>>> I am not an expert in compiler optimization, but it looks anyway
>>> impossible for me to make efficient shared code for formal scalar types
>>> of possibly different sizes.
>>
>> Some users care more about code space than execution time.  There are 
>> lots
>> of systems out there where memory space is severely limited.  And I think
>> that was part of the intended market when Ada was designed.
>
> I do not say that sharing code is not useful. I say that (in my opinion) 
> it
> is just too hard to implement (efficiently enough) in certain cases, such 
> as
> when we have a formal scalar type, because its size in bytes may vary.
>
> If it does not work anyway, we do not lose dismissing it.

Of course it works. And what do we lose by dismissing it:
(1) The possibility of having slim executables. Compare the .exe size for 
Janus/Ada and GNAT on Windows to see what I mean.
(2) Janus/Ada - there is no practical way for it ever to use macro-expanded 
generics (it would take 2-3 man years to build, and there's lots of other 
stuff that effort would be better used on).
(3) Me. If Janus/Ada goes, I leave Ada because there would be no point in 
hanging on further. (A sensible person would say that I passed that point 
10+ years ago.) Thus, Ada would need a new standards editor, ACATS manager, 
and so on. Most likely, a lot of stuff would fall out of maintenance and/or 
just get lost.

                                Randy.

Re: Rough proposal to make some generic types static

[AdaMagica]

On Tuesday, July 22, 2014 1:12:51 AM UTC+2, Randy Brukardt wrote:

> (1) you're wrong, and (2) there's nothing in the Ada standard that requires 
> code to be efficient! If there was, some constructs would be impossible (ATC 
> comes to mind).
>
>                         Randy.

Hm, there's Introduction(6/3):

Ada was originally designed with three overriding concerns: program reliability and maintenance, programming as a human activity, and efficiency.

Re: Rough proposal to make some generic types static

[Randy Brukardt]

"AdaMagica" <christ-usch.grein@t-online.de> wrote in message 
news:37b276da-6260-4bc7-8090-702142391a4f@googlegroups.com...
> On Tuesday, July 22, 2014 1:12:51 AM UTC+2, Randy Brukardt wrote:
>
>> (1) you're wrong, and (2) there's nothing in the Ada standard that 
>> requires
>> code to be efficient! If there was, some constructs would be impossible 
>> (ATC
>> comes to mind).
>>
>>                         Randy.
>
> Hm, there's Introduction(6/3):
>
> Ada was originally designed with three overriding concerns: program 
> reliability
> and maintenance, programming as a human activity, and efficiency.

That's the language as a whole, not a particular feature. Moreover, even if 
a feature can be implemented efficiently in a vacuum, there often are other 
concerns that affect the ability to do so. (For example, the need to make 
convention C work properly.)

                             Randy.

Re: Rough proposal to make some generic types static

[Robert A Duff]

Victor Porton <porton@narod.ru> writes:

> I do not say that sharing code is not useful. I say that (in my opinion) it 
> is just too hard to implement (efficiently enough) in certain cases, such as 
> when we have a formal scalar type, because its size in bytes may vary.

You could have (say) two pieces of code for the generic body, one shared
by all instances that pass a scalar that fits in 32 bits, and one shared
by all those that need 64 bits.

Or more generally, two instances of a generic could share code only if
the actual parameters are similar enough that it can be done efficiently.

- Bob