* Re: Pure Aspect on Library-Level Function
@ 2021-02-11 2:53 4% ` Randy Brukardt
0 siblings, 0 replies; 123+ results
From: Randy Brukardt @ 2021-02-11 2:53 UTC (permalink / raw)
I agree with Christoph. The very last Ada 202x AI (because it's the only one
that I haven't finished yet) obsolesces all of the categorization pragmas,
only defining the aspects in the core. So it will be crystal clear in the
updated RM that the aspects apply to all compilation units (the pragmas
having moved to Annex J). (All of the language-defined packages also have
been changed to use aspects - that was a job I was working on today - I
believe there will be only a single pragma left in the entire Ada library (a
single "Elaborate_All", in Interfaces.Fortran).
This probably is just an oversight in compiler O.
BTW, these aspects are implemented in Janus/Ada (and have been for a while);
if I'm reading the code right, they should should be allowed on any library
unit. So Janus/Ada agrees with compiler G.
Randy.
"AdaMagica" <christ-usch.grein@t-online.de> wrote in message
news:317ba71f-f049-4bbd-8da3-cc8dc1637eaan@googlegroups.com...
> Hm, I worked thru the RM and think compiler O(bject Ada?) is incorrect.
> But I'm not a language lawyer.
> A subprogram ceclaration is a library unit.
> 10.2.1(17) A pragma Pure is used to specify that a library unit is
> declared pure, namely that the Pure aspect of the library unit is True
> 6.1(2) subprogram_declaration ::=
> [overriding_indicator]
> subprogram_specification
> [aspect_specification];
> Thus it seems the aspect can be defined via a pragma or via an aspect
> specification.
^ permalink raw reply [relevance 4%]
* Re: Making the same mistake as the broken C interface to fortran
2019-07-05 17:44 0% ` Simon Wright
@ 2019-07-07 16:33 0% ` Chris M Moore
0 siblings, 0 replies; 123+ results
From: Chris M Moore @ 2019-07-07 16:33 UTC (permalink / raw)
On 05/07/2019 18:44, Simon Wright wrote:
> Chris M Moore <zmower@ntlworld.com> writes:
>
>> On 04/07/2019 09:38, Simon Wright wrote:
>>> procedure Call is
>>> procedure Callee_C (C : Character)
>>> with
>>> Import,
>>> Convention => Fortran,
>>> External_Name => "callee_";
>>> procedure Callee_F (C : Interfaces.Fortran.Fortran_Character)
>>> with
>>> Import,
>>> Convention => Fortran,
>>> External_Name => "callee_";
>>> procedure Callee_S (S : String)
>>> with
>>> Import,
>>> Convention => Fortran,
>>> External_Name => "callee_";
>>> begin
>>> Callee_C ('c');
>>
>> I've looked at the assembler for this. Passing 'c' results in only a
>> byte pushed to the stack. And then (aha!) the address on the stack is
>> placed in the rdi register.
>
> Because all Fortran parameters are passed by reference.
I spoke too soon when I said
> I'm sure GNAT does the right thing if you're using Fortran_Character.
If I change callee.f to
subroutine callee (c)
character (len=*), intent (in) :: c
print *, 'parameter c is ', c
end
then STORAGE_ERROR is the order of the day no matter the call used.
Looking at the assembler, this is because GNAT does not pass the length
of the string.
I compared it to fcall.f:
program fcall
call callee("OK")
call callee("Oh noes")
stop
end
and this unsurprisingly does pass the lengths.
I've used the webform on the Community section of the GNAT website to
provide feedback. I've pointed out that the issue also affects single
chacter parameters.
Chris
--
sig pending (since 1995)
^ permalink raw reply [relevance 0%]
* Re: Making the same mistake as the broken C interface to fortran
2019-07-05 13:49 0% ` Chris M Moore
@ 2019-07-05 17:44 0% ` Simon Wright
2019-07-07 16:33 0% ` Chris M Moore
0 siblings, 1 reply; 123+ results
From: Simon Wright @ 2019-07-05 17:44 UTC (permalink / raw)
Chris M Moore <zmower@ntlworld.com> writes:
> On 04/07/2019 09:38, Simon Wright wrote:
>> procedure Call is
>> procedure Callee_C (C : Character)
>> with
>> Import,
>> Convention => Fortran,
>> External_Name => "callee_";
>> procedure Callee_F (C : Interfaces.Fortran.Fortran_Character)
>> with
>> Import,
>> Convention => Fortran,
>> External_Name => "callee_";
>> procedure Callee_S (S : String)
>> with
>> Import,
>> Convention => Fortran,
>> External_Name => "callee_";
>> begin
>> Callee_C ('c');
>
> I've looked at the assembler for this. Passing 'c' results in only a
> byte pushed to the stack. And then (aha!) the address on the stack is
> placed in the rdi register.
Because all Fortran parameters are passed by reference.
^ permalink raw reply [relevance 0%]
* Re: Making the same mistake as the broken C interface to fortran
2019-07-04 8:38 6% ` Simon Wright
@ 2019-07-05 13:49 0% ` Chris M Moore
2019-07-05 17:44 0% ` Simon Wright
0 siblings, 1 reply; 123+ results
From: Chris M Moore @ 2019-07-05 13:49 UTC (permalink / raw)
On 04/07/2019 09:38, Simon Wright wrote:
> Chris M Moore <zmower@ntlworld.com> writes:
>
>> On 03/07/2019 20:02, Randy Brukardt wrote:
>>> "Chris M Moore" <zmower@ntlworld.com> wrote in message
>>> news:2uYSE.298383$sJ3.119314@fx04.am4...
>>> ...
>>>> So the question is do we break the API or not?
>>>
>>> That's not the question. The question is ensuring that the Ada
>>> compiler properly implements the Fortran convention. If it does, then
>>> the API doesn't change. And if it doesn't, then fix the silly
>>> compiler (or get a different one that does the right thing). The
>>> Annex B "Implementation Advice" (specifically, B.5(22-26)) is very
>>> close to a requirement, in that the interface is not useful if one
>>> can't depend on the mapping.
>>>
>> <snip>
>>>
>>> BTW, I note that type Fortran_Character is in fact an array type, so
>>> that could be confusing some readers of the API (it surely would have
>>> confused me).
>
> It confused the heck out of me, too. You'd've expected a warning at
> least if you use a dodgy parameter type!
Agreed.
> I did a little poking around with GCC 9.1.0:
>
> Fortran:
>
> subroutine callee (c)
> character (1), intent (in) :: c
>
> print *, 'parameter c is ', c
>
> end
I'm having flashbacks. Send help. ;)
> Ada:
>
> with Interfaces.Fortran;
> procedure Call is
> procedure Callee_C (C : Character)
> with
> Import,
> Convention => Fortran,
> External_Name => "callee_";
> procedure Callee_F (C : Interfaces.Fortran.Fortran_Character)
> with
> Import,
> Convention => Fortran,
> External_Name => "callee_";
> procedure Callee_S (S : String)
> with
> Import,
> Convention => Fortran,
> External_Name => "callee_";
> begin
> Callee_C ('c');
I've looked at the assembler for this. Passing 'c' results in only a
byte pushed to the stack. And then (aha!) the address on the stack is
placed in the rdi register.
> Callee_F ((1 => 'f'));
> Callee_F ("F string");
> Callee_S ("A string");
These pass the address of a fixed string (in the ro text area) in the
rdi register.
> end Call;
>
> Result:
>
> $ gfortran -c callee.f
> $ gnatmake -gnatwa call.adb -largs callee.o -lgfortran
> gcc -c -gnatwa call.adb
> gnatbind -x call.ali
> gnatlink call.ali callee.o -lgfortran
> $ ./call
> parameter c is > parameter c is f
> parameter c is F
> parameter c is A
So it works at the moment for the small example we have.
>> I'm sure GNAT does the right thing if you're using
>> Fortran_Character. Unfortunately the bindings use Standard.Character.
>
> Which bindings are those?
I was looking at the LAPACK ones on sourceforge.
> I can certainly look at changing the ones in
> gnat-math-extn (Should be https://sf.net/p/gnat-math-extn, but down at
> the moment), but those are entirely internal.
I'd wait until we have conclusive proof we have a problem. I'll do some
more digging.
<snip>
--
sig pending (since 1995)
^ permalink raw reply [relevance 0%]
* Re: Making the same mistake as the broken C interface to fortran
@ 2019-07-04 8:38 6% ` Simon Wright
2019-07-05 13:49 0% ` Chris M Moore
0 siblings, 1 reply; 123+ results
From: Simon Wright @ 2019-07-04 8:38 UTC (permalink / raw)
Chris M Moore <zmower@ntlworld.com> writes:
> On 03/07/2019 20:02, Randy Brukardt wrote:
>> "Chris M Moore" <zmower@ntlworld.com> wrote in message
>> news:2uYSE.298383$sJ3.119314@fx04.am4...
>> ...
>>> So the question is do we break the API or not?
>>
>> That's not the question. The question is ensuring that the Ada
>> compiler properly implements the Fortran convention. If it does, then
>> the API doesn't change. And if it doesn't, then fix the silly
>> compiler (or get a different one that does the right thing). The
>> Annex B "Implementation Advice" (specifically, B.5(22-26)) is very
>> close to a requirement, in that the interface is not useful if one
>> can't depend on the mapping.
>>
> <snip>
>>
>> BTW, I note that type Fortran_Character is in fact an array type, so
>> that could be confusing some readers of the API (it surely would have
>> confused me).
It confused the heck out of me, too. You'd've expected a warning at
least if you use a dodgy parameter type!
I did a little poking around with GCC 9.1.0:
Fortran:
subroutine callee (c)
character (1), intent (in) :: c
print *, 'parameter c is ', c
end
Ada:
with Interfaces.Fortran;
procedure Call is
procedure Callee_C (C : Character)
with
Import,
Convention => Fortran,
External_Name => "callee_";
procedure Callee_F (C : Interfaces.Fortran.Fortran_Character)
with
Import,
Convention => Fortran,
External_Name => "callee_";
procedure Callee_S (S : String)
with
Import,
Convention => Fortran,
External_Name => "callee_";
begin
Callee_C ('c');
Callee_F ((1 => 'f'));
Callee_F ("F string");
Callee_S ("A string");
end Call;
Result:
$ gfortran -c callee.f
$ gnatmake -gnatwa call.adb -largs callee.o -lgfortran
gcc -c -gnatwa call.adb
gnatbind -x call.ali
gnatlink call.ali callee.o -lgfortran
$ ./call
parameter c is c
parameter c is f
parameter c is F
parameter c is A
> I'm sure GNAT does the right thing if you're using
> Fortran_Character. Unfortunately the bindings use Standard.Character.
Which bindings are those? I can certainly look at changing the ones in
gnat-math-extn (Should be https://sf.net/p/gnat-math-extn, but down at
the moment), but those are entirely internal.
====================
For what it's worth, the issue is that a long-standing feature of the
Fortran ABI is that 'character' is an array type, so that the fat
parameter contains (1) the address of the first element and (2) the
length of the actual (I'm not sure whether these two parts are
necessarily contiguous). If the Fortran only ever accesses the first
element, it doesn't matter if the length part is never actually passed
on the stack, which is what happens when Ada or C passes Character or
char rsp.
However, with a new optimisation, if the Fortran compiler recognises an
opportunity for "tail recursion" (or a sibling call), it reuses
the current stack arguments for the sibling call, including the length
component of the character argument. If that length component was never
actually pushed by the original caller, oops, trashed stack.
^ permalink raw reply [relevance 6%]
* Re: Statistics
@ 2014-04-09 9:52 6% ` Simon Wright
0 siblings, 0 replies; 123+ results
From: Simon Wright @ 2014-04-09 9:52 UTC (permalink / raw)
"J-P. Rosen" <rosen@adalog.fr> writes:
> Le 09/04/2014 08:37, Simon Wright a écrit :
>> If you need asymmetric matrices, you might find Ada 2005 Math Extensions
>> useful.
>>
>> http://sourceforge.net/projects/gnat-math-extn/
> Out of curiosity: it is presented as Gnat-specific. Why?
It used to use Interfaces.Fortran.BLAS, which was removed in GNAT GPL
2012/GCC 4.7. AdaCore reimplemented Ada.Numerics to improve portability
(to systems that don't have BLAS, LAPACK) at the expense of performance.
The body of Ada_Numerics.Generic_Arrays now says
with Interfaces.Fortran;
with System.Generic_Array_Operations;
and I think the latter is a GNAT unit? (of course, anyone could copy it;
it doesn't look unusual aside from a pragma Inline_Always).
Also, I don't have any other Ada 2005 compiler!
The library needs BLAS and LAPACK, easy enough on Mac OS X and Debian,
apparently a PITA on Windows.
^ permalink raw reply [relevance 6%]
* Re: A thicker binding for Lapack
@ 2013-01-01 0:24 6% ` jpwoodruff
0 siblings, 0 replies; 123+ results
From: jpwoodruff @ 2013-01-01 0:24 UTC (permalink / raw)
On Sunday, December 30, 2012 12:41:54 PM UTC-7, Simon Wright wrote:
> jpwoodruff@gmail.com writes:
>
>
>
> > On Saturday, December 29, 2012 12:59:46 PM UTC-7, Simon Wright wrote:
>
> >> jpwoodruff@gmail.com writes:
>
> >>
>
> >> > Conclusion: transpose appears necessary.
>
> >>
>
> >> For info, the compiler (well, GNAT) will automatically transpose when
>
> >> doing assignment between arrays with different conventions. And it's
>
> >> quicker (not by very much at -O2, though).
>
> >>
>
> >
>
> > I'll be darned. You are both right about pragma Convention. I am
>
> > going to unwrite some code. Even my old gnat gpl 2010 got it right.
>
> > I need to (re)learn to trust Lady Ada.
>
> >
>
> >
>
> > From Simon's context, I found System.Generic_Real_LAPACK. There is
>
> > quite a lot there. I want to spend some time reading that, then
>
> > determine if (as I suspect) the problem I stated has already been
>
> > solved by the structures there.
>
>
>
> System.Generic_Real_LAPACK looks a bit off to me - lots of unchecked
>
> conversions of address-of-array into access-to-another-array-type. But
>
> it may do what you need.
>
>
>
> NB, GNATs later than GCC 4.6 or GNAT GPL 2010 don't use LAPACK or
>
> BLAS. I wrote a bit about this on comp.lang.ada at [1].
>
>
>
> [1] http://coding.derkeiler.com/Archive/Ada/comp.lang.ada/2012-07/msg00138.html
I'm uncertain about what Ada lapack materials are in play. Please
help me get the story of the several variations straight.
about System.Generic_Real_LAPACK --
Is it true that this structure that I see in my gpl 2010 is obsolete?
Has it been removed in later gnats? Has interfaces.fortran.lapack met
the same fate?
About lapack.ads on sourceforge, attributed to NMA and SJW: --
Is this in fact the only low-level binding to the Fortran linear
algebra subroutines?
Properties of lapack.ads:
- largely auto-generated.
- covers the entire lapack library: single, double precision, real
and complex.
- defines array types with components and indices specified from
types defined by interfaces.fortran.
- uses pragma fortran for vector and matrix array types.
Evidently conversion between columnwise and row-wise storage is
handled transparently by Ada language specification of pragma.
Transparent transposition happens on assignment (but not on parameter
elaboration?). Some testing is in order here.
I considered enumerating the properties of System.Generic_Real_LAPACK
but if it's leaving, why bother?
John
^ permalink raw reply [relevance 6%]
* Re: A thicker binding for Lapack
@ 2012-12-29 19:59 8% ` Simon Wright
0 siblings, 1 reply; 123+ results
From: Simon Wright @ 2012-12-29 19:59 UTC (permalink / raw)
jpwoodruff@gmail.com writes:
> Conclusion: transpose appears necessary.
For info, the compiler (well, GNAT) will automatically transpose when
doing assignment between arrays with different conventions. And it's
quicker (not by very much at -O2, though).
with Ada.Calendar; use Ada.Calendar;
with Ada.Text_IO; use Ada.Text_IO;
with Ada.Numerics.Float_Random;
with Interfaces.Fortran;
with System.Generic_Array_Operations;
procedure Sauvage_Timing is
package BLAS is
-- Copied from old GNAT Interfaces.Fortran.BLAS.
-- Vector types
type Real_Vector is array (Integer range <>)
of Interfaces.Fortran.Real;
type Complex_Vector is array (Integer range <>)
of Interfaces.Fortran.Complex;
type Double_Precision_Vector is array (Integer range <>)
of Interfaces.Fortran.Double_Precision;
type Double_Complex_Vector is array (Integer range <>)
of Interfaces.Fortran.Double_Complex;
-- Matrix types
type Real_Matrix is array (Integer range <>, Integer range <>)
of Interfaces.Fortran.Real;
type Double_Precision_Matrix
is array (Integer range <>, Integer range <>)
of Interfaces.Fortran.Double_Precision;
type Complex_Matrix is array (Integer range <>, Integer range <>)
of Interfaces.Fortran.Complex;
type Double_Complex_Matrix is array (Integer range <>, Integer range <>)
of Interfaces.Fortran.Double_Complex;
end BLAS;
procedure Transpose
is new System.Generic_Array_Operations.Transpose
(Scalar => Interfaces.Fortran.Double_Precision'Base,
Matrix => BLAS.Double_Precision_Matrix);
type Double_Precision_Matrix is array (Integer range <>, Integer range <>)
of Interfaces.Fortran.Double_Precision;
pragma Convention (Fortran, Double_Precision_Matrix);
A, B : BLAS.Double_Precision_Matrix (1 .. 100, 1 .. 100);
C : Double_Precision_Matrix (1 .. 100, 1 .. 100);
pragma Volatile (B);
pragma Volatile (C);
Gen : Ada.Numerics.Float_Random.Generator;
Start, Finish : Time;
use type Interfaces.Fortran.Double_Precision;
begin
Ada.Numerics.Float_Random.Reset (Gen);
for J in A'Range (1) loop
for K in A'Range (2) loop
A (J, K) :=
Interfaces.Fortran.Double_Precision (J * K)
* Interfaces.Fortran.Double_Precision
(Ada.Numerics.Float_Random.Random (Gen));
end loop;
end loop;
Start := Clock;
for J in 1 .. 100 loop
Transpose (A, B);
end loop;
Finish := Clock;
Put_Line ("Transpose took " & Duration'Image (Finish - Start));
Start := Clock;
for J in 1 .. 100 loop
C := Double_Precision_Matrix (A);
end loop;
Finish := Clock;
Put_Line ("Assignment took" & Duration'Image (Finish - Start));
declare
Same : Boolean := True;
begin
for J in 1 .. 100 loop
for K in 1 .. 100 loop
if B (J, K) /= C (K, J) then
Same := False;
end if;
end loop;
end loop;
Put_Line ("B = ~C: " & Same'Img);
end;
end Sauvage_Timing;
^ permalink raw reply [relevance 8%]
* Re: fyi, small update to Ada LAPACK and BLAS binding
2012-07-31 6:37 5% fyi, small update to Ada LAPACK and BLAS binding Nasser M. Abbasi
@ 2012-07-31 8:59 0% ` Niklas Holsti
0 siblings, 0 replies; 123+ results
From: Niklas Holsti @ 2012-07-31 8:59 UTC (permalink / raw)
On 12-07-31 09:37 , Nasser M. Abbasi wrote:
> Here is a complete example using LAPACK from Ada, with the gnatmake
> command to build it:
>
> gnatmake -Iada_lapack/binding mysolve.adb -largs -L/usr/lib -lblas -llapack
>
> ------ mysolve.adb -------------------------------------
> with Ada.Text_IO; use Ada.Text_IO;
>
> with Interfaces.Fortran; use Interfaces.Fortran;
> with lapack;
>
> procedure mysolve is
>
> A : lapack.Fortran_Real_Matrix (1 .. 3, 1 .. 3);
> b : lapack.Fortran_Real_Matrix (1 .. 3, 1 .. 1);
> info : Fortran_Integer;
> ipiv : lapack.Fortran_Integer_Vector (1 .. A'Last (2));
>
> begin -- solve A x=b
>
> A := ((2.0, 3.0, 1.0), (2.0, 1.0, 1.0), (4.0, -1.0, 6.0));
> b := ((1 => 9.0), (1 => 2.0), (1 => -2.0));
>
> lapack.SGESV
> (N => A'Last (2),
Wouldn't A'Length(2) be more to the point? And the same for the other
uses of 'Last below. Of course, when 'First = 1 then 'Length = 'Last,
but just as a general point of principle...
> NRHS => b'Last (2),
> A => A,
> LDA => A'Last (1),
> IPIV => ipiv,
> B => b,
> LDB => b'Last (1),
> INFO => info);
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
^ permalink raw reply [relevance 0%]
* fyi, small update to Ada LAPACK and BLAS binding
@ 2012-07-31 6:37 5% Nasser M. Abbasi
2012-07-31 8:59 0% ` Niklas Holsti
0 siblings, 1 reply; 123+ results
From: Nasser M. Abbasi @ 2012-07-31 6:37 UTC (permalink / raw)
FYI;
I've added more documentation and made a little cleanup of the
current Ada LAPACK and BLAS bindings.
As per earlier thread, this snap shot of the LAPACK binding now
uses one package to interface to LAPACK so it is easier to use.
The location is still the same as before, and with more
documentation now how to use the bindings.
http://12000.org/my_notes/ada/index.htm
I have a zip file the the LAPACK and BLAS updates I made there
with links to the original versions
Here is a complete example using LAPACK from Ada, with the gnatmake
command to build it:
gnatmake -Iada_lapack/binding mysolve.adb -largs -L/usr/lib -lblas -llapack
------ mysolve.adb -------------------------------------
with Ada.Text_IO; use Ada.Text_IO;
with Interfaces.Fortran; use Interfaces.Fortran;
with lapack;
procedure mysolve is
A : lapack.Fortran_Real_Matrix (1 .. 3, 1 .. 3);
b : lapack.Fortran_Real_Matrix (1 .. 3, 1 .. 1);
info : Fortran_Integer;
ipiv : lapack.Fortran_Integer_Vector (1 .. A'Last (2));
begin -- solve A x=b
A := ((2.0, 3.0, 1.0), (2.0, 1.0, 1.0), (4.0, -1.0, 6.0));
b := ((1 => 9.0), (1 => 2.0), (1 => -2.0));
lapack.SGESV
(N => A'Last (2),
NRHS => b'Last (2),
A => A,
LDA => A'Last (1),
IPIV => ipiv,
B => b,
LDB => b'Last (1),
INFO => info);
if (info /= 0) then
raise Program_Error;
end if;
declare
package real_IO is new Ada.Text_IO.Float_IO (Real);
begin
for I in b'Range (1) loop
real_IO.Put (b (I, 1));
New_Line;
end loop;
end;
end mysolve;
-----------------------
--Nasser
^ permalink raw reply [relevance 5%]
* Re: basic question on nested packages
@ 2012-07-28 9:01 5% ` Nasser M. Abbasi
0 siblings, 0 replies; 123+ results
From: Nasser M. Abbasi @ 2012-07-28 9:01 UTC (permalink / raw)
On 7/28/2012 12:36 AM, Shark8 wrote:
> On Friday, July 27, 2012 11:27:31 PM UTC-6, Nasser M. Abbasi wrote:
>> On 7/27/2012 10:22 PM, Nasser M. Abbasi wrote:
>>
>>>
>>> What I think would be better is to have ONE lapack package and
>>> with the above packages as nested packages.
>> ref (me)
>>
>> I think may be I need to use 'child packages', not 'nested pacakges',
>> but not sure yet.
>>
>> I am doing a crash course now reading an ada book to learn more
>> the difference between these and which one to use....
>
> You could likely use nested packages; though child packages will likely be better
>for maintainability, but if they're short/simple child packages make good sense.
>
Yes, this is what I ended up doing. It was easier that I thought.
Now the lapack client has this:
----------------------------
with Ada.Text_IO; use Ada.Text_IO;
with Interfaces.Fortran; use Interfaces.Fortran;
with lapack, lapack.driver;
procedure mysolve is
A : lapack.Fortran_Real_Matrix (1 .. 3, 1 .. 3)
begin
lapack.driver.SGESV(...)
....
-----------------------
>gnatmake -I../ada mysolve.adb
-largs
-L/usr/lib/atlas-base/atlas
-L/usr/lib/atlas-base/
-lblas
-llapack
>./mysolve
-1.31250E+00
3.50000E+00
1.12500E+00
>
done!
The only surprise for me, was that I had to WITH the 'driver' which is a
child package of the parent lapack package explicitly to use it from the
client even though I withed the parent package.
I thought, since it is a child package of lapack, then it will be pulled in
automatically by just WITH'ing lapack. But no.
i.e. I thought by inviting the parent in, the children will come along
with the parent and not be left alone outside.
No problem.
I think now the API is much more clean. I rebuild lapack
with this new change and all is well. I think when Lapack binding was made,
child packages did not exist yet in Ada?
I also removed all the pragma linker options that was hard-coded in the
source code. I do not like to see hard-coded values for build in source
code. I think all of this belong to Makefile or gpr and not in source code.
Making more documentations and diagrams and will update all this on
my Ada page soon with a new snapshot tar file in case someone wants to try
it.
--Nasser
^ permalink raw reply [relevance 5%]
* Re: Free AMD Core Math Library (BLAS/LAPACK) + Ada
2012-07-25 8:56 4% ` Ada novice
@ 2012-07-25 9:26 0% ` Georg Bauhaus
0 siblings, 0 replies; 123+ results
From: Georg Bauhaus @ 2012-07-25 9:26 UTC (permalink / raw)
On 25.07.12 10:56, Ada novice wrote:
>
>> How can you say that?
>
> I was thinking that the -gnat2012 switch should do the trick. Or was this new for loop feature added much later?
>
> So to what extent this -gnat2012 in GPL 2011 is effective?
>
>> You can simply for now, change the above LOOP to use standard Ada loop
>> and not the new enhanced LOOP above, and all will be OK. Or use GNAT 2012
>> and leave the source as is.
>
> If I modified the for construct to say:
>
> for x in b'Range loop -- print solution
> real_io.PUT (x'img); new_line;
> end loop;
>
> that doesn't work:
>
> $ gnatmake -gnat2012 -I../ada mysolve2.adb
> gcc -c -gnat2012 -I../ada mysolve2.adb
> mysolve2.adb:40:21: no candidate interpretations match the actuals:
> mysolve2.adb:40:21: missing argument for parameter "Item" in call to "Put" declared at a-tiflio.ads:78, instance at line 11
> mysolve2.adb:40:21: missing argument for parameter "Item" in call to "Put" declared at a-tiflio.ads:60, instance at line 11
> mysolve2.adb:40:28: expected type "Interfaces.Fortran.Real"
> mysolve2.adb:40:28: found type "Standard.String"
> mysolve2.adb:40:28: ==> in call to "Put" at a-tiflio.ads:67, instance at line 11
> gnatmake: "mysolve2.adb" compilation error
>
> So how to properly output the x vector?
real_io is likely an instance for floating point types.
"x in b'range" means x is of the index type of the array.
'img is a non-Ada extension of GNAT for lazy writers,
intended to be used with pragma Debug. It's result is
of a string type, real_io.Put needs a floating point value.
"x of b" in terms of Ada 2012 means x is of the component
type of b, not of the index type of b. It is what real_io.Put
needs.
--
--
Georg Bauhaus
Y A Time Drain http://www.9toX.de
^ permalink raw reply [relevance 0%]
* Re: Free AMD Core Math Library (BLAS/LAPACK) + Ada
@ 2012-07-25 8:56 4% ` Ada novice
2012-07-25 9:26 0% ` Georg Bauhaus
0 siblings, 1 reply; 123+ results
From: Ada novice @ 2012-07-25 8:56 UTC (permalink / raw)
Cc: nma
> How can you say that?
I was thinking that the -gnat2012 switch should do the trick. Or was this new for loop feature added much later?
So to what extent this -gnat2012 in GPL 2011 is effective?
> You can simply for now, change the above LOOP to use standard Ada loop
> and not the new enhanced LOOP above, and all will be OK. Or use GNAT 2012
> and leave the source as is.
If I modified the for construct to say:
for x in b'Range loop -- print solution
real_io.PUT (x'img); new_line;
end loop;
that doesn't work:
$ gnatmake -gnat2012 -I../ada mysolve2.adb
gcc -c -gnat2012 -I../ada mysolve2.adb
mysolve2.adb:40:21: no candidate interpretations match the actuals:
mysolve2.adb:40:21: missing argument for parameter "Item" in call to "Put" declared at a-tiflio.ads:78, instance at line 11
mysolve2.adb:40:21: missing argument for parameter "Item" in call to "Put" declared at a-tiflio.ads:60, instance at line 11
mysolve2.adb:40:28: expected type "Interfaces.Fortran.Real"
mysolve2.adb:40:28: found type "Standard.String"
mysolve2.adb:40:28: ==> in call to "Put" at a-tiflio.ads:67, instance at line 11
gnatmake: "mysolve2.adb" compilation error
So how to properly output the x vector?
Thanks
YC
^ permalink raw reply [relevance 4%]
* Re: Free AMD Core Math Library (BLAS/LAPACK) + Ada
@ 2012-07-25 5:36 4% ` Ada novice
0 siblings, 1 reply; 123+ results
From: Ada novice @ 2012-07-25 5:36 UTC (permalink / raw)
Cc: nma
First, I am using GNAT GPL 2011 and not the 2012 version. But I am adding the -gnat2012 switch as this is required or else I get:
$ gnatmake -I../ada mysolve.adbgcc -c -I../ada mysolve.adb
mysolve.adb:39:16: iterator is an Ada2012 feature
gnatmake: "mysolve.adb" compilation error
Anyway, back to using the -gnat2012 switch:
(my username here)~/work/ada/testlapack/lapada/test $ gnatmake -gnat2012 -I../ada mysolve.adb
gcc -c -gnat2012 -I../ada mysolve.adb
mysolve.adb:39:21: too few subscripts in array reference
gnatmake: "mysolve.adb" compilation error
and
(my username here)~/work/ada/testlapack/lapada/test $ cat mysolve.adb
with Ada.Text_IO; use Ada.Text_IO;
with Interfaces.Fortran; use Interfaces.Fortran;
with labase; -- from LAPACK binding
with ladrv; -- from LAPACK binding
procedure mySolve is
A: labase.Fortran_Real_Matrix ( 1..3, 1..3 );
b: labase.Fortran_Real_Matrix ( 1..3, 1..1 );
package Real_IO is new Ada.Text_IO.Float_IO( Real );
INFO : Fortran_Integer;
IPIV : labase.Fortran_Integer_Vector ( 1..A'Last(2));
Begin -- solve A x=b
A := ((2.0, 3.0, 1.0),
(2.0, 1.0, 1.0),
(4.0, -1.0, 6.0));
b := (( 1=> 9.0 ),
( 1=> 2.0 ),
( 1=>-2.0 )
);
ladrv.SGESV (N => A'Last(2),
NRHS => b'Last(2),
A => A,
LDA => A'Last(1),
IPIV => IPIV,
B => b,
LDB => b'Last(1),
INFO => INFO);
if ( not(INFO = 0) ) then
raise PROGRAM_ERROR;
end if;
for x of b loop -- print solution
real_io.PUT ( x ); new_line;
end loop;
I am not convinced to think that using GNAT GPL 2011 instead of the 2012 version is the culprit here. If however I have to change to the 2012 version, I wonder if I can have both the 2011 and 202 on my machine. On windows it is simple as GNAT is stored in year-wise folders.
I am using the 2011 version since there is no in-built lapack/blas in GNAT 2012 and I want to be sure that I can still run the earlier math extension package from Simon Wright.
On Windows installing separate lapack/blas libraries is a nightmare. But I guess if I am using linux, then I can safely change to GPL 2012 and use the updated math extension package from Simon. Anyway, in this respect what is the way to uninstall GNAT GPL 2011 given that this cannot be done via the synaptic package manager since GNAT GPL 2011 does not come pre-packaged for Debian.
Thanks,
YC
^ permalink raw reply [relevance 4%]
* Re: Free AMD Core Math Library (BLAS/LAPACK) + Ada
@ 2012-07-24 16:41 5% ` Nasser M. Abbasi
0 siblings, 1 reply; 123+ results
From: Nasser M. Abbasi @ 2012-07-24 16:41 UTC (permalink / raw)
On 7/24/2012 10:40 AM, Ada novice wrote:
> In http://12000.org/my_notes/ada/index.htm point 13 where a complete
>example is given to solve the system Ax=b, on running the code I get an error due to a line almost at the bottom of the code:
>
> for x of b loop
>
> The error message is "too few subscripts in array reference".
>
> The b vector is a 3 rows 1 column vector.
>
> YC
>
It works fine here. May be you copied the source from the page wrong.
(I'll make a text file of this later and add it later, for now
you can use the mouse to copy it, it is verbatim text)
--------------------------------
cd lapada/test -- this is where you'll have the test program sit
>gnatmake -gnat2012 -I../ada mysolve.adb
gcc -c -gnat2012 -I../ada mysolve.adb
gnatbind -I../ada -x mysolve.ali
gnatlink mysolve.ali
>ls -lrt
-rwxrwxrwx 1 me me 552678 Jul 24 11:35 mysolve
>./mysolve
-1.31250E+00
3.50000E+00
1.12500E+00
-------------------------
Make sure to copy the source correct. Here it is again
>cat mysolve.adb
-----------------------------------
with Ada.Text_IO; use Ada.Text_IO;
with Interfaces.Fortran; use Interfaces.Fortran;
with labase; -- from LAPACK binding
with ladrv; -- from LAPACK binding
procedure mySolve is
A: labase.Fortran_Real_Matrix ( 1..3, 1..3 );
b: labase.Fortran_Real_Matrix ( 1..3, 1..1 );
package Real_IO is new Ada.Text_IO.Float_IO( Real );
INFO : Fortran_Integer;
IPIV : labase.Fortran_Integer_Vector ( 1..A'Last(2));
Begin -- solve A x=b
A := ((2.0, 3.0, 1.0),
(2.0, 1.0, 1.0),
(4.0, -1.0, 6.0));
b := (( 1=> 9.0 ),
( 1=> 2.0 ),
( 1=>-2.0 )
);
ladrv.SGESV (N => A'Last(2),
NRHS => b'Last(2),
A => A,
LDA => A'Last(1),
IPIV => IPIV,
B => b,
LDB => b'Last(1),
INFO => INFO);
if ( not(INFO = 0) ) then
raise PROGRAM_ERROR;
end if;
for x of b loop -- print solution
real_io.PUT ( x ); new_line;
end loop;
end mySolve;
--------------------------------------
--Nasser
^ permalink raw reply [relevance 5%]
* Re: Lapack Ada binding matrices/vectors issue, how to best to resolve?
2012-07-12 0:38 6% Lapack Ada binding matrices/vectors issue, how to best to resolve? Nasser M. Abbasi
@ 2012-07-12 0:45 0% ` Nasser M. Abbasi
0 siblings, 0 replies; 123+ results
From: Nasser M. Abbasi @ 2012-07-12 0:45 UTC (permalink / raw)
On 7/11/2012 7:38 PM, Nasser M. Abbasi wrote:
>
> ---------------------------
> with Interfaces.Fortran; use Interfaces.Fortran;
> with Ada.Numerics.Real_Arrays; use Ada.Numerics.Real_Arrays;
> with labase; use labase; -- LAPACK binding
>
> procedure foo3 is
>
> A1 : constant Fortran_Real_Matrix(1..2,1..2):=
> 12.0*((12.0, 6.0),(-12.0, 6.0)); -- ERROR
>
> A2 : constant Real_Matrix(1..2,1..2) :=
> 12.0*((12.0, 6.0),(-12.0, 6.0)); -- OK
> begin
> null;
> end foo3;
> --------------------
>
opps that should be foo3.adb in the command below (I copied the file content
to new file and named it foo3, but pasted the older command on the window which
was foo2.adb)
>> gnatmake -gnat2012 -I/lapada/ada foo2.adb -largs -lblas
> gcc -c -gnat2012 -I/lapada/ada foo2.adb
> foo2.adb:24:20: expected type "Fortran_Real_Matrix" defined at labase.ads:94
> foo2.adb:24:20: found type "Interfaces.Fortran.Complex"
> gnatmake: "foo2.adb" compilation error
>>
>
here is the command again:
>gnatmake -gnat2012 -I/lapada/ada foo3.adb -largs -lblas
gcc -c -gnat2012 -I/lapada/ada foo3.adb
foo3.adb:10:13: expected type "Fortran_Real_Matrix" defined at labase.ads:94
foo3.adb:10:13: found type "Complex_Star_16" defined at labase.ads:52
gnatmake: "foo3.adb" compilation error
>
(I just did not want someone to get confused if they saw this).
--Nasser
^ permalink raw reply [relevance 0%]
* Lapack Ada binding matrices/vectors issue, how to best to resolve?
@ 2012-07-12 0:38 6% Nasser M. Abbasi
2012-07-12 0:45 0% ` Nasser M. Abbasi
0 siblings, 1 reply; 123+ results
From: Nasser M. Abbasi @ 2012-07-12 0:38 UTC (permalink / raw)
The Ada lapack binding defines its own Matrix types. However, it
does not define operators (multiply, add, etc.. ) to work on these
types similar to Ada's Real Vectors and Matrices in the
Ada.Numerics.Real_Arrays package
http://www.ada-auth.org/standards/12rm/html/RM-G-3-1.html
What this means, is that one can't even multiply a number by the
matrix if the Matrix is Fortran_Real_Matrix like one can with
Real_Matrix. Here is a simple example
---------------------------
with Interfaces.Fortran; use Interfaces.Fortran;
with Ada.Numerics.Real_Arrays; use Ada.Numerics.Real_Arrays;
with labase; use labase; -- LAPACK binding
procedure foo3 is
A1 : constant Fortran_Real_Matrix(1..2,1..2):=
12.0*((12.0, 6.0),(-12.0, 6.0)); -- ERROR
A2 : constant Real_Matrix(1..2,1..2) :=
12.0*((12.0, 6.0),(-12.0, 6.0)); -- OK
begin
null;
end foo3;
--------------------
>gnatmake -gnat2012 -I/lapada/ada foo2.adb -largs -lblas
gcc -c -gnat2012 -I/lapada/ada foo2.adb
foo2.adb:24:20: expected type "Fortran_Real_Matrix" defined at labase.ads:94
foo2.adb:24:20: found type "Interfaces.Fortran.Complex"
gnatmake: "foo2.adb" compilation error
>
I tried to do conversion of the Fortran_Real_Matrix to
Real_Matrix but the compiler does not like it as it is
aggregate.
So, this means this binding as it stands is too limited to
use as is.
What would be a good way to fix this whole issue? Make a
pacakge similar to Numerics.Generic_Real_Arrays for
the Fortran_Real_Matrix so that all the operators '*','+', etc..
are available now for this Matrix type?
The Ada lapack package with's :
with Ada.Numerics.Generic_Complex_Types;
with Interfaces.Fortran; use Interfaces.Fortran;
Then it defines many types, such as
----------------------
type Fortran_Integer_Matrix is array (Fortran_Integer range <>,
Fortran_Integer range <>)
of Fortran_Integer;
pragma Convention (Fortran, Fortran_Integer_Matrix);
etc..
----------------------
But it does NOT define operators to work on these types like
the Ada package Ada.Numerics.Real_Arrays does:
-------------------------------
function "*" (Left : Real'Base; Right : Real_Matrix)
return Real_Matrix;
---------------------------
I was thinking of just copying all these functions as the above to the
Lapack package and edit things and change all the Real_Matrix to
Fortran_Real_Matrix etc.. but this seems like not the right way
to do this.
The main Lapack package is lapada/ada/labase.ads in
the tar file
ftp://ftp.cs.kuleuven.be/pub/Ada-Belgium/mirrors/gnu-ada/OLD/contrib/lapack-ada/
Any suggestion how to resolve this from experts will be great as I am
a newbie in Ada.
--Nasser
^ permalink raw reply [relevance 6%]
* Re: How to initialize a matrix of one column only?
2012-07-08 0:08 5% How to initialize a matrix of one column only? Nasser M. Abbasi
2012-07-08 0:20 0% ` Nasser M. Abbasi
2012-07-08 1:47 0% ` John B. Matthews
@ 2012-07-08 7:43 0% ` Stephen Leake
2 siblings, 0 replies; 123+ results
From: Stephen Leake @ 2012-07-08 7:43 UTC (permalink / raw)
"Nasser M. Abbasi" <nma@12000.org> writes:
> Here is the code, I write
>
> ----------------------
> with Interfaces.Fortran;
> use Interfaces.Fortran;
> with lbase;
> ....
> N: Fortran_Integer := 3;
> B: labase.Fortran_Real_Matrix ( 1..N, 1..1 );
> BEGIN
> B := ((9.0) , -- here is the problem
> (2.0) ,
> (-2.0));
There is an ambiguity in Ada syntax; a parenthesized expression looks
like a one-element aggregate. To distinguish the two cases, you must use
named association for one-element aggregates:
B := ((1 => 9.0) , -- here is the problem
(1 => 2.0) ,
(1 => -2.0));
--
-- Stephe
^ permalink raw reply [relevance 0%]
* Re: How to initialize a matrix of one column only?
2012-07-08 0:08 5% How to initialize a matrix of one column only? Nasser M. Abbasi
2012-07-08 0:20 0% ` Nasser M. Abbasi
@ 2012-07-08 1:47 0% ` John B. Matthews
2012-07-08 7:43 0% ` Stephen Leake
2 siblings, 0 replies; 123+ results
From: John B. Matthews @ 2012-07-08 1:47 UTC (permalink / raw)
In article <jtaj2c$18k$1@speranza.aioe.org>,
"Nasser M. Abbasi" <nma@12000.org> wrote:
[...]
> Here is the code, I write
>
> ----------------------
> with Interfaces.Fortran;
> use Interfaces.Fortran;
> with lbase;
> ....
> N: Fortran_Integer := 3;
> B: labase.Fortran_Real_Matrix ( 1..N, 1..1 );
> BEGIN
> B := ((9.0) , -- here is the problem
> (2.0) ,
> (-2.0));
> ....
> --------------------------------------------
>
> where the labase package simply introduces a type for
> Fortran_Real_Matrix as follows
>
> ----------------------------
> type Fortran_Real_Matrix is array (Fortran_Integer range <>,
> Fortran_Integer range <>)
> of Real;
> pragma Convention (Fortran, Fortran_Real_Matrix);
> --------------------
>
>
> >gnatmake -I../ada lap42.adb
> gcc -c -I../ada lap42.adb
> lap42.adb:35:16: nested array aggregate expected
> lap42.adb:35:16: if single-component aggregate is intended, write e.g. (1 =>
> ...)
> gnatmake: "lap42.adb" compilation error
> >
>
> I tried B:=(1=>9.0,2=>2.03=>-2.0);
> and B := ((9.0 ,2.0 , 3));
> but non working.
>
> What is the correct syntax to use?
According to 4.3.3 Array Aggregates, you need to use named notation for
a single component, otherwise "a single expression in parentheses is
interpreted as a parenthesized expression."
B := ((1 => 9.0),
(1 => 2.0),
(1 => -2.0));
<http://www.ada-auth.org/standards/12rm/html/RM-4-3-3.html>
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
^ permalink raw reply [relevance 0%]
* Re: my cheat sheet note on installation of the Ada binding to Blas and Lapack
@ 2012-07-08 0:50 5% ` Nasser M. Abbasi
0 siblings, 0 replies; 123+ results
From: Nasser M. Abbasi @ 2012-07-08 0:50 UTC (permalink / raw)
On 7/6/2012 4:26 AM, Nasser M. Abbasi wrote:
> fyi;
>
> I wrote a small note on the installation of the Ada binding
> to Blas and Lapack, in case they might be useful for someone.
>
> Added the note to my Ada web page below
>
> http://12000.org/my_notes/ada/index.htm
>
fyi;
This is my first program using the lapack binding!
I tried to make it as simple as I can. It solves
A x = b. (one can do this also using Ada own solve() function
ofcourse, but with Lapack, one can do much more).
I show the Ada code, and the matlab equivalent to show they
give the same result. I'll update my cheat sheet above with
these examples later on.
----------------------------------
with Ada.Text_IO; use Ada.Text_IO;
with Interfaces.Fortran; use Interfaces.Fortran;
with labase; -- from LAPACK binding
with ladrv; -- from LAPACK binding
procedure mySolve is
A: labase.Fortran_Real_Matrix ( 1..3, 1..3 );
b: labase.Fortran_Real_Matrix ( 1..3, 1..1 );
package Real_IO is new Ada.Text_IO.Float_IO( Real );
INFO : Fortran_Integer;
IPIV : labase.Fortran_Integer_Vector ( 1..A'Last(2));
Begin -- solve A x=b
A := ((2.0, 3.0, 1.0),
(2.0, 1.0, 1.0),
(4.0, -1.0, 6.0));
b := ((9.0,others=>0.0),
(2.0,others=>0.0),
(-2.0,others=>0.0)
);
ladrv.SGESV ( N => A'Last(2),
NRHS => b'Last(2),
A => A,
LDA => A'Last(1),
IPIV => IPIV,
B => b,
LDB => b'Last(1),
INFO => INFO);
if ( not(INFO = 0) ) then
raise PROGRAM_ERROR;
end if;
for x of b loop -- print solution
real_io.PUT ( x ); new_line;
end loop;
end mySolve;
--------------------------
output is
>gnatmake -gnat2012 -I../ada mysolve.adb
gcc -c -gnat2012 -I../ada mysolve.adb
gnatbind -I../ada -x mysolve.ali
gnatlink mysolve.ali
>./mysolve
-1.31250E+00
3.50000E+00
1.12500E+00
>
Matlab
--------
EDU>> A=[2 3 1;2 1 1;4 -1 6];
EDU>> b=[9;2;-2];
EDU>> A\b -- This is Matlab API to SGESV
ans =
-1.312500000000000
3.500000000000000
1.125000000000000
------------
So we see that Matlab is correct, as confirmed by Ada :)
--Nasser
^ permalink raw reply [relevance 5%]
* Re: How to initialize a matrix of one column only?
2012-07-08 0:08 5% How to initialize a matrix of one column only? Nasser M. Abbasi
@ 2012-07-08 0:20 0% ` Nasser M. Abbasi
2012-07-08 1:47 0% ` John B. Matthews
2012-07-08 7:43 0% ` Stephen Leake
2 siblings, 0 replies; 123+ results
From: Nasser M. Abbasi @ 2012-07-08 0:20 UTC (permalink / raw)
On 7/7/2012 7:08 PM, Nasser M. Abbasi wrote:
> Here is the code, I write
>
> ----------------------
> with Interfaces.Fortran;
> use Interfaces.Fortran;
> with lbase;
> ....
> N: Fortran_Integer := 3;
> B: labase.Fortran_Real_Matrix ( 1..N, 1..1 );
> BEGIN
> B := ((9.0) , -- here is the problem
> (2.0) ,
> (-2.0));
> ....
> --------------------------------------------
....
>
> I tried B:=(1=>9.0,2=>2.03=>-2.0);
> and B := ((9.0 ,2.0 , 3));
> but non working.
>
> What is the correct syntax to use?
>
I found it !
But it makes no sense at al to me. Here is the correct syntax
------------------
N: Fortran_Integer := 3;
B: labase.Fortran_Real_Matrix ( 1..N, 1..1 );
BEGIN
B := ((9.0, others=>0.0),
(2.0, others=>0.0),
(-2.0, others=>0.0)
);
----------------------
Why do I have to write others=>0.0 ? What others? there is
only 1 column? What Am I missing here?
--Nasser
^ permalink raw reply [relevance 0%]
* How to initialize a matrix of one column only?
@ 2012-07-08 0:08 5% Nasser M. Abbasi
2012-07-08 0:20 0% ` Nasser M. Abbasi
` (2 more replies)
0 siblings, 3 replies; 123+ results
From: Nasser M. Abbasi @ 2012-07-08 0:08 UTC (permalink / raw)
So trivial, yet Ada is giving me hard time with this
because I am a newbie.
I am trying to call SGESV in Lapack
http://www.netlib.org/lapack/single/sgesv.f
One of the arguments must be a matrix (the 'B' argument there).
I want to pass it a one column matrix. (i.e. I can't use a
Vector, it must be a matrix, since this is what the Ada Lapack
binding requires).
But I can't get the syntax to simply initialize the required
matrix to be a one column matrix. I keep getting the error
nested array aggregate expected
I am sure this is trivial, but after tried all the
combinations I can think of, and googling around, I
give up. It works with the B matrix is (1..N,1..N)
but not when I write it as (1..N,1..1) to make it one
column matrix.
Here is the code, I write
----------------------
with Interfaces.Fortran;
use Interfaces.Fortran;
with lbase;
....
N: Fortran_Integer := 3;
B: labase.Fortran_Real_Matrix ( 1..N, 1..1 );
BEGIN
B := ((9.0) , -- here is the problem
(2.0) ,
(-2.0));
....
--------------------------------------------
where the labase package simply introduces a type for
Fortran_Real_Matrix as follows
----------------------------
type Fortran_Real_Matrix is array (Fortran_Integer range <>,
Fortran_Integer range <>)
of Real;
pragma Convention (Fortran, Fortran_Real_Matrix);
--------------------
>gnatmake -I../ada lap42.adb
gcc -c -I../ada lap42.adb
lap42.adb:35:16: nested array aggregate expected
lap42.adb:35:16: if single-component aggregate is intended, write e.g. (1 => ...)
gnatmake: "lap42.adb" compilation error
>
I tried B:=(1=>9.0,2=>2.03=>-2.0);
and B := ((9.0 ,2.0 , 3));
but non working.
What is the correct syntax to use?
thanks,
--Nasser
^ permalink raw reply [relevance 5%]
* Re: What would you like in Ada202X?
2012-07-05 15:55 5% ` johnscpg
@ 2012-07-05 16:57 0% ` Simon Wright
0 siblings, 0 replies; 123+ results
From: Simon Wright @ 2012-07-05 16:57 UTC (permalink / raw)
johnscpg@googlemail.com writes:
> Package interfaces.fortran.blas was in the files i-forbla.ads and
> i-forbla.adb, and lapack interfaces in i-forlap.ads.
>
> In the GNAT GPL 2012 distribution I can't find any of these things. I
> was able to get your Ada_Numerics.Generic_Arrays package working OK on
> GPL 2012, but I had to copy i-forbla.ads and i-forbla.adb from the old
> GPL 2011 src, and I had to link to my own lapack and blas
> libraries. At least System.Generic_Array_Operations is still in 2012,
> so Ada_Numerics.Generic_Arrays worked well.
Same problem with GCC 4.7.
AdaCore have stopped using BLAS and LAPACK; for symmetric real matrices
they use an internal implementation of Jacobi, and for hermitian complex
matrices they say
-- For a Hermitian matrix C, we convert the eigenvalue problem to a
-- real symmetric one: if C = A + i * B, then the (N, N) complex
-- eigenvalue problem:
-- (A + i * B) * (u + i * v) = Lambda * (u + i * v)
--
-- is equivalent to the (2 * N, 2 * N) real eigenvalue problem:
-- [ A, B ] [ u ] = Lambda * [ u ]
-- [ -B, A ] [ v ] [ v ]
--
-- Note that the (2 * N, 2 * N) matrix above is symmetric, as
-- Transpose (A) = A and Transpose (B) = -B if C is Hermitian.
-- We solve this eigensystem using the real-valued algorithms. The final
-- result will have every eigenvalue twice, so in the sorted output we
-- just pick every second value, with associated eigenvector u + i * v.
So, I've got some work ahead of me; and, regrettably, users of my Ada
2005 Math Extensions[1] are probably going to need to install their own
BLAS/LAPACK libraries (not on Mac OS X, I think). Grr. Bug raised[2].
One thing I _don't_ see in the SVN history is any indication of _why_
this change was made.
[1] https://sourceforge.net/projects/gnat-math-extn/
[2] https://sourceforge.net/tracker/?func=detail&aid=3540499&group_id=338296&atid=1416932
^ permalink raw reply [relevance 0%]
* Re: What would you like in Ada202X?
@ 2012-07-05 15:55 5% ` johnscpg
2012-07-05 16:57 0% ` Simon Wright
0 siblings, 1 reply; 123+ results
From: johnscpg @ 2012-07-05 15:55 UTC (permalink / raw)
On Wednesday, July 4, 2012 11:26:53 PM UTC+1, Simon Wright wrote:
> shai.lesh writes:
>
> > On Wednesday, July 4, 2012 8:22:46 PM UTC+1, Dennis Lee Bieber wrote:
> >
> >> A search of my machine (WinXP, ancient) with the 2011 build from
> >> AdaCore/libre, seeking *blas*.*
> >>
> >>
> >> Nothing in E:\GNAT\... and only an old malware checker from M$ in
> >> system directories.
> >> --
> >
> > Nothing in mine too. I have both GNAT GPL 2011 and 2012 on
> > Windows. Hope that next Ada versions will make the library more
> > "accessible" and easier to use.
>
> Looks as though for GNAT GPL 2011 on Windows, BLAS and LAPACK are in
> C:\GNAT\2011\lib\gcc\i686-pc-mingw32\4.5.3\libgnalasup.a.
>
> Not as obvious as one might have expected.
On linux, the GNAT GPL 2011 lapack stuff seems to be in
.../lib/gcc/x86_64-pc-linux-gnu/4.5.3/adalib/libgnala.a
Package interfaces.fortran.blas was in the files i-forbla.ads and
i-forbla.adb, and lapack interfaces in i-forlap.ads.
In the GNAT GPL 2012 distribution I can't find any of these things. I
was able to get your Ada_Numerics.Generic_Arrays package working OK on
GPL 2012, but I had to copy i-forbla.ads and i-forbla.adb from the old
GPL 2011 src, and I had to link to my own lapack and blas libraries. At least
System.Generic_Array_Operations is still in 2012, so Ada_Numerics.Generic_Arrays worked well.
J.
^ permalink raw reply [relevance 5%]
* Re: Interfacing Ada multidimensional arrays with Fortran.
@ 2011-06-09 7:55 7% ` David Sauvage
0 siblings, 0 replies; 123+ results
From: David Sauvage @ 2011-06-09 7:55 UTC (permalink / raw)
On May 28, 8:45 pm, Simon Wright <si...@pushface.org> wrote:
...
> -O1:
> Transposition: 1200 us
> Assignment: 300 us
>
> -O2:
> Transposition: 500 us
> Assignment: 300 us
Using this testcase [1], here are my results using Intel Atom CPU N270
@ 1.60GHz / Linux (launched with root privilege) :
-O1:
Transposition: 2202 us
Assignment: 1014 us
-O2:
Transposition: 2556 us
Assignment: 885 us
Transposition (using assignment via pragma Convention) seems to be
quicker than Transposition (without pragma Convention).
The reason why pragma Convention (Fortran, Type) is not used in
Interfaces.Fortran... is unknown and seems to give slower compute
time.
[1]
-- gnatmake -f compare.adb -cargs -gnat05 -O2
-- gnatmake -f compare.adb -cargs -gnat05 -O1
with Interfaces.Fortran.BLAS;
with Ada.Text_IO,
Ada.Calendar,
Ada.Numerics.Generic_Real_Arrays;
procedure Compare is
Start, Stop : Ada.Calendar.Time;
use type Ada.Calendar.Time;
type Real_Matrix is
array (Integer range <>, Integer range <>) of
Interfaces.Fortran.Real;
pragma Convention (Fortran, Real_Matrix);
package GRA is new Ada.Numerics.Generic_Real_Arrays (
Interfaces.Fortran.Real);
Row, Column : constant Positive := 100;
Iteration : constant Positive := 10;
M : Real_Matrix (1 .. Row, 1 .. Column) := (others => (others
=> 2.0));
pragma Volatile (M);
MFA, MFB : GRA.Real_Matrix (1 .. Row, 1 .. Column) := (others =>
(others => 2.0));
pragma Volatile (MFA);
pragma Volatile (MFB);
use type Interfaces.Fortran.Real;
begin
Start := Ada.Calendar.Clock;
for I in 1 .. Iteration loop
M := Real_Matrix (MFB);
end loop;
Stop := Ada.Calendar.Clock;
Ada.Text_IO.Put_Line
("Assignation (Transposition via pragma Convention)" &
Duration'Image (Stop - Start));
Start := Ada.Calendar.Clock;
for I in 1 .. Iteration loop
MFA := GRA.Transpose (MFB);
end loop;
Stop := Ada.Calendar.Clock;
Ada.Text_IO.Put_Line
("Transposition" & Duration'Image (Stop - Start));
end Compare;
^ permalink raw reply [relevance 7%]
* Re: Interfacing Ada multidimensional arrays with Fortran.
2011-05-27 20:50 6% Interfacing Ada multidimensional arrays with Fortran David Sauvage
@ 2011-05-28 9:41 7% ` Simon Wright
0 siblings, 1 reply; 123+ results
From: Simon Wright @ 2011-05-28 9:41 UTC (permalink / raw)
David Sauvage <sauvage.david@gmail.com> writes:
> Concerning multidimensional arrays, Ada use row-major order [0] while
> Fortran use column-major order [1].
> 3 - Concerning BLAS & LAPACK routines, there are parameters to
> indicates the form of the array (transposed or not) to the Fortran
> code, so that the Fortran code load the array properly.
This is true of BLAS, but I don't believe it's true of LAPACK.
> In Interfaces.Fortran.BLAS, there are Multidimensional arrays types
> that are already defined ;
> (Real_Matrix, Double_Precision_Matrix, Complex_Matrix,
> Double_Complex_Matrix)
> But the corresponding pragma Convention (Fortran, type) are not
> defined for them. So any user that would re-use those types can not
> use pragma Convention, and use possibility 2 or 3 above,
Interfaces.Fortran.BLAS is an internal GNAT unit, ie part of GNAT's
implementation of the standard Ada.Numerics.Generic_*_Arrays, not part
of the standard itself.
> It would be interesting to know the story behind the scene of why
> array types declared in Interfaces.Fortran.BLAS do not use pragma
> Convention (Fortran, *) ?
There I can't help you.
The implementor of Ada.Numerics.Generic_Real_Arrays has decided to
declare Interfaces.Fortran.BLAS using Ada order, so that to convert from
the Ada order required in the standard for these units he uses the
Transpose operation (note, a copy is required anyway because LAPACK
doesn't preserve the input matrix).
Functionally, he could equally well have declared in Fortran order, as
you suggest:
with Ada.Text_IO; use Ada.Text_IO;
with Interfaces.Fortran.BLAS;
procedure Sauvage is
type Real_Matrix is array (Integer range <>, Integer range <>)
of Interfaces.Fortran.Real;
pragma Convention (Fortran, Real_Matrix);
Theirs : constant Interfaces.Fortran.BLAS.Real_Matrix :=
(1 => (1 => 1.0, 2 => 2.0),
2 => (1 => 3.0, 2 => 4.0));
Mine : Real_Matrix (1 .. 2, 1 .. 2);
begin
Mine := Real_Matrix (Theirs); -- transposition occurs here
for J in Mine'Range (1) loop
for K in Mine'Range (2) loop
Put_Line (Mine (J, K)'Img);
end loop;
end loop;
end Sauvage;
and it might have been quicker.
Quite how the implementor of Ada.Numerics.Generic_Complex_Arrays managed
the transposition is less than clear to me!
> What are the performance issues by using the three possibilities
> above ? (may be the community already had some interesting information
> about this)
I haven't measured this. Anyone else?
> Some would think the pragma Convention (Fortran, type) should be more
> efficient, but may be it is not that simple, as apparently the choice
> has been made to avoid [4] pragma Convention (Fortran, type).
^ permalink raw reply [relevance 7%]
* Interfacing Ada multidimensional arrays with Fortran.
@ 2011-05-27 20:50 6% David Sauvage
2011-05-28 9:41 7% ` Simon Wright
0 siblings, 1 reply; 123+ results
From: David Sauvage @ 2011-05-27 20:50 UTC (permalink / raw)
Hi,
Concerning multidimensional arrays, Ada use row-major order [0] while
Fortran use column-major order [1].
It seems to exist two possibilities to handle this issue when calling
Fortran procedures from Ada, and three possibilities when calling BLAS
[2] or LAPACK [3] Fortran specific routines.
1 - Use the pragma Convention (Fortran, T_Real_Matrix)
on the array type, so that the array will be stored in column-major
order, as needed by Fortran.
Any feedbacks concerning the successful use of this pragma Convention
(Fortran, type) & GNATGPL 2010 or FSF GCC would be appreciate.
2 - Transpose the array in the Ada side when calling the Fortran code,
so that the Fortran code will load the array properly.
3 - Concerning BLAS & LAPACK routines, there are parameters to
indicates the form of the array (transposed or not) to the Fortran
code, so that the Fortran code load the array properly.
In Interfaces.Fortran.BLAS, there are Multidimensional arrays types
that are already defined ;
(Real_Matrix, Double_Precision_Matrix, Complex_Matrix,
Double_Complex_Matrix)
But the corresponding pragma Convention (Fortran, type) are not
defined for them. So any user that would re-use those types can not
use pragma Convention, and use possibility 2 or 3 above,
It would be interesting to know the story behind the scene of why
array types declared in Interfaces.Fortran.BLAS do not use pragma
Convention (Fortran, *) ?
What are the performance issues by using the three possibilities
above ? (may be the community already had some interesting information
about this)
Some would think the pragma Convention (Fortran, type) should be more
efficient, but may be it is not that simple, as apparently the choice
has been made to avoid [4] pragma Convention (Fortran, type).
Cheers
[0] http://en.wikipedia.org/wiki/Row-major_order
[1] http://www.adaic.org/resources/add_content/standards/05rm/html/RM-B-5.html
[2] http://www.netlib.org/blas/
[3] http://www.netlib.org/lapack/
[4] i-forbla.ads
^ permalink raw reply [relevance 6%]
* Re: simple question on long_float/short_float
2010-10-02 9:11 6% ` Nasser M. Abbasi
2010-10-02 9:48 4% ` Dmitry A. Kazakov
2010-10-02 10:45 0% ` cjpsimon
@ 2010-10-02 16:52 4% ` Jeffrey Carter
2 siblings, 0 replies; 123+ results
From: Jeffrey Carter @ 2010-10-02 16:52 UTC (permalink / raw)
On 10/02/2010 02:11 AM, Nasser M. Abbasi wrote:
>
> 1) So, it seems to me that Ada did use Fortran double in v1. since
> output is different than in v2. Unless I made a mistake in v2. Hence, I
> do not understand why the webpage above said that Gnat would use the
> same types. Can I change v2 to make it output the same as Fortran? I
> assume not, since it is not double to start with.
Sure. Try
type My_Float is digits Interfaces.Fortran.Double_Precision'digits;
or
type My_Float is digits Long_Float'digits;
or even
type My_Float is digits 15;
all of which give My_Float the same "digits 15" declaration as Double_Precision
and Long_Float.
> I also need to study more about Ada floats and how they work. What I do
> not understand yet, does Ada does use IEEE754 for its floats? Assuming
> it does, then it must do something additional at run-time to obtain the
> result it needs when one uses DIGITS nnn in the type definition for Ada
> float.
Ada compilers typically use an underlying hardware floating-point type to
implement floating-point type declarations. That is IEEE-754 on many platforms,
but not all.
--
Jeff Carter
"So if I understand 'The Matrix Reloaded' correctly, the Matrix is
basically a Microsoft operating system--it runs for a while and
then crashes and reboots. By design, no less. Neo is just a
memory leak that's too hard to fix, so they left him in ... The
users don't complain because they're packed in slush and kept
sedated."
Marin D. Condic
65
^ permalink raw reply [relevance 4%]
* Re: simple question on long_float/short_float
2010-10-02 9:11 6% ` Nasser M. Abbasi
2010-10-02 9:48 4% ` Dmitry A. Kazakov
@ 2010-10-02 10:45 0% ` cjpsimon
2010-10-02 16:52 4% ` Jeffrey Carter
2 siblings, 0 replies; 123+ results
From: cjpsimon @ 2010-10-02 10:45 UTC (permalink / raw)
On 2 oct, 11:11, "Nasser M. Abbasi" <n...@12000.org> wrote:
> Ada experts;
>
> I have a follow up.
>
> It says herehttp://www.pegasoft.ca/resources/boblap/17.html
>
> "Gnat provides interfacing packages for languages besides C.
> Interfaces.Fortran contains types and subprograms to link Fortran
> language programs to your Ada programs. The GCC Fortran 77 compiler is g77.
>
> As with gcc, most of the Fortran data types correspond identically with
> an Ada type. A Fortran real variable, for example, is the same as an Ada
> float, and a double precision variable is an Ada long_float. Other Ada
> compilers may not do this: if portability is an issue, always use the
> types of Interfaces.Fortran."
>
> I wrote a small Ada program to print a value of a floating number which
> has the type Double_Precision, and printed the value to the screen.
>
> I did the same in Fortran, same number, and printed the value to screen.
> In Fortran, the value printed is that of IEEE754, and in Ada it also
> printed the same as Fortran. So I am happy to see that. Here is the code
> and the output:
>
> ---- Ada v1 ----
> with ada.text_io;
> with Interfaces.Fortran; use Interfaces.Fortran;
>
> procedure test is
> package my_float_IO is new Ada.Text_IO.float_IO(Double_Precision);
> use my_float_IO;
> a : Double_Precision := 2.3;
> begin
> Put( item=>a,Fore=>25,Aft=>16) ;
> end test;
>
> ---- fortran ----
> program main
> implicit none
> double precision :: c=2.3D0
>
> write (*,'(F25.16)') c
> end program main
>
> ---- output of the above in same order ----
> 2.2999999999999998E+00 ---- Ada
> 2.2999999999999998 ---- Fortran
>
> Then I changed the Ada code to the following:
>
> ---- Ada v2 -----
> with ada.text_io;
> procedure test is
> type my_float_type is digits 16;
> package my_float_IO is new Ada.Text_IO.float_IO(my_float_type);
> use my_float_IO;
> a : my_float_type := 2.3;
> begin
> Put( item=>a,Fore=>25,Aft=>16) ;
> end test;
>
> and now the output is
>
> 2.3000000000000000E+00
>
> ------------------------------
>
> 1) So, it seems to me that Ada did use Fortran double in v1. since
> output is different than in v2. Unless I made a mistake in v2. Hence, I
> do not understand why the webpage above said that Gnat would use the
> same types. Can I change v2 to make it output the same as Fortran? I
> assume not, since it is not double to start with.
>
> 2) The reason I wanted to use Fortran double type, so I can compare the
> output of my Ada program to that of Fortran and some output in the textbook.
>
> 3) I need to read more about Ada Float type. Standard is IEEE754, so if
> Ada float does not use this, would this not make the analysis of
> floating point computation in Ada harder? Most textbooks and numerical
> stuff, assume IEEE754 computation done on floating points.
>
> I also need to study more about Ada floats and how they work. What I do
> not understand yet, does Ada does use IEEE754 for its floats? Assuming
> it does, then it must do something additional at run-time to obtain the
> result it needs when one uses DIGITS nnn in the type definition for Ada
> float.
>
> --Nasser
I think Long_Float representation is limited to digits 15. As you want
to
have digits 16 the compiler have to choose Long_Long_Float
representation
or to reject your code depending of the hardware.
Claude
^ permalink raw reply [relevance 0%]
* Re: simple question on long_float/short_float
2010-10-02 9:11 6% ` Nasser M. Abbasi
@ 2010-10-02 9:48 4% ` Dmitry A. Kazakov
2010-10-02 10:45 0% ` cjpsimon
2010-10-02 16:52 4% ` Jeffrey Carter
2 siblings, 0 replies; 123+ results
From: Dmitry A. Kazakov @ 2010-10-02 9:48 UTC (permalink / raw)
On Sat, 02 Oct 2010 02:11:10 -0700, Nasser M. Abbasi wrote:
> I wrote a small Ada program to print a value of a floating number which
> has the type Double_Precision, and printed the value to the screen.
>
> I did the same in Fortran, same number, and printed the value to screen.
> In Fortran, the value printed is that of IEEE754, and in Ada it also
> printed the same as Fortran. So I am happy to see that. Here is the code
> and the output:
>
> ---- Ada v1 ----
> with ada.text_io;
> with Interfaces.Fortran; use Interfaces.Fortran;
>
> procedure test is
> package my_float_IO is new Ada.Text_IO.float_IO(Double_Precision);
> use my_float_IO;
> a : Double_Precision := 2.3;
> begin
> Put( item=>a,Fore=>25,Aft=>16) ;
> end test;
>
> ---- fortran ----
> program main
> implicit none
> double precision :: c=2.3D0
>
> write (*,'(F25.16)') c
> end program main
>
> ---- output of the above in same order ----
> 2.2999999999999998E+00 ---- Ada
> 2.2999999999999998 ---- Fortran
>
> Then I changed the Ada code to the following:
>
> ---- Ada v2 -----
> with ada.text_io;
> procedure test is
> type my_float_type is digits 16;
> package my_float_IO is new Ada.Text_IO.float_IO(my_float_type);
> use my_float_IO;
> a : my_float_type := 2.3;
> begin
> Put( item=>a,Fore=>25,Aft=>16) ;
> end test;
>
> and now the output is
>
> 2.3000000000000000E+00
>
> ------------------------------
>
> 1) So, it seems to me that Ada did use Fortran double in v1. since
> output is different than in v2. Unless I made a mistake in v2. Hence, I
> do not understand why the webpage above said that Gnat would use the
> same types. Can I change v2 to make it output the same as Fortran? I
> assume not, since it is not double to start with.
Hmm, try this:
with Ada.Text_IO; use Ada.Text_IO;
with Interfaces.Fortran; use Interfaces.Fortran;
procedure Test is
type My_Float_Type is digits 16;
type Long_Float_Type is digits 18;
A : My_Float_Type := 2.3;
B : Double_Precision := 2.3;
C : Long_Float_Type := 2.3;
begin
Put_Line ("A'Size=" & Integer'Image (A'Size) & " A=" &
My_Float_Type'Image (A));
Put_Line ("B'Size=" & Integer'Image (B'Size) & " B=" &
Double_Precision'Image (B));
Put_Line ("C'Size=" & Integer'Image (C'Size) & " C=" &
Long_Float_Type'Image (C));
end Test;
On my Intel machine Double_Precision is 96 bits.
Then note that the output may differ not because the Ada type uses another
machine type. Even if they are same, since you have specified 16 *decimal*
digits, the output rounds the underlying binary representation to 16
decimal digits.
> 3) I need to read more about Ada Float type. Standard is IEEE754, so if
> Ada float does not use this,
That depends on the machine. Float and Long_Float standard types are most
likely IEEE 754.
> would this not make the analysis of
> floating point computation in Ada harder?
No, it makes it easier. It is advisable not to use IEEE 754 semantics, even
if the machine is IEEE 754. E.g. if you declare your type as
type My_Float is new Float; -- Chances are high to get IEEE 754 here
To kill IEEE 754 semantics do it this way:
type My_Float is new Float range Float'Range; -- Only numbers!
> Most textbooks and numerical
> stuff, assume IEEE754 computation done on floating points.
I doubt it much. IEEE 754 is a normal floating-point + some non-numbers
like NaN. As the name suggests, numeric computations are performed on
*numbers*. IEEE 754 non-numbers might be useful for the languages with no
means to deal with numeric errors. But in Ada you don't need that because
Ada has numeric exceptions.
From the software design point of view, it is a very bad idea of IEEE 754
to postpone error handling till the end of computations or even forever.
You might compute something awfully long and complex just to get NaN in the
end, not knowing what (and where) was wrong. In a closed loop system you
might deliver NaN on actuators, what would they do?
Ada's numeric model follows the fundamental software design principle: you
shall detect errors *early*.
> I also need to study more about Ada floats and how they work. What I do
> not understand yet, does Ada does use IEEE754 for its floats?
It likely uses IEEE 754 if the machine is IEEE 754, which is almost always.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [relevance 4%]
* Re: simple question on long_float/short_float
2010-09-30 6:58 5% ` J-P. Rosen
@ 2010-10-02 9:11 6% ` Nasser M. Abbasi
2010-10-02 9:48 4% ` Dmitry A. Kazakov
` (2 more replies)
1 sibling, 3 replies; 123+ results
From: Nasser M. Abbasi @ 2010-10-02 9:11 UTC (permalink / raw)
Ada experts;
I have a follow up.
It says here
http://www.pegasoft.ca/resources/boblap/17.html
"Gnat provides interfacing packages for languages besides C.
Interfaces.Fortran contains types and subprograms to link Fortran
language programs to your Ada programs. The GCC Fortran 77 compiler is g77.
As with gcc, most of the Fortran data types correspond identically with
an Ada type. A Fortran real variable, for example, is the same as an Ada
float, and a double precision variable is an Ada long_float. Other Ada
compilers may not do this: if portability is an issue, always use the
types of Interfaces.Fortran."
I wrote a small Ada program to print a value of a floating number which
has the type Double_Precision, and printed the value to the screen.
I did the same in Fortran, same number, and printed the value to screen.
In Fortran, the value printed is that of IEEE754, and in Ada it also
printed the same as Fortran. So I am happy to see that. Here is the code
and the output:
---- Ada v1 ----
with ada.text_io;
with Interfaces.Fortran; use Interfaces.Fortran;
procedure test is
package my_float_IO is new Ada.Text_IO.float_IO(Double_Precision);
use my_float_IO;
a : Double_Precision := 2.3;
begin
Put( item=>a,Fore=>25,Aft=>16) ;
end test;
---- fortran ----
program main
implicit none
double precision :: c=2.3D0
write (*,'(F25.16)') c
end program main
---- output of the above in same order ----
2.2999999999999998E+00 ---- Ada
2.2999999999999998 ---- Fortran
Then I changed the Ada code to the following:
---- Ada v2 -----
with ada.text_io;
procedure test is
type my_float_type is digits 16;
package my_float_IO is new Ada.Text_IO.float_IO(my_float_type);
use my_float_IO;
a : my_float_type := 2.3;
begin
Put( item=>a,Fore=>25,Aft=>16) ;
end test;
and now the output is
2.3000000000000000E+00
------------------------------
1) So, it seems to me that Ada did use Fortran double in v1. since
output is different than in v2. Unless I made a mistake in v2. Hence, I
do not understand why the webpage above said that Gnat would use the
same types. Can I change v2 to make it output the same as Fortran? I
assume not, since it is not double to start with.
2) The reason I wanted to use Fortran double type, so I can compare the
output of my Ada program to that of Fortran and some output in the textbook.
3) I need to read more about Ada Float type. Standard is IEEE754, so if
Ada float does not use this, would this not make the analysis of
floating point computation in Ada harder? Most textbooks and numerical
stuff, assume IEEE754 computation done on floating points.
I also need to study more about Ada floats and how they work. What I do
not understand yet, does Ada does use IEEE754 for its floats? Assuming
it does, then it must do something additional at run-time to obtain the
result it needs when one uses DIGITS nnn in the type definition for Ada
float.
--Nasser
^ permalink raw reply [relevance 6%]
* Re: simple question on long_float/short_float
2010-09-30 8:31 0% ` Nasser M. Abbasi
2010-09-30 8:45 7% ` Nasser M. Abbasi
@ 2010-09-30 15:56 4% ` Adam Beneschan
1 sibling, 0 replies; 123+ results
From: Adam Beneschan @ 2010-09-30 15:56 UTC (permalink / raw)
On Sep 30, 1:31 am, "Nasser M. Abbasi" <n...@12000.org> wrote:
> Is this for real? :)
No, it's for float. Ada doesn't use the REAL keyword.
> So, what is Ada's Float? 32 bit or 64 bits?
The language does not define this. The language is designed to be
implemented on many processors, some of which have floats that are
neither 32 nor 64 bits. Others have mentioned 80-bit floats. ADI
SHARC has 40-bit floats. Some older systems (Honeywell 600 series
e.g.) were based on 36-bit words and their floats were 36 bits. No
idea what Crays define, but it wouldn't surprise me if there are
processors designed for heavy scientific computation that would
require floats of even greater precision than these.
Anyway, it was deliberate that the language did not define exactly
what "Float", "Long_Float", and "Short_Float" are supposed to look
like, so you shouldn't use those types if you care what kind of float
you're getting. If you need the type to match a type in some other
language implemented on that same processor, then use one of the types
in Interfaces.Fortran or Interfaces.C or whatever. If you need your
floating-point type to be specifically 32 or 64 or 57 bits for some
other reason, then either define your own, or (if you don't care about
portability) check to see what your particular compiler's definitions
for that particular processor are. (Even on the same processor, the
definition of "Float" may be different between different vendors'
compilers, because the language doesn't define this.) You can use
Float or Long_Float if you just want any floating-point type that
meets or exceeds the minimum standard in 3.5.7(14-15) and don't really
care how it's implemented. But only then.
-- Adam
^ permalink raw reply [relevance 4%]
* Re: simple question on long_float/short_float
2010-09-30 8:45 7% ` Nasser M. Abbasi
2010-09-30 9:59 0% ` Mark Lorenzen
@ 2010-09-30 13:30 5% ` Peter C. Chapin
1 sibling, 0 replies; 123+ results
From: Peter C. Chapin @ 2010-09-30 13:30 UTC (permalink / raw)
On 2010-09-30 04:45, Nasser M. Abbasi wrote:
> So Ada has
>
> Float,
> long_float,
> short_float,
> Interfaces.Fortran.Reals
> Interfaces.Fortran.Double_Precision
A common recommendation is to avoid using the built-in types directly.
Instead define your own:
type My_Floating_Type is digits 12;
If the implementation has a floating point type with at least 12 decimal
digits of precision it will use it as the base type for My_Floating_Type
and all will be well. If the implementation can't handle that much
precision in any of its built-in types you will get a compile time
error. For example you could try
type My_Floating_Type is digits 350;
But I doubt if there is any implementation that will honor that.
The types in Interfaces.Fortran are intended for the case where you are
exchanging data with a corresponding Fortran compiler. It sounds like
you might, in fact, be doing that.
Peter
^ permalink raw reply [relevance 5%]
* Re: simple question on long_float/short_float
2010-09-30 8:45 7% ` Nasser M. Abbasi
@ 2010-09-30 9:59 0% ` Mark Lorenzen
2010-09-30 13:30 5% ` Peter C. Chapin
1 sibling, 0 replies; 123+ results
From: Mark Lorenzen @ 2010-09-30 9:59 UTC (permalink / raw)
On 30 Sep., 10:45, "Nasser M. Abbasi" <n...@12000.org> wrote:
>
> I just looked it up. So, if I use Interfaces.Fortran Reals and
> Double_Precision I think that would be just fine.
>
> I have always thought that long_float and short_float where the same as
> Fortran's double and single precision. This is confusing.
>
> So Ada has
>
> Float,
> long_float,
> short_float,
> Interfaces.Fortran.Reals
> Interfaces.Fortran.Double_Precision
>
> --Nasser
You should generally not use the predefined types for anything other
than interfacing with other languages e.g. C or Fortran. Don't think
in terms of "Ada has these types..." but define the types you need.
Ada is not Fortran, so don't code Fortran in Ada.
- Mark L
^ permalink raw reply [relevance 0%]
* Re: simple question on long_float/short_float
2010-09-30 8:31 0% ` Nasser M. Abbasi
@ 2010-09-30 8:45 7% ` Nasser M. Abbasi
2010-09-30 9:59 0% ` Mark Lorenzen
2010-09-30 13:30 5% ` Peter C. Chapin
2010-09-30 15:56 4% ` Adam Beneschan
1 sibling, 2 replies; 123+ results
From: Nasser M. Abbasi @ 2010-09-30 8:45 UTC (permalink / raw)
On 9/30/2010 1:31 AM, Nasser M. Abbasi wrote:
> On 9/29/2010 11:58 PM, J-P. Rosen wrote:
>> Le 30/09/2010 08:17, Nasser M. Abbasi a �crit :
>>> Ada experts:
>>>
>>> Is Ada's long_float like Fortran double precision? and short_float is
>>> like Fortran single precision (just called real in Fortran)?
>
>
>> There is nothing in the standard that guarantees this. Float and
>> Long_Float are just floating point types, with greater accuracy for
>> Long_Float.
>>
>> On the other hand, package Interfaces.Fortran provides types Real and
>> Double_Precision, which are required to match the corresponding Fortran
>> types.
>>
I just looked it up. So, if I use Interfaces.Fortran Reals and
Double_Precision I think that would be just fine.
I have always thought that long_float and short_float where the same as
Fortran's double and single precision. This is confusing.
So Ada has
Float,
long_float,
short_float,
Interfaces.Fortran.Reals
Interfaces.Fortran.Double_Precision
--Nasser
^ permalink raw reply [relevance 7%]
* Re: simple question on long_float/short_float
2010-09-30 6:58 5% ` J-P. Rosen
@ 2010-09-30 8:31 0% ` Nasser M. Abbasi
2010-09-30 8:45 7% ` Nasser M. Abbasi
2010-09-30 15:56 4% ` Adam Beneschan
0 siblings, 2 replies; 123+ results
From: Nasser M. Abbasi @ 2010-09-30 8:31 UTC (permalink / raw)
On 9/29/2010 11:58 PM, J-P. Rosen wrote:
> Le 30/09/2010 08:17, Nasser M. Abbasi a �crit :
>> Ada experts:
>>
>> Is Ada's long_float like Fortran double precision? and short_float is
>> like Fortran single precision (just called real in Fortran)?
> There is nothing in the standard that guarantees this. Float and
> Long_Float are just floating point types, with greater accuracy for
> Long_Float.
>
> On the other hand, package Interfaces.Fortran provides types Real and
> Double_Precision, which are required to match the corresponding Fortran
> types.
>
>
Thanks. Are you saying that in Ada I can't make double precision
variables and single precision variables? (as in Fortran?)
Is this for real? :)
So, what is Ada's Float? 32 bit or 64 bits?
--Nasser
^ permalink raw reply [relevance 0%]
* Re: simple question on long_float/short_float
@ 2010-09-30 6:58 5% ` J-P. Rosen
2010-09-30 8:31 0% ` Nasser M. Abbasi
2010-10-02 9:11 6% ` Nasser M. Abbasi
1 sibling, 1 reply; 123+ results
From: J-P. Rosen @ 2010-09-30 6:58 UTC (permalink / raw)
Le 30/09/2010 08:17, Nasser M. Abbasi a �crit :
> Ada experts:
>
> Is Ada's long_float like Fortran double precision? and short_float is
> like Fortran single precision (just called real in Fortran)?
There is nothing in the standard that guarantees this. Float and
Long_Float are just floating point types, with greater accuracy for
Long_Float.
On the other hand, package Interfaces.Fortran provides types Real and
Double_Precision, which are required to match the corresponding Fortran
types.
--
---------------------------------------------------------
J-P. Rosen (rosen@adalog.fr)
Adalog a d�m�nag� / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
^ permalink raw reply [relevance 5%]
* Re: ANN: Ada 2005 Math Extensions, 20100901 release
2010-09-03 5:58 6% ` Simon Wright
@ 2010-09-03 13:48 0% ` John B. Matthews
0 siblings, 0 replies; 123+ results
From: John B. Matthews @ 2010-09-03 13:48 UTC (permalink / raw)
In article <m2y6bjmkr4.fsf@pushface.org>,
Simon Wright <simon@pushface.org> wrote:
> "John B. Matthews" <nospam@nospam.invalid> writes:
>
> > For future reference, here is the patch:
> >
> > <http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01623.html>
>
> Interesting. On Mac OS X, GNAT GPL 2010 i-forbla.adb contains
>
> package body Interfaces.Fortran.BLAS is
> pragma Linker_Options ("-lgnala");
> pragma Linker_Options ("-lm");
> pragma Linker_Options ("-Wl,-framework,vecLib");
> end Interfaces.Fortran.BLAS;
>
> > The compiler options from ada_math_build.gpr should work, e.g.
> > gnatmake -a or gcc -c -gnatpg. Finally, copy the .ali and .o to
> > your Ada library path, `gnatls -v`.
>
> I don't see why you'd do this 'by hand' rather than letting
> ada_math_build.gpr do the heavy lifting?
Good point. I got used to doing it manually while nursing GNAT 4.3.4.
I'm slowly coming to terms with GPS, but it won't stay off my lawn. :-)
> If you do do this, (a) make sure the .ali is read-only, (b) copy
> ada-numerics-generic_arrays.ad[bs] too (to the source search path, of
> course).
>
> I'm having 4th or 5th thoughts about package naming. Perhaps I should
> make it Ada_Numerics.Generic_Arrays? That way future compiler
> releases won't get sniffy about this non-ARM package. OTOH, it isn't
> broken now ...
Difficult call. I implemented Ada.Numerics.Generic_Complex_Arrays.
Generic_Roots according to the (proposed) specification, but I don't
know how hard it would be to move.
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
^ permalink raw reply [relevance 0%]
* Re: ANN: Ada 2005 Math Extensions, 20100901 release
@ 2010-09-03 5:58 6% ` Simon Wright
2010-09-03 13:48 0% ` John B. Matthews
0 siblings, 1 reply; 123+ results
From: Simon Wright @ 2010-09-03 5:58 UTC (permalink / raw)
"John B. Matthews" <nospam@nospam.invalid> writes:
> For future reference, here is the patch:
>
> <http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01623.html>
Interesting. On Mac OS X, GNAT GPL 2010 i-forbla.adb contains
package body Interfaces.Fortran.BLAS is
pragma Linker_Options ("-lgnala");
pragma Linker_Options ("-lm");
pragma Linker_Options ("-Wl,-framework,vecLib");
end Interfaces.Fortran.BLAS;
> The compiler options from ada_math_build.gpr should work,
> e.g. gnatmake -a or gcc -c -gnatpg. Finally, copy the .ali and .o to
> your Ada library path, `gnatls -v`.
I don't see why you'd do this 'by hand' rather than letting
ada_math_build.gpr do the heavy lifting?
If you do do this, (a) make sure the .ali is read-only, (b) copy
ada-numerics-generic_arrays.ad[bs] too (to the source search path, of
course).
I'm having 4th or 5th thoughts about package naming. Perhaps I should
make it Ada_Numerics.Generic_Arrays? That way future compiler releases
won't get sniffy about this non-ARM package. OTOH, it isn't broken now
...
^ permalink raw reply [relevance 6%]
* Re: Interfacing Ada with C
2010-07-25 23:21 5% ` Simon Wright
@ 2010-07-26 1:24 0% ` John B. Matthews
0 siblings, 0 replies; 123+ results
From: John B. Matthews @ 2010-07-26 1:24 UTC (permalink / raw)
In article <m2iq43rvv1.fsf@pushface.org>,
Simon Wright <simon@pushface.org> wrote:
> I've encoded a general complex eigenvalues function, interfacing to the
> LAPACK procedure zgeev, starting from a demo at
> http://www.physics.oregonstate.edu/~rubin/nacphy/lapack/codes/eigen-c.html
> & copying bits and pieces from within the GNAT implementation of
> Ada.Numerics.Generic_Complex_Arrays.
>
> Find it at http://public.me.com/simon.j.wright (folder numerics).
Exemplary!
> NB1 LAPACK is a Fortran code, hence the need to transpose the matrix.
>
> NB2 the compilation gives warnings ..
>
> $ gnatmake test_zgeev.adb
> gcc -c test_zgeev.adb
> test_zgeev.adb:9:06: warning: "Interfaces.Fortran.BLAS" is an internal GNAT unit
> test_zgeev.adb:9:06: warning: use of this unit is non-portable and version-dependent
> test_zgeev.adb:10:06: warning: "Interfaces.Fortran.LAPACK" is an internal GNAT unit
> test_zgeev.adb:10:06: warning: use of this unit is non-portable and version-dependent
For convenience, the warnings may be suppressed:
pragma Warnings("I");
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
^ permalink raw reply [relevance 0%]
* Re: Interfacing Ada with C
@ 2010-07-25 23:21 5% ` Simon Wright
2010-07-26 1:24 0% ` John B. Matthews
0 siblings, 1 reply; 123+ results
From: Simon Wright @ 2010-07-25 23:21 UTC (permalink / raw)
Ada novice <posts@gmx.us> writes:
> Many thanks for all your inputs. I'll give you an example. Say we want
> to compute the eigenvalues of this 3 X 3 matrix. The code in C (using
> the IMSL library) is as follows:
[...]
> What would the best way to interface this with Ada? The elements of my
> matrix will be formed in Ada, then the matrix will be passed to C to
> calculate the eigenvalues and then the latter passed back to Ada. The
> size of my matrix will be fixed say 3 x 3. As a novice in Ada, I would
> like to learn good programming practice and the best way is to use
> codes and learn from experts here in Ada.
I've encoded a general complex eigenvalues function, interfacing to the
LAPACK procedure zgeev, starting from a demo at
http://www.physics.oregonstate.edu/~rubin/nacphy/lapack/codes/eigen-c.html
& copying bits and pieces from within the GNAT implementation of
Ada.Numerics.Generic_Complex_Arrays.
Find it at http://public.me.com/simon.j.wright (folder numerics).
NB1 LAPACK is a Fortran code, hence the need to transpose the matrix.
NB2 the compilation gives warnings ..
$ gnatmake test_zgeev.adb
gcc -c test_zgeev.adb
test_zgeev.adb:9:06: warning: "Interfaces.Fortran.BLAS" is an internal GNAT unit
test_zgeev.adb:9:06: warning: use of this unit is non-portable and version-dependent
test_zgeev.adb:10:06: warning: "Interfaces.Fortran.LAPACK" is an internal GNAT unit
test_zgeev.adb:10:06: warning: use of this unit is non-portable and version-dependent
gnatbind -x test_zgeev.ali
gnatlink test_zgeev.ali
$
However, (a) one could always write ones own versions, (b) the results
are the same with GNAT GPL 2010 and GCC 4.5.0, (c) the output looks good
(from your inputs) ..
$ ./test_zgeev
2.00000000000000E+00 4.00000000000000E+00
2.00000000000000E+00 -4.00000000000000E+00
9.99999999999996E-01 2.07319734774360E-16
I get the strong impression that to know what the arguments of the BLAS
& LAPACK subprograms are you have to buy the book or read the code!
This all worked without any need for additional link-time arguments on
Mac OS X, but YMMV on Windows. If not, I *think* that if you with
Ada.Numerics.Long_Complex_Arrays (no need to use anything from it) that
would be enough to bring in the necessary libraries.
^ permalink raw reply [relevance 5%]
* Re: How to exit a loop with keyboard input
2010-04-13 21:22 5% ` Simon Wright
@ 2010-04-15 3:39 0% ` Jerry
0 siblings, 0 replies; 123+ results
From: Jerry @ 2010-04-15 3:39 UTC (permalink / raw)
On Apr 13, 2:22 pm, Simon Wright <si...@pushface.org> wrote:
> Jerry <lancebo...@qwest.net> writes:
> > However, both of these builds still contain the old bug which arises
> > when using
> > Ada.Numerics.Long_Real_Arrays;
> > in which the linker can't find the non-existent (on OS X) library
> > lgnalasup (linear algebra support) requested by i-forbla.adb. I
> > thought this was fixed a long time ago and if I'm reading the history
> > correctly it was fixed on Apr 22 07:14:31 2008. I suppose I should
> > raise this on another thread, however.
>
> Same here.
>
> $ gnatmake jerry
> gcc -c jerry.adb
> gnatbind -x jerry.ali
> gnatlink jerry.ali
> ld: library not found for -lgnalasup
> collect2: ld returned 1 exit status
> gnatlink: error when calling /opt/gnat-gpl-2009-x86_64/bin/gcc
> gnatmake: *** link failed.
>
> (sorry to take your name in vain, it helps me to keep my ~/tmp
> code in order)
>
> 4.5.0 has a Darwin-specific i-forbla.adb containing
>
> OX--------------------------------------------
> -- Version for Mac OS X
>
> package body Interfaces.Fortran.BLAS is
> pragma Linker_Options ("-Wl,-framework,vecLib");
> end Interfaces.Fortran.BLAS;
> OX--------------------------------------------
>
> and I just managed to link (just a 'with', no execution) with GNAT GPL
> 2009 by compiling against this file -- I put it in a subdir called math
> and said
>
> $ gnatmake jerry -a -Imath
> gcc -gnatpg -c -Imath i-forbla.adb
> gnatbind -Imath -x jerry.ali
> gnatlink jerry.ali
Awesome. In the past I discovered that if I delete the inappropriate
linker pragma in i-forbla.adb and link with -largs to the BLAS and
LAPACK libraries in the OS X frameworks that I could work around this
problem. But this is better. Following your lead, I moved the newly-
made i-forbla.o and i-forbla.ali into
/opt/gnat-gpl-2009/lib/gcc/i386-apple-darwin9.7.0/4.3.4/adalib
I then moved /opt/gnat-gpl-2009 to /usr/local/ada-4.3 which is where
the Xcode Ada plug-in expects to find a compiler. I also moved your /
opt/gnu/ to /usr/local/gnu.
I can now compile a small program that uses Real_Vector etc. and has a
non-blocking Get_Immediate without any compiler switches using Xcode
with the (ever-brittle) Ada plug-in. 8o)
Trying to use the GUI debugger within Xcode,
(Apple version gdb-768) (Tue Oct 2 04:07:49 UTC 2007)
is mostly successful but it bombs with SIGBUS when trying to single-
step past a Put_Line.
I have also applied the fix to AdaCore's GPL 2009.
Unfortunately, with the new set-up, building PLplot (to which I wrote
Ada bindings) now results in the linker complaining of some dylibs,
"file is not of required architecture."
Jerry
^ permalink raw reply [relevance 0%]
* Re: How to exit a loop with keyboard input
@ 2010-04-13 21:22 5% ` Simon Wright
2010-04-15 3:39 0% ` Jerry
0 siblings, 1 reply; 123+ results
From: Simon Wright @ 2010-04-13 21:22 UTC (permalink / raw)
Jerry <lanceboyle@qwest.net> writes:
> However, both of these builds still contain the old bug which arises
> when using
> Ada.Numerics.Long_Real_Arrays;
> in which the linker can't find the non-existent (on OS X) library
> lgnalasup (linear algebra support) requested by i-forbla.adb. I
> thought this was fixed a long time ago and if I'm reading the history
> correctly it was fixed on Apr 22 07:14:31 2008. I suppose I should
> raise this on another thread, however.
Same here.
$ gnatmake jerry
gcc -c jerry.adb
gnatbind -x jerry.ali
gnatlink jerry.ali
ld: library not found for -lgnalasup
collect2: ld returned 1 exit status
gnatlink: error when calling /opt/gnat-gpl-2009-x86_64/bin/gcc
gnatmake: *** link failed.
(sorry to take your name in vain, it helps me to keep my ~/tmp
code in order)
4.5.0 has a Darwin-specific i-forbla.adb containing
OX--------------------------------------------
-- Version for Mac OS X
package body Interfaces.Fortran.BLAS is
pragma Linker_Options ("-Wl,-framework,vecLib");
end Interfaces.Fortran.BLAS;
OX--------------------------------------------
and I just managed to link (just a 'with', no execution) with GNAT GPL
2009 by compiling against this file -- I put it in a subdir called math
and said
$ gnatmake jerry -a -Imath
gcc -gnatpg -c -Imath i-forbla.adb
gnatbind -Imath -x jerry.ali
gnatlink jerry.ali
^ permalink raw reply [relevance 5%]
* Re: Learning Ada (Was: unsigned type)
@ 2009-07-06 0:05 6% ` Ludovic Brenta
0 siblings, 0 replies; 123+ results
From: Ludovic Brenta @ 2009-07-06 0:05 UTC (permalink / raw)
anon top-posted on comp.lang.ada:
> Wrong!
> I was not talking about the Ada Statements "Type" or "Subtype" but
> true Standards that go beyond Ada.
Please define a "true standard" (as opposed to a "standard") and what
it means for a "true standard" to "go beyond" Ada. "go beyond" is a
non-standard phrase, it does not appear anywhere in the ARM.
[use the language-defined Integer and Float]
> But some people like "Ludovic Brenta, state that most Ada programmers
> would prefer to create their own types.
I did not state that; I don't know what "most Ada programmers" do or
where they are, and I don't use the "lemming argument" because I
honestly don't care what "most people" do in general. If I wanted to
do what "most people" do, I would not program in Ada. What I said is
that it is generally *better* to use application-defined types than
language-defined types; this is the proper and intended way to use
Ada.
> In some case, that goes against the RM
> because it can create a non-standardize form of an Ada programs, that violate
> other RM rules.
If a program violates other RM rules and the compiler properly
enforces the rules, then the program won't compile. What was your
point?
> Plus, the RM states that a number of numeric types are
> predefined, such as "Integer", and it subtypes "Natural" and "Positive" as
> well the type "Float" and its subtypes. Redefining those predefines types are
> legal in Ada, by simply re-defining the type. Like for example, using 24 bit
> integer:
>
> type Integer is range -2 ** 24 .. +2 ** ( 24 - 1 ) ;
Wrong; your declaration is legal but it does not "redefine"
Standard.Integer; it defines a new type with the same name.
> To use this new definition of "Integer", globally it needs to be define in the
> standard package, but for a single package or routine it better to create a new
> type or subtype and for the routine or package.
No; it is better to define an application-specific type instead. By
declaring a type Integer in your own package, you create a new problem
(global visibility of your new type) without solving any existing
problem, so this is not only useless but harmful. I've seen it done
in several places before and the reasons given to me for doing that
were always wrong. At least they avoided using the name Integer but
used Integer_Type or something similarly stupid instead. By the same
token, changing the definition of Standard.Integer achieves nothing
useful and is a lot of trouble, so don't do that.
> But in most programming this
> is not necessary. That is, since Ada creation and the DOD dropping it full
> support of Ada, the usage for redefining the numeric data types is almost nil,
> not the norm any more. Plus, the DOD require full documentation on all new
> define types. And no matter what type is defined the compiler will fall back to the
> basic standards of the universal-integer and universal-real aka CPU integer
> and FPU float and their operations. If you study most of the implementations of
> Ada, one can see that the types "Integer" and "Float" that are defined in the
> "Standard" package are basically equivalent to the Ada's universal-integer and
> universal-real.
So what? If you don't want compile-time type checks and only care
about the hardware-defined types, then go program in assembly
language.
> Now, "Rob Solomon" stated that he think "it would be beneficial, if
> the types Float and Integer were removed from the language".
No, that was Jacob Sparre Andersen.
> First, if this could happen the RM would need a MAJOR overhaul.
> It would be easier to create a new language. Because both types are used
> throughout the RM defined packages.
>
> Second, the predefined types allow for the program to be more portable,
> because a users type might not be accepted on the new system.
I'm sure Jacob is well aware of that. For your second objection, it
is a *Good* *Thing* if the compiler says up-front, at compile time,
whether it supports the application-defined types or not. It is a
*Bad* *Thing* if the compiler is silent and the application later
misbehaves because the hardware doesn't support the application
constraints.
[...]
> Then third, is without standards types like "Integer" and "Float" how
> would the system work. Using Ada, define a "=" or "*" without using the
> universal-integer and universal-real types or there operations. You can not!
You seem to be confusing the unioversal_integer and universal_real
types (which are anonymous) with Standard.Integer and Standard.Float,
respectively. They are *not* the same things. Even if
Standard.Integer and Standard.Float disappeared, unioversal_integer
and universal_real would still exist and allow the arithmetic
operations you describe.
[...]
> Fourth, is to interface with other languages. which also use standards.
> Some Ada programmer prefer pure Ada code. Like using the "Interface"
> package to only define the standard unsigned types and to use the low-level
> shift and rotate routines for those unsigned types. But there are times when
> interfacing is required.
For interfacing to C, you use Interfaces.C.int, not Standard.Integer,
and Interfaces.C.C_float, not Standard.Float. For COBOL you use
Interfaces.COBOL.Binary and Interfaces.COBOL.Floating. For Fortran,
you use Interfaces.Fortran.Fortran_Integer and
Interfaces.Fortran.Real. If "some Ada programmers" prefer
Standard.Integer and Standard.Float against the ARM, then they are
wrong. Nowhere does the ARM state what Standard.Integer or
Standard.Float correspond to in C, COBOL or Fortran.
--
Ludovic Brenta.
^ permalink raw reply [relevance 6%]
* Re: gnatmake, gnat2007. Linking to lapack and blas using with Ada.Numerics.Generic_Real_Arrays;
@ 2007-08-12 9:53 5% ` Marc Enzmann
0 siblings, 0 replies; 123+ results
From: Marc Enzmann @ 2007-08-12 9:53 UTC (permalink / raw)
Hi Jerry!
The libraries for MacOS -on my MacBook with 10.4- are libBLAS.dylib
and
libLAPACK.dylib, so no problem here, but:
I had to tinker with the Interfaces.Fortran.BLAS package, which is
used
to write Ada wrappers for the BLAS and LAPACK functions. The
"standard"
i-forbla.ads uses pragma import to access Fortran Routines, which are
not
available on standard Mac OS. I had to replace the Fortran Routines in
the
import with C Routines. Not a clean solution, really.
It works, but I am not sure, whether I mapped all routines correctly.
Not much time to check ...
Send me an e-mail, if you would like to try my workaround.
Best regards,
Marc
On 12 Aug., 03:01, Jerry <lancebo...@qwest.net> wrote:
> Has anyone done this on OS X? I believe that lapack and blas are pre-
> installed but might be called clapack and cblas.
>
> Jerry
>
^ permalink raw reply [relevance 5%]
* Re: Just a thought!
2007-07-25 12:43 3% ` anon
@ 2007-07-26 23:37 0% ` Xianzheng Zhou
0 siblings, 0 replies; 123+ results
From: Xianzheng Zhou @ 2007-07-26 23:37 UTC (permalink / raw)
This is a rather long-term approach. I haven't seen that far yet:) I'm
planning to do a nanokernel, it's basically an abstraction of the cpu
layer and do nothing more than that.
The idea is to build more complex kernel on top of that which makes it
flexible, so that it's flexible to be re-planted to other hardware
platform and even embedded system without modifying the complex upper
part of the kernel. And it can be built as small as possible, rather
than heavy-weight, super advanced operating system.:)
Just my thought. Feel free to comments:)
thanks,
xianzheng
anon wrote:
> It is feasible if you have the time! I have written the "True Ada OS"
> kernel. The kernel is a non-Posix system which uses all three Intel
> protective rings as a security design. Except for the ASM instructions
> that are embedded in the Ada source code there are no assembly
> routines, the bios boot the kernel by jumping to the Ada code startup
> procedure. Also, the kernel runs in a 100% preemptive design which
> means after kernel is active the use of the "cli" and "sti" instruction
> are not allowed because they could allow non-preemptive coding.
>
> The kernel does test memory and calculate page sizes and tables as
> well as testing for devices but does limits the graphics card to the
> standard VGA mode only. Just too many cards and no standardized
> for SVGA mode, plus Ada has only limited graphics capabilities. Works
> with Linksys network cards as well as having a few file systems
> including it own version. So no need for GRUB or use of multiboot which
> could allow virus, due to the fact that GRUB is written in real (DOS)
> mode. Also, once loaded into memory and control is passed to kernel
> there are no BIOS calls, device drivers built-in. The prototype is
> native CD/DVD Bootable, with swapper partition optional. After
> booting it loads from the CD a controller shell.
>
> Using the initial kernel I have three extra projects. One is to write a
> compiler/binder/linker for the kernel (in the processes now). Gnat
> compiler has some designs fault that makes partition building difficult
> for this system, plus modifying the code would take more time then
> starting from scratch. Also, Gnat allows language interfaces and some
> non standard Ada features which this compiler and system will not.
> Only Pure Standard Ada code will compile and run in this system.
>
> And the second project is to replace the "BIOS ROM" with the kernel and
> a system configurator written in Ada. Initial test used an old ethernet
> card with a rom boot slot to test booting the system. Later after the
> compiler project if finished I will take an older PII and flash the bios
> prom with the kernel and configurator. So the whole system will then run
> pure Ada code.
>
> The third is to install the kernel in a "Core 2 Quad", later this year or
> maybe if Intel create the "Core 2 Octal", next year. This will give Ada
> a true parallel and multi-task design.
>
> With the PII test system and the "Core 2 Quad" Ada bios the computer
> system could be called a "True Ada Machine". Something like the old
> "Lisp Machines" except that this system will allow growth so long as
> the code is written in Ada. After that I have number of projects lined
> up to use the either the CD-Bootable Ada OS version or the
> "True Ada Machine".
>
> Note: The Interface package is limited to the parent package only. Which
> means not foreign languages or sub packages will exist. Such as
> Interfaces.C, Interfaces.COBOL, and Interfaces.Fortran. Also, the
> Ada.Machine_Code package will not all the ASM instruction only special
> calls to selected number of assembly instructions. So the Ada will be
> called a limited subset of Ada because of the specification RM B.2 ( 1 ).
>
>
>
> Now, what do you need to know! First, the complete features of Ada,
> the computer system, the processor assembly language as well as the
> hardware that is installed. And you will need a lot of time for research
> and writing code. It is not someone thinks about playing with. I
> know a couple of programmers that are using an Ada OS as their doctoral
> thesis, their prof thinks the task is too great for them but they have 7
> years to finish it. Of course, they should think what types of computer
> system will exist in 7 years from now. And will their code still work.
>
>
> In <f86rrl$6qf$1@aioe.org>, Xianzheng Zhou <joe@lgsolutions.com.au> writes:
>> Hello everyone,
>>
>> I'm just thinking about writing a nanokernel using Ada. I don't know
>> whether this idea is feasible or not, just wanna have a play around with it.
>> Any suggestions please?:)
>>
>> Thanks,
>>
>> Xianzheng
>
^ permalink raw reply [relevance 0%]
* Re: Just a thought!
@ 2007-07-25 12:43 3% ` anon
2007-07-26 23:37 0% ` Xianzheng Zhou
0 siblings, 1 reply; 123+ results
From: anon @ 2007-07-25 12:43 UTC (permalink / raw)
It is feasible if you have the time! I have written the "True Ada OS"
kernel. The kernel is a non-Posix system which uses all three Intel
protective rings as a security design. Except for the ASM instructions
that are embedded in the Ada source code there are no assembly
routines, the bios boot the kernel by jumping to the Ada code startup
procedure. Also, the kernel runs in a 100% preemptive design which
means after kernel is active the use of the "cli" and "sti" instruction
are not allowed because they could allow non-preemptive coding.
The kernel does test memory and calculate page sizes and tables as
well as testing for devices but does limits the graphics card to the
standard VGA mode only. Just too many cards and no standardized
for SVGA mode, plus Ada has only limited graphics capabilities. Works
with Linksys network cards as well as having a few file systems
including it own version. So no need for GRUB or use of multiboot which
could allow virus, due to the fact that GRUB is written in real (DOS)
mode. Also, once loaded into memory and control is passed to kernel
there are no BIOS calls, device drivers built-in. The prototype is
native CD/DVD Bootable, with swapper partition optional. After
booting it loads from the CD a controller shell.
Using the initial kernel I have three extra projects. One is to write a
compiler/binder/linker for the kernel (in the processes now). Gnat
compiler has some designs fault that makes partition building difficult
for this system, plus modifying the code would take more time then
starting from scratch. Also, Gnat allows language interfaces and some
non standard Ada features which this compiler and system will not.
Only Pure Standard Ada code will compile and run in this system.
And the second project is to replace the "BIOS ROM" with the kernel and
a system configurator written in Ada. Initial test used an old ethernet
card with a rom boot slot to test booting the system. Later after the
compiler project if finished I will take an older PII and flash the bios
prom with the kernel and configurator. So the whole system will then run
pure Ada code.
The third is to install the kernel in a "Core 2 Quad", later this year or
maybe if Intel create the "Core 2 Octal", next year. This will give Ada
a true parallel and multi-task design.
With the PII test system and the "Core 2 Quad" Ada bios the computer
system could be called a "True Ada Machine". Something like the old
"Lisp Machines" except that this system will allow growth so long as
the code is written in Ada. After that I have number of projects lined
up to use the either the CD-Bootable Ada OS version or the
"True Ada Machine".
Note: The Interface package is limited to the parent package only. Which
means not foreign languages or sub packages will exist. Such as
Interfaces.C, Interfaces.COBOL, and Interfaces.Fortran. Also, the
Ada.Machine_Code package will not all the ASM instruction only special
calls to selected number of assembly instructions. So the Ada will be
called a limited subset of Ada because of the specification RM B.2 ( 1 ).
Now, what do you need to know! First, the complete features of Ada,
the computer system, the processor assembly language as well as the
hardware that is installed. And you will need a lot of time for research
and writing code. It is not someone thinks about playing with. I
know a couple of programmers that are using an Ada OS as their doctoral
thesis, their prof thinks the task is too great for them but they have 7
years to finish it. Of course, they should think what types of computer
system will exist in 7 years from now. And will their code still work.
In <f86rrl$6qf$1@aioe.org>, Xianzheng Zhou <joe@lgsolutions.com.au> writes:
>Hello everyone,
>
>I'm just thinking about writing a nanokernel using Ada. I don't know
>whether this idea is feasible or not, just wanna have a play around with it.
>Any suggestions please?:)
>
>Thanks,
>
>Xianzheng
^ permalink raw reply [relevance 3%]
* Interfacing Gnat to Fortran Complex*16
@ 2005-01-10 14:29 5% Steve Sangwine
0 siblings, 0 replies; 123+ results
From: Steve Sangwine @ 2005-01-10 14:29 UTC (permalink / raw)
Has anyone tried and succeeded in interfacing Ada code compiled with
Gnat (gcc 3.4.2 version) to Fortran code, passing double precision
complex arrays to the Fortran code (Complex*16)?
Background: the LRM Annex B specifies only single precision complex
in Interfaces.Fortran, and I have code for which this works (I am
interfacing to the LAPACK numerical library). LAPACK contains a
double precision version of the routine I am using and I would like
to interface to it.
Problem: although the single precision routine works fine, the double
precision code goes into an apparently infinite loop.
Steve Sangwine
University of Essex, UK.
^ permalink raw reply [relevance 5%]
* Re: Fortran Interface
@ 2004-08-06 11:46 5% ` Dr Steve Sangwine
0 siblings, 0 replies; 123+ results
From: Dr Steve Sangwine @ 2004-08-06 11:46 UTC (permalink / raw)
On Tue, 3 Aug 2004 18:15:20 +0000 (UTC), Georg Bauhaus
<sb463ba@l1-hrz.uni-duisburg.de> wrote:
>Wes Groleau <groleau+news@freeshell.org> wrote:
>: Dan Nagle wrote:
>:> Has there been any thought, in Ada0Y, to improving
>:> the interface to Fortran?
>:>
>:> Fortran 2003 in a long way from 77.
>:
>: But is there any difference in what matters for _interfacing_ ?
What about double precision complex types. Interfaces.Fortran includes
only single precision complex, which is not much use when the default
these days is often double.
Steve Sangwine
^ permalink raw reply [relevance 5%]
* Re: A couple of questions
@ 2004-05-01 15:37 4% ` Ed Falis
0 siblings, 0 replies; 123+ results
From: Ed Falis @ 2004-05-01 15:37 UTC (permalink / raw)
On Sat, 1 May 2004 15:12:33 +0000 (UTC), Yeric <NOSPAM@NOSPAM.com> wrote:
> Thank you for your insight.
I'll take a crack at some of these - I'm sure there will be some errors.
> How well does ADA interface with other languages ?
Ada is one of the few languages whose design attended to issues of
interfacing to other languages. It does well, particularly with C,
Fortran, assember, and reasonably well with a lot of others. There are
specific capabilities to force calling conventions to match those of other
languages, and there are specific packages that provide definitions of
common base types from other languages (eg Interfaces.C,
Interfaces.Fortran ...).
> I know it has capabilities to interface with ADO through COM, what about
> .NET, Can ADA do this now, are there any plans for the future ?
I believe Martin Carlisle at the USAF Academy and his team have made a
port of GNAT to .NET.
>
> I also read that ADA is reviewd every 10 years, so does this mean the
> language is going to change/enhance in any way for 2005 ?
There are a number of revision issues being considered at this time, for
enhancement to the standard in roughly 2005.
>
> One thing that makes me feel a bit uneasy about adopting ADA is that
> there
> seems to be very little activity on web pages for it, and the ADA FAQ is
> dated 1997, even some projects that are good now have not changed in
> over a
> year.
Don't know what to tell you. libre.act-europe.fr is updated on a pretty
regular basis.
> How would ADA handle incorrect data types being input apart from
> exception
> handling or lots of messy if then statements ?
Usually by exception handling, though there is a typename'Valid (x)
attribute available that can be used on input of broader type than
"typename" to explicitly test.
>
> I would very much like to know any thoughts advantages/disadvantes of ADA
> compared to another language, but I dare not mention the other languages
> name to avoid being called a TROLL or starting a debate of this language
> is
> better than that, like a similar post I noted about OO operating systems.
Well, you are on comp.lang.ada, so the likelihood of a flameware is less
(the other posting went to a variety of language newsgroups, so invited it
a bit more). It's difficult to state advantages in the abstract.
I've done more than dabbling in quite a few languages, including Java,
Eiffel, C++, Lisp, ... The things I most appreciate about Ada are its
flexibility, its clean syntax, well-defined semantics, and its portability
(oh yeah, and its helpful compilers). A nice combination. Other
languages I've used are IMO superior in certain areas, but don't bring
that particular balance that I prefer.
> It is interesting to see that ADA supports range checking, but how about
> data type checking, does range checking preclude the need for exception
> handling for a number too large being entered ?
Certain type checking can be done at compile time; other checking requires
run-time checks. In the latter case, exceptions are the standard way of
flagging a violation.
>
> I guess design by contract could be handled using lots of if then
> statements
> and carefully crafted exception handling statements ?
Several compilers provide the implementation-defined pragma Assert, that
can be used to plant assertions in the code - It provides a lot of DBC,
though it is not as powerful as what is found in Eiffel. I believe this
pragma is being added to the next revision of Ada. Again, the mechanism
used to enforce the assertion is an exception.
>
> Can ADA interface with OpenGL ? have any games been written in ADA/would
> ADA
> be suited for games programming ?
I don't know about games. The mailing list oglada@niestu.com is all about
OpenGL bindings and use.
>
> Are there any GUI designers available for ADA like in VB? even if this is
> just designing them and compiling as a resource or exporting as ADA code
> ?
glade is available for use with GTKAda. ObjectAda has a GUI builder for
Windows. There are others, I'm sure.
>
> I have seen a couple of Commercial products for ADA Gnat Pro and GPS, but
> there are no published prices for this software.
Contact sales@gnat.com or sales@act-europe.fr. These products are mainly
oriented towards project customers and consultative support (disclaimer: I
work for AdaCore). ObjectAda from Aonix has a relatively inexpensive
version available. RR Software almost certainly does as well. But most
hobbiests will use public distributions of GNAT.
> I have bookmarked ADApower.com, any other web sites that may be of
> interest
> ?
www.adaworld.com, libre.act-europe.fr
- Ed
^ permalink raw reply [relevance 4%]
* Re: New Language Design: (Cray, Sun prep radical software models for petaflops systems)
2003-11-26 15:25 5% ` Georg Bauhaus
@ 2003-11-27 12:33 6% ` Dan Nagle
0 siblings, 0 replies; 123+ results
From: Dan Nagle @ 2003-11-27 12:33 UTC (permalink / raw)
Hello,
On Wed, 26 Nov 2003 15:25:17 +0000 (UTC), Georg Bauhaus
<sb463ba@l1-hrz.uni-duisburg.de> wrote:
>Dan Nagle <dnagle@erols.com> wrote:
>: (Fortran 2003 has "Interoperability with C", which the subgroup
>: claims includes interoperability with Ada, if the Ada side is
>: also interoperating with C. So it's C as universal assembler.)
>
>Does the interoperability include more features than are currently
>covered by Ada's Interfaces.Fortran?
IIRC (I'd have to investigate to fully recall Interfaces.Fortran),
the Ada interoperability is largely, at least, Fortran 77.
Fortran 2003 Interoperability allows passing Fortran derived types,
uses the Fortran kind system to select the interoperating types,
allows passing and converting pointers (data and procedure). Et al.
It's intended to be a full-blown feature.
The Interoperability subgroup of J3 has assured me that
Interoperating with Ada (etc.) is possible, if the interoperating
language can interoperate with C. Any comments from Ada
programmers regarding a perceived difficulty would be welcome,
but the Fortran standards approval process is moving quickly!
>
>-- Georg
BTW, if the PDF doesn't suit, you may root around the site a bit
and download the PS, text, or the LaTeX source itself. PDF is
the "usual" format, it's the one the bureaucrats at ISO formally
read and publish.
http://www.j3-fortran.org
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
^ permalink raw reply [relevance 6%]
* Re: New Language Design: (Cray, Sun prep radical software models for petaflops systems)
@ 2003-11-26 15:25 5% ` Georg Bauhaus
2003-11-27 12:33 6% ` Dan Nagle
0 siblings, 1 reply; 123+ results
From: Georg Bauhaus @ 2003-11-26 15:25 UTC (permalink / raw)
Dan Nagle <dnagle@erols.com> wrote:
: (Fortran 2003 has "Interoperability with C", which the subgroup
: claims includes interoperability with Ada, if the Ada side is
: also interoperating with C. So it's C as universal assembler.)
Does the interoperability include more features than are currently
covered by Ada's Interfaces.Fortran?
-- Georg
^ permalink raw reply [relevance 5%]
* A question relating to package interfaces.fortran
@ 2003-03-01 10:02 13% ` Zheng Long Gen
0 siblings, 0 replies; 123+ results
From: Zheng Long Gen @ 2003-03-01 10:02 UTC (permalink / raw)
To: comp.lang.ada mail to news gateway
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 1954 bytes --]
Hi, all,
Forgive my ignorance, if this is a repeated post.
In the following code, one tries to do math calculation on values of
complex types defined in interfaces.fortran.
-----------------------------------------------------------------------
with Interfaces.Fortran;
use Interfaces.Fortran;
with Ada.Numerics.Generic_Complex_Elementary_Functions;
procedure Complex_Type is
package Complex_Elementary_Functions is
new Ada.Numerics.Generic_Complex_Elementary_Functions
(Single_Precision_Complex_Types);
use Complex_Elementary_Functions;
C1,c2:Complex:=(0.5,0.0);
begin
C2:=Sin(C1);
end;
------------------------------------------------------------------------
Compiling this piece of code(gnat 3.13p, Redhat 7.3.2) will result in the
following message:
gnatgcc -c -g -gnatq complex_type.adb
complex_type.adb:10:12: expected type
"Ada.Numerics.Generic_Complex_Types.Complex" from instance at i-fortra.ads:37
complex_type.adb:10:12: found type "Interfaces.Fortran.Complex"
package interfaces.fortran defines types to interface with fortran
subprograms. The complex type is defined in the following way: (from RM
B.5)
---------------------------------------------------------------------------
package Single_Precision_Complex_Types is
new Ada.Numerics.Generic_Complex_Types (Real);
type Complex is new Single_Precision_Complex_Types.Complex;
subtype Imaginary is Single_Precision_Complex_Types.Imaginary;
----------------------------------------------------------------------------
The problem is :
Type complex is a new type. It is different from its ancester defined in
single_precision_complex_types. It should be a subtype of
single_precision_complex_types.complex , just like the definition of "subtype
Imaginary". Otherwise, it is totally useless. What do you think of it?
Many thanks in advance.
zhenggen
20020301
^ permalink raw reply [relevance 13%]
* Passing Unconstrained Arrays from FORTRAN to an Ada95 subunit
@ 2002-07-20 0:57 6% Karen Carron
0 siblings, 0 replies; 123+ results
From: Karen Carron @ 2002-07-20 0:57 UTC (permalink / raw)
What I have found is that the offset in referencing individual array
elements in FORTRAN is 1 (ex. the first element is referenced with a
subscript of value 1) but in Ada it is 0. This is causing a problem
since the subscripts are variables in a fortran common.
Here is an example of what I'm trying to do:
FORTRAN calling routine:
program callada
common /subs/ i1,i2,i3
integer a(10)
i1 = 1
i2 = 2
i3 = 3
a(i1) = 10
a(i2) = 20
a(i3) = 30
call adainit
call pass_array(a)
stop
end
...
Ada units:
package type_decl is
type int_array_type is array(integer range <>) of integer;
end type_decl;
...
with type_decl; use type_decl;
package routines is
procedure pass_array (a : in out int_array_type);
pragma export (fortran, pass_array, "pass_array");
end routines;
...
package common_subs is
type subs_rec is
i1, i2, i3 : integer;
end record;
subs : subs_rec;
pragma volatile (subs);
pragma import_object (subs, "subs");
end common_subs;
...
with common_subs;
package body routines is
-- pass_array can be called by more than one unit with varying
-- sizes of arrays
procedure pass_array (a : in out int_array_type) is
var1 : integer;
begin
var1 := a(common_subs.subs.i1) + a(common_subs.subs.i2);
end pass_array;
end routines;
In the fortran equivalent of pass_array, the var1 would be 30. But in
the ada version, var1 is 50. I tried the following but without any
success:
1) I modified type_decl package as follows:
-- added:
with interfaces.fortran; use interfaces.fortran;
package type_decl is
type int_array_type is array(integer range <>) of integer;
-- added:
pragma convention (fortran, int_array_type);
end type_decl;
2) I modified the original type_decl package as follows:
package type_decl is
-- I changed the range to positive from integer
type int_array_type is array(positive range <>) of integer;
end type_decl;
I would very much appreciate any other ideas.
Thanks!
^ permalink raw reply [relevance 6%]
* Problematic type definition in Interfaces.Fortran
@ 2001-11-26 15:15 14% Jacob Sparre Andersen
0 siblings, 0 replies; 123+ results
From: Jacob Sparre Andersen @ 2001-11-26 15:15 UTC (permalink / raw)
I have noticed what I consider a rather problematic type
definition in package Interfaces.Fortran. RM B.5(9):
type Complex is new Single_Precision_Complex_Types.Complex;
Since package
Ada.Numerics.Generic_Complex_Elementary_Functions is
instantiated using an instantiation of package
Ada.Numerics.Generic_Complex_Types, it is not possible to
instantiate it for type Interfaces.Fortran.Complex.
And authors of Fortran bindings (such as "lapada") have a
habit of using type Interfaces.Fortran.Complex. :-(
Here is a code example that illustrates the problem:
----------
with Ada.Numerics.Generic_Complex_Elementary_Functions;
with Interfaces.Fortran; use Interfaces.Fortran;
procedure Hack_Virker is
package KomplekseFunktioner is
new Ada.Numerics.Generic_Complex_Elementary_Functions
(Interfaces.Fortran.Single_Precision_Complex_Types);
use KomplekseFunktioner;
Psi :
Interfaces.Fortran.Single_Precision_Complex_Types.Complex;
II : constant
Interfaces.Fortran.Single_Precision_Complex_Types.Complex
:= (0.0, 1.0);
begin -- Hack_Virker
Psi := Exp(II);
end Hack_Virker;
----------
The problem is that since "Interfaces.Fortran.Complex" is
derived from
"Interfaces.Fortran.Single_Precision_Complex_Types.Complex",
and not just a subtype of
"Interfaces.Fortran.Single_Precision_Complex_Types.Complex",
there is no package to use for instantiating package
Ada.Numerics.Generic_Complex_Elementary_Functions.
Is there a very good reason for not making
"Interfaces.Fortran.Complex" a subtype of
"Interfaces.Fortran.Single_Precision_Complex_Types.Complex"?
Jacob
--
Sk�ne Sj�lland Linux User Group - http://www.sslug.dk/
N�ste m�de: IT-lovgivning.
Tirsdag den 27. november 2001 i Symbion, Fruebjergvej 3.
^ permalink raw reply [relevance 14%]
* Re: Naturals and discrete types
@ 2001-11-02 17:24 4% ` Ted Dennison
0 siblings, 0 replies; 123+ results
From: Ted Dennison @ 2001-11-02 17:24 UTC (permalink / raw)
In article <oGjE7.221593$K6.106487221@news2>, Clueless says...
>Also, I've been checking my Ada docs to find out if the Natural type is
>considered to be a Discrete or Real type by the GNAT compiler, but I
>havent found any specific info yet. Although the compiler messages
>certainly seem to indicate that Natural is a subtype of Real.
Boy are you confused!
Natural is a subtype of Integer with a range of 0 to Integer'last. It is defined
in package Standard (see
http://www.ada-auth.org/~acats/arm-html/RM-A-1.html#I4539 ). Thus you do *not*
need a conversion to use Natural where Integer is usable. However, you *do* need
a conversion ( "Float(My_Natural)" ) to use it where a Float is expected. There
is no type named "Real" (unless you count the one in Interfaces.Fortran), but
there are a class of types called "real", which includes floating-point and
fixed point types. The only predefined floating-point types is "Float" (and
"Long_Float" on some systems), and the only predefined fixed-point type is
"Duration".
This is all pretty basic stuff. If it is confusing you, you probably ought to go
read a good Ada book. If you don't want to shell out cash for one, there's one
online at http://www.it.bton.ac.uk/staff/je/adacraft/ . At least read through
chapter 5 there (http://www.it.bton.ac.uk/staff/je/adacraft/ch05.htm)
---
T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html
No trees were killed in the sending of this message.
However a large number of electrons were terribly inconvenienced.
^ permalink raw reply [relevance 4%]
* Re: Trying to pass strings to Fortan routines
2001-08-12 18:17 5% ` tmoran
@ 2001-08-13 18:28 0% ` Jack Scheible
0 siblings, 0 replies; 123+ results
From: Jack Scheible @ 2001-08-13 18:28 UTC (permalink / raw)
I was importing the routines as Fortran, so when I tried to pass the
lengths of the strings, the compiler converted those to pointers,
since Fortran passes everything by reference. Since C passes by
value, the Fortran routines now get the string lengths, not pointers
to the string lengths.
-jack
tmoran@acm.org wrote in message news:<MKzd7.57284$Kd7.32367559@news1.rdc1.sfba.home.com>...
> >Hideous, but it works.
> >I don't like having to call a Fortran subroutine as though it were C, but it
> >works.
> How does it differ from the method that got a Constraint_Error?
> Perhaps some tweak to the latter would make it work.
>
> In light of Dan Nagle's comment in <ppocntg7a1lqk4d2iatcd7hmt95269ubmr@4ax.com>
>
> >Actually, the Fortran standard only says what a program has to be able
> >to do with character arguments, not how to pass them. Popular
> >varieties of implementation include
> >
> >-passing character, then length, for each character argument,
> >-passing character with all the lengths at the end
> > of the calling sequence (which you have described in your post),
> >-and passing the address of a descriptor containing the address
> > and length of the character argument.
>
> Does your Gnat support Interfaces.Fortran in a way that matches your
> Fortran compiler? If so, that should be much easier. If they don't
> understand each other, they'll both have to speak some third way
> that they do both understand.
^ permalink raw reply [relevance 0%]
* Re: Trying to pass strings to Fortan routines
@ 2001-08-12 18:17 5% ` tmoran
2001-08-13 18:28 0% ` Jack Scheible
0 siblings, 1 reply; 123+ results
From: tmoran @ 2001-08-12 18:17 UTC (permalink / raw)
>Hideous, but it works.
>I don't like having to call a Fortran subroutine as though it were C, but it
>works.
How does it differ from the method that got a Constraint_Error?
Perhaps some tweak to the latter would make it work.
In light of Dan Nagle's comment in <ppocntg7a1lqk4d2iatcd7hmt95269ubmr@4ax.com>
>Actually, the Fortran standard only says what a program has to be able
>to do with character arguments, not how to pass them. Popular
>varieties of implementation include
>
>-passing character, then length, for each character argument,
>-passing character with all the lengths at the end
> of the calling sequence (which you have described in your post),
>-and passing the address of a descriptor containing the address
> and length of the character argument.
Does your Gnat support Interfaces.Fortran in a way that matches your
Fortran compiler? If so, that should be much easier. If they don't
understand each other, they'll both have to speak some third way
that they do both understand.
^ permalink raw reply [relevance 5%]
* Re: LLQ: -1 a valid boolean?
2000-05-21 0:00 6% ` Robert Dewar
@ 2000-05-23 0:00 0% ` Ted Dennison
2000-05-23 0:00 0% ` David C. Hoos, Sr.
2000-05-23 0:00 0% ` Robert Dewar
0 siblings, 2 replies; 123+ results
From: Ted Dennison @ 2000-05-23 0:00 UTC (permalink / raw)
In article <8g8o3b$9l0$1@nnrp1.deja.com>,
Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <39253CD0.C8DC893D@telepath.com>,
> Ted Dennison <dennison@telepath.com> wrote:
> > You'd think that a value that is legal in situ ought to be
> > legal to assign as well. Then again, if Ada_Boolean'Size = 8
> > or 32 or something, then I can see where one might argue that
> > a value of -1 (all bits set) is out of range of the possible
> > Boolean values, and thus should raise
> > Constraint_Error.
> >
> > So what's right?
>
> Not only is the compiler's behavior conforming, it is actually
> what one would expect, given that you most certainly expect
> that boolean objects have a size of 8 (the choice of a size
> of 1 for boolean objects is typically impractical on most
> architectures due to the task indepedence requirement).
>
> Your code is just wrong here, and you are going to have to
> deal with these booleans in a completely different manner.
That's what I was afraid of.
> If your compiler implements Interfaces.Fortran, then everything
> should be fine, since the type Logical should work properly.
Except that sometimes the value comes from a Fortran program, and
sometimes it comes from a C program.
I just ended up doing the following, which looks damn silly (so I had
to comment it copiously), but works:
if To_Bool_Ptr(Addr).all then
return True;
else
return False;
end if;
--
T.E.D.
http://www.telepath.com/~dennison/Ted/TED.html
Sent via Deja.com http://www.deja.com/
Before you buy.
^ permalink raw reply [relevance 0%]
* Re: LLQ: -1 a valid boolean?
2000-05-23 0:00 0% ` Ted Dennison
2000-05-23 0:00 0% ` David C. Hoos, Sr.
@ 2000-05-23 0:00 0% ` Robert Dewar
1 sibling, 0 replies; 123+ results
From: Robert Dewar @ 2000-05-23 0:00 UTC (permalink / raw)
In article <8ge39b$g45$1@nnrp1.deja.com>,
Ted Dennison <dennison@telepath.com> wrote:
> > If your compiler implements Interfaces.Fortran, then
everything
> > should be fine, since the type Logical should work properly.
>
> Except that sometimes the value comes from a Fortran program,
and
> sometimes it comes from a C program.
That;s fine Fortran.Logical will work in either case
> I just ended up doing the following, which looks damn silly
> (so I had to comment it copiously), but works:
> if To_Bool_Ptr(Addr).all then
> return True;
> else
> return False;
> end if;
It's not only silly, it is incorrect. There is absolutely NO
reason to think this should work correctly, since you are
testing an out of range and hence abnormal value, and the
result of this test is undefined.
You should use unchecked conversion to convert it to an unsigned
integer of the approipriate size, and check that integer for
a non-zero value.
Writing erroneous code like this and being satisied that it
happens to work on the particular compiler you are using is
not a good approach to writing reliable code!
Sent via Deja.com http://www.deja.com/
Before you buy.
^ permalink raw reply [relevance 0%]
* Re: LLQ: -1 a valid boolean?
2000-05-23 0:00 0% ` Ted Dennison
@ 2000-05-23 0:00 0% ` David C. Hoos, Sr.
2000-05-23 0:00 0% ` Robert Dewar
1 sibling, 0 replies; 123+ results
From: David C. Hoos, Sr. @ 2000-05-23 0:00 UTC (permalink / raw)
return To_Bool_Ptr(Addr).all;
might look a little less "silly" than
if To_Bool_Ptr(Addr).all then
return True;
else
return False;
end if;
Ted Dennison <dennison@telepath.com> wrote in message
news:8ge39b$g45$1@nnrp1.deja.com...
> In article <8g8o3b$9l0$1@nnrp1.deja.com>,
> Robert Dewar <robert_dewar@my-deja.com> wrote:
> > In article <39253CD0.C8DC893D@telepath.com>,
> > Ted Dennison <dennison@telepath.com> wrote:
> > > You'd think that a value that is legal in situ ought to be
> > > legal to assign as well. Then again, if Ada_Boolean'Size = 8
> > > or 32 or something, then I can see where one might argue that
> > > a value of -1 (all bits set) is out of range of the possible
> > > Boolean values, and thus should raise
> > > Constraint_Error.
> > >
> > > So what's right?
> >
> > Not only is the compiler's behavior conforming, it is actually
> > what one would expect, given that you most certainly expect
> > that boolean objects have a size of 8 (the choice of a size
> > of 1 for boolean objects is typically impractical on most
> > architectures due to the task indepedence requirement).
> >
> > Your code is just wrong here, and you are going to have to
> > deal with these booleans in a completely different manner.
>
> That's what I was afraid of.
>
> > If your compiler implements Interfaces.Fortran, then everything
> > should be fine, since the type Logical should work properly.
>
> Except that sometimes the value comes from a Fortran program, and
> sometimes it comes from a C program.
>
> I just ended up doing the following, which looks damn silly (so I had
> to comment it copiously), but works:
>
> if To_Bool_Ptr(Addr).all then
> return True;
> else
> return False;
> end if;
>
> --
> T.E.D.
>
> http://www.telepath.com/~dennison/Ted/TED.html
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
^ permalink raw reply [relevance 0%]
* Re: LLQ: -1 a valid boolean?
2000-05-19 0:00 5% ` Jeff Carter
@ 2000-05-21 0:00 6% ` Robert Dewar
2000-05-23 0:00 0% ` Ted Dennison
1 sibling, 1 reply; 123+ results
From: Robert Dewar @ 2000-05-21 0:00 UTC (permalink / raw)
In article <39253CD0.C8DC893D@telepath.com>,
Ted Dennison <dennison@telepath.com> wrote:
> You'd think that a value that is legal in situ ought to be
> legal to assign as well. Then again, if Ada_Boolean'Size = 8
> or 32 or something, then I can see where one might argue that
> a value of -1 (all bits set) is out of range of the possible
> Boolean values, and thus should raise
> Constraint_Error.
>
> So what's right?
Not only is the compiler's behavior conforming, it is actually
what one would expect, given that you most certainly expect
that boolean objects have a size of 8 (the choice of a size
of 1 for boolean objects is typically impractical on most
architectures due to the task indepedence requirement).
Your code is just wrong here, and you are going to have to
deal with these booleans in a completely different manner.
If your compiler implements Interfaces.Fortran, then everything
should be fine, since the type Logical should work properly.
However, you may well find that even if your compiler says it
supports Interfaces.Fortran, it may get Logical wrong. That
was certainly the case with earlier versions of GNAT (a bad
gap in the ACVC tests is that there are no tests for proper
implementation of Logical, and the requirements are subtle).
The trouble is that Logical is derived from Boolean, but is
required to have completely different semantics from normal
Booleans, namely zero/nonzero semantics like C.
What we did in GNAT was implement a completely general facility
that allows derived booleans to be given a convention of C or
Fortran, and then they implement full zero/nonzero semantics.
This was definitely a non-trivial implementation effort, since
all sorts of special cases arise (we now for the first time have
a many-to-one mapping for the pos function for example).
So in GNAT, you can solve this problem by simply using pragma
Convention (Fortran, ...) but I don't think any other compilers
implement this feature in general terms. Whether any other
compilers properly implement Logical I don't know. Here's the
test we use for this purpose in our regression suite at Ada
Core Technologies:
with Interfaces.Fortran; use Interfaces.Fortran;
with Unchecked_Conversion;
with Text_IO; use Text_IO;
procedure q is
B : Boolean;
L : Logical;
I : Short_Short_Integer;
Passed : Boolean := True;
function To_L is new Unchecked_Conversion (Integer, Logical);
function From_B is new Unchecked_Conversion (Boolean,
Short_Short_Integer);
AL : array (1 .. 1) of Logical;
begin
goto Next;
<<Next>>
L := To_L (2);
AL (1) := L;
if Logical'Pos (L) /= 1 then
Put_Line ("wrong pos value for L");
Passed := False;
end if;
if L then
null;
else
Put_Line ("true value of L does not look true");
Passed := False;
end if;
if not L'Valid then
Put_Line ("L looks invalid");
Passed := False;
end if;
if (L > True or True < L) then
Put_Line ("complex condition handled incorrectly");
end if;
if (L > True or else True < L) then
Put_Line ("complex short circuit condition handled
incorrectly");
end if;
if Logical'Pos (AL (1)) /= 1 then
Put_Line ("wrong pos value for AL (1)");
Passed := False;
end if;
if AL (1) then
null;
else
Put_Line ("true value of AL (1) does not look true");
Passed := False;
end if;
if not AL (1)'Valid then
Put_Line ("AL (1) looks invalid");
Passed := False;
end if;
if (AL (1) > True or True < AL (1)) then
Put_Line ("complex condition handled incorrectly");
end if;
if (AL (1) > True or else True < AL (1)) then
Put_Line ("complex short circuit condition handled
incorrectly");
end if;
B := Boolean (L);
I := From_B (B);
if I /= 1 then
Put_Line ("wrong boolean value from conversion");
Passed := False;
end if;
if Passed then
Put_Line ("passed");
end if;
end q;
(well there are some other tests as well, but they are based
on customer proprietary code, so they cannot be posted. It was
a customer doing interfacing to Fortran who first brought this
to our attention).
Robert Dewar
Ada Core Technologies
P.S. This was implemented in GNAT version 3.12
Sent via Deja.com http://www.deja.com/
Before you buy.
^ permalink raw reply [relevance 6%]
* Re: LLQ: -1 a valid boolean?
2000-05-19 0:00 5% ` Jeff Carter
@ 2000-05-20 0:00 5% ` Ted Dennison
0 siblings, 0 replies; 123+ results
From: Ted Dennison @ 2000-05-20 0:00 UTC (permalink / raw)
Jeff Carter wrote:
> Ted Dennison wrote:
> > Fortran_True : Integer := -1;
>
> Shouldn't you be using Interfaces.Fortran.Logical? Which is guaranteed
> to be FORTRAN compatible?
No, because the boolean could have come from C or Fortran or Ada.
Interfaces.Fortran.Logical is not guaranteed to be C compatable.
--
T.E.D.
Home - mailto:dennison@telepath.com Work - mailto:dennison@ssd.fsi.com
WWW - http://www.telepath.com/dennison/Ted/TED.html ICQ - 10545591
^ permalink raw reply [relevance 5%]
* Re: LLQ: -1 a valid boolean?
@ 2000-05-19 0:00 5% ` Jeff Carter
2000-05-20 0:00 5% ` Ted Dennison
2000-05-21 0:00 6% ` Robert Dewar
1 sibling, 1 reply; 123+ results
From: Jeff Carter @ 2000-05-19 0:00 UTC (permalink / raw)
Ted Dennison wrote:
> Fortran_True : Integer := -1;
Shouldn't you be using Interfaces.Fortran.Logical? Which is guaranteed
to be FORTRAN compatible?
--
Jeff Carter
"Son of a silly person."
Monty Python & the Holy Grail
^ permalink raw reply [relevance 5%]
* Re: BLAS
2000-05-12 0:00 0% ` BLAS Duncan Sands
@ 2000-05-13 0:00 0% ` Larry Kilgallen
0 siblings, 0 replies; 123+ results
From: Larry Kilgallen @ 2000-05-13 0:00 UTC (permalink / raw)
In article <E12qHFV-00005Z-00@Baldrick>, Duncan Sands <sands@topo.math.u-psud.fr> writes:
> Gautier wrote:
>
>> Duncan wrote:
>>
>> > How important do you think it is to keep Ada 83 compatibility?
>>
>> Maybe because some Ada83 can be more efficient than their Ada 95
>> replacements. I did not install GNAT on OpenVMS to compare with the
>> DEC Ada I'm using, but the latter really rocks; I doubt GNAT can
>> be as good as DEC Ada. But globally an Ada95 solution using
>> Interfaces.Fortran is preferable. It would be also preferable
>> to have the best sort of Ada 95 for each platform with the in-house
>> code generator, with e.g. a Lahey Ada95, a DEC Ada 95, a Fujitsu
>> Ada 95, but -hum- it's rather a wish...
>>
>> In fact what is missing is an extensive comparison among
>> compilers on each platforms, including Ada and Fortran
>> compilers!
Unfortunately a published comparison would likely only be made
on the basis of performance or features. I heard the author
Mark Minasi speak last October about problems in the software
industry, and he pointed out that magazine comparisons with a
two-dimensional array showing features of competing products
was exactly what drove vendors to emphasize new features rather
than quality. There is a famous quote from Bill Gates saying
that new features are the only thing that sells new versions
of software (not better quality).
I realize that performance is one aspect of "quality",
but I think the more important one is "correctness".
I don't like the idea of Ada people being sucked into the
mainstream error of considering only that which is most
easily measured rather than that which is most important.
^ permalink raw reply [relevance 0%]
* Re: BLAS
@ 2000-05-12 0:00 6% ` Gautier
0 siblings, 0 replies; 123+ results
From: Gautier @ 2000-05-12 0:00 UTC (permalink / raw)
> How important do you think it is to keep Ada 83 compatibility?
[Short version:] not important!
More important would be to add to Ada83 still in activity
(DEC Ada: latest update 4/1999 or later) some name syntax for
Ada95 packages.
For DEC Ada:
"Ada.Numerics.Generic_Elementary_functions" would alias "Math_Lib"
and so on;
Interfaces would be added (some contents are already in System!)
as well as Interfaces.Fortran.
Would be a Ada 83.5, but very useful.
Another thing to do: compare compilers, Ada and Fortran,
on many platforms, to have an idea of the numerics-friendly
optimisations.
_____________________________________________
Gautier -- http://members.xoom.com/gdemont/
^ permalink raw reply [relevance 6%]
* BLAS
[not found] <391BC1F5.DFB47045@maths.unine.ch>
@ 2000-05-12 0:00 0% ` Duncan Sands
2000-05-13 0:00 0% ` BLAS Larry Kilgallen
0 siblings, 1 reply; 123+ results
From: Duncan Sands @ 2000-05-12 0:00 UTC (permalink / raw)
To: Gautier
Gautier wrote:
> Duncan wrote:
>
> > How important do you think it is to keep Ada 83 compatibility?
>
> Maybe because some Ada83 can be more efficient than their Ada 95
> replacements. I did not install GNAT on OpenVMS to compare with the
> DEC Ada I'm using, but the latter really rocks; I doubt GNAT can
> be as good as DEC Ada. But globally an Ada95 solution using
> Interfaces.Fortran is preferable. It would be also preferable
> to have the best sort of Ada 95 for each platform with the in-house
> code generator, with e.g. a Lahey Ada95, a DEC Ada 95, a Fujitsu
> Ada 95, but -hum- it's rather a wish...
>
> In fact what is missing is an extensive comparison among
> compilers on each platforms, including Ada and Fortran
> compilers!
While gcc (C version) does a good job on all platforms, it can certainly
be beaten by C compilers tailored for the platform. Since GNAT can't do
better than gcc, your remarks about DEC Ada aren't surprising; there must
be many other examples. It is true that a systematic compiler comparison
would be interesting.
> So, my answer is: not important!
>
> BTW I've pushed the remaining "DEC Ada" people at DEC to
> include some 95 extensions like
> "Ada.Numerics.Generic_elementary_functions = Math_lib"
> "Ada.Numerics.Elementary_functions = Float_math_lib"
> and so on. But they would push towards GNAT and are pushed towards
> the exit door... Anyway there is a bit of effort on that
> side (some improvements in the library, 95esque iirc).
I'm glad it's not important, because I plan to make the binding even
more Ada 95'ish, using child packages as follows:
Ada_Blas <- non generic package defining exceptions and other common stuff
Ada_Blas.Real <- real blas
Ada_Blas.Complex <- complex blas
By the way, I'm in two minds as to whether the Matrix and Vector types
should be defined in the package or passed as generic parameters. It
would be nice to be able to pass them in. The problem with generic
parameters is that I don't see how to pass in an array type of Float_Type'Base:
generic
type Float_Type is digits <>;
type Matrix is array (Integer range <>, Integer range <>) of Float_Type'Base;
is rejected by GNAT. I would like to do
generic
type Float_Type is digits <>;
type Base_Type is new Float_Type'Base;
type Matrix is array (Integer range <>, Integer range <>) of Base_Type;
but there are two problems with this:
(1) GNAT seems to have a bug in this area.
(2) Base_Type could have a range restriction. Eg if I defined
type Base is new Float_Type'Base range 0.0 .. 1.0;
then this is fine for passing as the Base_Type parameter. The
problem is that the Fortran procedures aren't going to respect the
range constraints, so after performing operations you may obtain
vectors/matrices with invalid components. You could then check
(with the 'Valid attribute) if all components are ok, but this
would introduce heavy overheads. Not checking is not in keeping
with the Ada philosophy! By the way, I want Float_Type'Base because
it has no range constraints (cf Ada.Numerics.Generic_Elementary_Functions).
Any thoughts?
Duncan.
^ permalink raw reply [relevance 0%]
* BLAS binding
@ 2000-05-11 0:00 5% Duncan Sands
0 siblings, 0 replies; 123+ results
From: Duncan Sands @ 2000-05-11 0:00 UTC (permalink / raw)
I'm interested in doing a medium-thin binding to the BLAS
(Basic Linear Algebra Subprograms) and to some of LAPACK.
I've written a (preliminary) binding to the level 1 BLAS
to show the kind of thing I have in mind (see below or
http://topo.math.u-psud.fr/~sands/BLAS/ ): you just
instantiate it with your favorite floating point type
and it automagically calls the BLAS routines of the
appropriate precision. I added checking of array bounds
(easy in Ada) and exploited overloading to give simplified
forms of the procedures.
Please let me know if you have any comments. Help is
welcome!
Duncan Sands.
with Interfaces.Fortran;
generic
type Float_Type is digits <>;
package Real_BLAS is
pragma Elaborate_Body (Real_BLAS);
type Precision is (Double, Single, Unsupported);
BLAS_Precision : constant Precision;
Argument_Error : exception;
Unsupported_Precision_Error : exception;
type Vector is array (Integer range <>) of Float_Type'Base;
pragma Convention (Fortran, Vector);
type Matrix is array (Integer range <>, Integer range <>)
of Float_Type'Base;
pragma Convention (Fortran, Matrix);
-- Level 1
-- ROTG: Generate plane rotation
procedure ROTG (
A, B : in out Float_Type'Base;
C, S : out Float_Type'Base
);
pragma Inline (ROTG);
type Modified_Givens is new Vector (1 .. 5);
-- ROTMG: Generate modified plane rotation
procedure ROTMG (
D1, D2 : in out Float_Type'Base;
A : in out Float_Type'Base;
B : in Float_Type'Base;
PARAM : out Modified_Givens
);
pragma Inline (ROTMG);
-- ROT: Apply plane rotation
procedure ROT (
N : in Natural;
X : in out Vector;
INCX : in Integer;
Y : in out Vector;
INCY : in Integer;
C, S : in Float_Type'Base
);
procedure ROT (
X, Y : in out Vector;
C, S : in Float_Type'Base
);
pragma Inline (ROT);
-- ROTM: Apply modified plane rotation
procedure ROTM (
N : in Natural;
X : in out Vector;
INCX : in Integer;
Y : in out Vector;
INCY : in Integer;
PARAM : in Modified_Givens
);
procedure ROTM (
X, Y : in out Vector;
PARAM : in Modified_Givens
);
pragma Inline (ROTM);
-- SWAP: x <-> y
procedure SWAP (
N : in Natural;
X : in out Vector;
INCX : in Integer;
Y : in out Vector;
INCY : in Integer
);
procedure SWAP (X, Y : in out Vector);
pragma Inline (SWAP);
-- SCAL: x <- alpha x
procedure SCAL (
N : in Natural;
ALPHA : in Float_Type'Base;
X : in out Vector;
INCX : in Integer
);
procedure SCAL (
ALPHA : in Float_Type'Base;
X : in out Vector
);
pragma Inline (SCAL);
-- COPY: y <- x
procedure COPY (
N : in Natural;
X : in Vector;
INCX : in Integer;
Y : in out Vector;
INCY : in Integer
);
procedure COPY (
X : in Vector;
Y : in out Vector
);
pragma Inline (COPY);
-- AXPY: y <- alpha x + y
procedure AXPY (
N : in Natural;
ALPHA : in Float_Type'Base;
X : in Vector;
INCX : in Integer;
Y : in out Vector;
INCY : in Integer
);
procedure AXPY (
ALPHA : in Float_Type'Base;
X : in Vector;
Y : in out Vector
);
pragma Inline (AXPY);
-- DOT: dot <- x^T y
function DOT (
N : Natural;
X : Vector;
INCX : Integer;
Y : Vector;
INCY : Integer
) return Float_Type'Base;
function DOT (X, Y : Vector) return Float_Type'Base;
pragma Inline (DOT);
-- DSDOT: dot <- alpha + x^T y (double precision accumulation)
function DSDOT (
N : Natural;
ALPHA : Float_Type'Base;
X : Vector;
INCX : Integer;
Y : Vector;
INCY : Integer
) return Float_Type'Base;
function DSDOT (
ALPHA : Float_Type'Base;
X, Y : Vector
) return Float_Type'Base;
pragma Inline (DSDOT);
-- NRM2: nrm2 <- ||x||_2
function NRM2 (
N : Natural;
X : Vector;
INCX : Integer
) return Float_Type'Base;
function NRM2 (X : Vector) return Float_Type'Base;
pragma Inline (NRM2);
-- ASUM: asum <- ||x||_1
function ASUM (
N : Natural;
X : Vector;
INCX : Integer
) return Float_Type'Base;
function ASUM (X : Vector) return Float_Type'Base;
pragma Inline (ASUM);
-- AMAX: amax <- 1st k such that |x_k| = max(|x_i|)
function AMAX (
N : Natural;
X : Vector;
INCX : Integer
) return Integer;
function AMAX (X : Vector) return Integer;
pragma Inline (AMAX);
private
-- Strings that will be appended/prepended to each BLAS subroutine name
-- to form the external name used when importing it
Name_Prepend : constant String := "";
Name_Append : constant String := "_";
BLAS_Precision : constant Precision := Precision'Val (
Precision'Pos (Unsupported) -
(
Boolean'Pos (
Float_Type'Base'Digits = Interfaces.Fortran.Real'Digits and
Float_Type'Base'Size = Interfaces.Fortran.Real'Size
) - Boolean'Pos (False)
) - 2 *
(
Boolean'Pos (
Float_Type'Base'Digits = Interfaces.Fortran.Double_Precision'Digits
and Float_Type'Base'Size =
Interfaces.Fortran.Double_Precision'Size
) - Boolean'Pos (False)
)
);
-- Used this method to encourage compile time evaluation
-- Will raise Constraint_Error if Double and Single precision are the same
end Real_BLAS;
package body Real_BLAS is
use Interfaces.Fortran;
----------
-- AMAX --
----------
function ISAMAX (
N : Fortran_Integer;
X : Vector;
INCX : Fortran_Integer
) return Fortran_Integer;
pragma Import (Fortran, ISAMAX, Name_Prepend & "isamax" & Name_Append);
function IDAMAX (
N : Fortran_Integer;
X : Vector;
INCX : Fortran_Integer
) return Fortran_Integer;
pragma Import (Fortran, IDAMAX, Name_Prepend & "idamax" & Name_Append);
function AMAX (
N : Natural;
X : Vector;
INCX : Integer
) return Integer is
begin
-- Use of INCX rather than abs INCX is deliberate
if N > 0 and (N - 1) * INCX >= X'Length then
raise Argument_Error;
end if;
case BLAS_Precision is
when Single =>
return X'First - 1 + Integer (
ISAMAX (Fortran_Integer (N), X, Fortran_Integer (INCX))
);
when Double =>
return X'First - 1 + Integer (
IDAMAX (Fortran_Integer (N), X, Fortran_Integer (INCX))
);
when Unsupported =>
raise Unsupported_Precision_Error;
end case;
end AMAX;
function AMAX (X : Vector) return Integer is
begin
case BLAS_Precision is
when Single =>
return X'First - 1 + Integer (
ISAMAX (X'Length, X, 1)
);
when Double =>
return X'First - 1 + Integer (
IDAMAX (X'Length, X, 1)
);
when Unsupported =>
raise Unsupported_Precision_Error;
end case;
end AMAX;
----------
-- ASUM --
----------
function SASUM (
N : Fortran_Integer;
X : Vector;
INCX : Fortran_Integer
) return Float_Type'Base;
pragma Import (Fortran, SASUM, Name_Prepend & "sasum" & Name_Append);
function DASUM (
N : Fortran_Integer;
X : Vector;
INCX : Fortran_Integer
) return Float_Type'Base;
pragma Import (Fortran, DASUM, Name_Prepend & "dasum" & Name_Append);
function ASUM (
N : Natural;
X : Vector;
INCX : Integer
) return Float_Type'Base is
begin
-- Use of INCX rather than abs INCX is deliberate
if N > 0 and (N - 1) * INCX >= X'Length then
raise Argument_Error;
end if;
case BLAS_Precision is
when Single =>
return SASUM (Fortran_Integer (N), X, Fortran_Integer (INCX));
when Double =>
return DASUM (Fortran_Integer (N), X, Fortran_Integer (INCX));
when Unsupported =>
raise Unsupported_Precision_Error;
end case;
end ASUM;
function ASUM (X : Vector) return Float_Type'Base is
begin
case BLAS_Precision is
when Single =>
return SASUM (X'Length, X, 1);
when Double =>
return DASUM (X'Length, X, 1);
when Unsupported =>
raise Unsupported_Precision_Error;
end case;
end ASUM;
----------
-- AXPY --
----------
procedure SAXPY (
N : in Fortran_Integer;
ALPHA : in Float_Type'Base;
X : in Vector;
INCX : in Fortran_Integer;
Y : in out Vector;
INCY : in Fortran_Integer
);
pragma Import (Fortran, SAXPY, Name_Prepend & "saxpy" & Name_Append);
procedure DAXPY (
N : in Fortran_Integer;
ALPHA : in Float_Type'Base;
X : in Vector;
INCX : in Fortran_Integer;
Y : in out Vector;
INCY : in Fortran_Integer
);
pragma Import (Fortran, DAXPY, Name_Prepend & "daxpy" & Name_Append);
procedure AXPY (
N : in Natural;
ALPHA : in Float_Type'Base;
X : in Vector;
INCX : in Integer;
Y : in out Vector;
INCY : in Integer
) is
begin
if N > 0 and (
(N - 1) * abs INCX >= X'Length or (N - 1) * abs INCY >= Y'Length
) then
raise Argument_Error;
end if;
case BLAS_Precision is
when Single =>
SAXPY (
Fortran_Integer (N),
ALPHA,
X,
Fortran_Integer (INCX),
Y,
Fortran_Integer (INCY)
);
when Double =>
DAXPY (
Fortran_Integer (N),
ALPHA,
X,
Fortran_Integer (INCX),
Y,
Fortran_Integer (INCY)
);
when Unsupported =>
raise Unsupported_Precision_Error;
end case;
end AXPY;
procedure AXPY (
ALPHA : in Float_Type'Base;
X : in Vector;
Y : in out Vector
) is
begin
if X'Length /= Y'Length then
raise Argument_Error;
end if;
case BLAS_Precision is
when Single =>
SAXPY (X'Length, ALPHA, X, 1, Y, 1);
when Double =>
DAXPY (X'Length, ALPHA, X, 1, Y, 1);
when Unsupported =>
raise Unsupported_Precision_Error;
end case;
end AXPY;
----------
-- COPY --
----------
procedure SCOPY (
N : in Fortran_Integer;
X : in Vector;
INCX : in Fortran_Integer;
Y : in out Vector;
INCY : in Fortran_Integer
);
pragma Import (Fortran, SCOPY, Name_Prepend & "scopy" & Name_Append);
procedure DCOPY (
N : in Fortran_Integer;
X : in Vector;
INCX : in Fortran_Integer;
Y : in out Vector;
INCY : in Fortran_Integer
);
pragma Import (Fortran, DCOPY, Name_Prepend & "dcopy" & Name_Append);
procedure COPY (
N : in Natural;
X : in Vector;
INCX : in Integer;
Y : in out Vector;
INCY : in Integer
) is
begin
if N > 0 and (
(N - 1) * abs INCX >= X'Length or (N - 1) * abs INCY >= Y'Length
) then
raise Argument_Error;
end if;
case BLAS_Precision is
when Single =>
SCOPY (
Fortran_Integer (N),
X,
Fortran_Integer (INCX),
Y,
Fortran_Integer (INCY)
);
when Double =>
DCOPY (
Fortran_Integer (N),
X,
Fortran_Integer (INCX),
Y,
Fortran_Integer (INCY)
);
when Unsupported =>
raise Unsupported_Precision_Error;
end case;
end COPY;
procedure COPY (
X : in Vector;
Y : in out Vector
) is
begin
if X'Length /= Y'Length then
raise Argument_Error;
end if;
case BLAS_Precision is
when Single =>
SCOPY (X'Length, X, 1, Y, 1);
when Double =>
DCOPY (X'Length, X, 1, Y, 1);
when Unsupported =>
raise Unsupported_Precision_Error;
end case;
end COPY;
---------
-- DOT --
---------
function SDOT (
N : Fortran_Integer;
X : Vector;
INCX : Fortran_Integer;
Y : Vector;
INCY : Fortran_Integer
) return Float_Type'Base;
pragma Import (Fortran, SDOT, Name_Prepend & "sdot" & Name_Append);
function DDOT (
N : Fortran_Integer;
X : Vector;
INCX : Fortran_Integer;
Y : Vector;
INCY : Fortran_Integer
) return Float_Type'Base;
pragma Import (Fortran, DDOT, Name_Prepend & "ddot" & Name_Append);
function DOT (
N : Natural;
X : Vector;
INCX : Integer;
Y : Vector;
INCY : Integer
) return Float_Type'Base is
begin
if N > 0 and (
(N - 1) * abs INCX >= X'Length or (N - 1) * abs INCY >= Y'Length
) then
raise Argument_Error;
end if;
case BLAS_Precision is
when Single =>
return SDOT (
Fortran_Integer (N),
X,
Fortran_Integer (INCX),
Y,
Fortran_Integer (INCY)
);
when Double =>
return DDOT (
Fortran_Integer (N),
X,
Fortran_Integer (INCX),
Y,
Fortran_Integer (INCY)
);
when Unsupported =>
raise Unsupported_Precision_Error;
end case;
end DOT;
function DOT (X, Y : Vector) return Float_Type'Base is
begin
if X'Length /= Y'Length then
raise Argument_Error;
end if;
case BLAS_Precision is
when Single =>
return SDOT (X'Length, X, 1, Y, 1);
when Double =>
return DDOT (X'Length, X, 1, Y, 1);
when Unsupported =>
raise Unsupported_Precision_Error;
end case;
end DOT;
-----------
-- DSDOT --
-----------
function SDSDOT (
N : Fortran_Integer;
ALPHA : Float_Type'Base;
X : Vector;
INCX : Fortran_Integer;
Y : Vector;
INCY : Fortran_Integer
) return Float_Type'Base;
pragma Import (Fortran, SDSDOT, Name_Prepend & "sdsdot" & Name_Append);
function DSDOT (
N : Natural;
ALPHA : Float_Type'Base;
X : Vector;
INCX : Integer;
Y : Vector;
INCY : Integer
) return Float_Type'Base is
begin
if N > 0 and (
(N - 1) * abs INCX >= X'Length or (N - 1) * abs INCY >= Y'Length
) then
raise Argument_Error;
end if;
case BLAS_Precision is
when Single =>
return SDSDOT (
Fortran_Integer (N),
ALPHA,
X,
Fortran_Integer (INCX),
Y,
Fortran_Integer (INCY)
);
when Double =>
return ALPHA + DDOT (
Fortran_Integer (N),
X,
Fortran_Integer (INCX),
Y,
Fortran_Integer (INCY)
);
when Unsupported =>
raise Unsupported_Precision_Error;
end case;
end DSDOT;
function DSDOT (
ALPHA : Float_Type'Base;
X, Y : Vector
) return Float_Type'Base is
begin
if X'Length /= Y'Length then
raise Argument_Error;
end if;
case BLAS_Precision is
when Single =>
return SDSDOT (X'Length, ALPHA, X, 1, Y, 1);
when Double =>
return ALPHA + DDOT (X'Length, X, 1, Y, 1);
when Unsupported =>
raise Unsupported_Precision_Error;
end case;
end DSDOT;
----------
-- NRM2 --
----------
function SNRM2 (
N : Fortran_Integer;
X : Vector;
INCX : Fortran_Integer
) return Float_Type'Base;
pragma Import (Fortran, SNRM2, Name_Prepend & "snrm2" & Name_Append);
function DNRM2 (
N : Fortran_Integer;
X : Vector;
INCX : Fortran_Integer
) return Float_Type'Base;
pragma Import (Fortran, DNRM2, Name_Prepend & "dnrm2" & Name_Append);
function NRM2 (
N : Natural;
X : Vector;
INCX : Integer
) return Float_Type'Base is
begin
-- Use of INCX rather than abs INCX is deliberate
if N > 0 and (N - 1) * INCX >= X'Length then
raise Argument_Error;
end if;
case BLAS_Precision is
when Single =>
return SNRM2 (Fortran_Integer (N), X, Fortran_Integer (INCX));
when Double =>
return DNRM2 (Fortran_Integer (N), X, Fortran_Integer (INCX));
when Unsupported =>
raise Unsupported_Precision_Error;
end case;
end NRM2;
function NRM2 (X : Vector) return Float_Type'Base is
begin
case BLAS_Precision is
when Single =>
return SNRM2 (X'Length, X, 1);
when Double =>
return DNRM2 (X'Length, X, 1);
when Unsupported =>
raise Unsupported_Precision_Error;
end case;
end NRM2;
---------
-- ROT --
---------
procedure SROT (
N : in Fortran_Integer;
X : in out Vector;
INCX : in Fortran_Integer;
Y : in out Vector;
INCY : in Fortran_Integer;
C, S : in Float_Type'Base
);
pragma Import (Fortran, SROT, Name_Prepend & "srot" & Name_Append);
procedure DROT (
N : in Fortran_Integer;
X : in out Vector;
INCX : in Fortran_Integer;
Y : in out Vector;
INCY : in Fortran_Integer;
C, S : in Float_Type'Base
);
pragma Import (Fortran, DROT, Name_Prepend & "drot" & Name_Append);
procedure ROT (
N : in Natural;
X : in out Vector;
INCX : in Integer;
Y : in out Vector;
INCY : in Integer;
C, S : in Float_Type'Base
) is
begin
if N > 0 and (
(N - 1) * abs INCX >= X'Length or (N - 1) * abs INCY >= Y'Length
) then
raise Argument_Error;
end if;
case BLAS_Precision is
when Single =>
SROT (
Fortran_Integer (N),
X,
Fortran_Integer (INCX),
Y,
Fortran_Integer (INCY),
C, S
);
when Double =>
DROT (
Fortran_Integer (N),
X,
Fortran_Integer (INCX),
Y,
Fortran_Integer (INCY),
C, S
);
when Unsupported =>
raise Unsupported_Precision_Error;
end case;
end ROT;
procedure ROT (
X, Y : in out Vector;
C, S : in Float_Type'Base
) is
begin
if X'Length /= Y'Length then
raise Argument_Error;
end if;
case BLAS_Precision is
when Single =>
SROT (X'Length, X, 1, Y, 1, C, S);
when Double =>
DROT (X'Length, X, 1, Y, 1, C, S);
when Unsupported =>
raise Unsupported_Precision_Error;
end case;
end ROT;
----------
-- ROTM --
----------
procedure SROTM (
N : in Fortran_Integer;
X : in out Vector;
INCX : in Fortran_Integer;
Y : in out Vector;
INCY : in Fortran_Integer;
PARAM : in Modified_Givens
);
pragma Import (Fortran, SROTM, Name_Prepend & "srotm" & Name_Append);
procedure DROTM (
N : in Fortran_Integer;
X : in out Vector;
INCX : in Fortran_Integer;
Y : in out Vector;
INCY : in Fortran_Integer;
PARAM : in Modified_Givens
);
pragma Import (Fortran, DROTM, Name_Prepend & "drotm" & Name_Append);
procedure ROTM (
N : in Natural;
X : in out Vector;
INCX : in Integer;
Y : in out Vector;
INCY : in Integer;
PARAM : in Modified_Givens
) is
begin
if N > 0 and (
(N - 1) * abs INCX >= X'Length or (N - 1) * abs INCY >= Y'Length
) then
raise Argument_Error;
end if;
case BLAS_Precision is
when Single =>
SROTM (
Fortran_Integer (N),
X,
Fortran_Integer (INCX),
Y,
Fortran_Integer (INCY),
PARAM
);
when Double =>
DROTM (
Fortran_Integer (N),
X,
Fortran_Integer (INCX),
Y,
Fortran_Integer (INCY),
PARAM
);
when Unsupported =>
raise Unsupported_Precision_Error;
end case;
end ROTM;
procedure ROTM (
X, Y : in out Vector;
PARAM : in Modified_Givens
) is
begin
if X'Length /= Y'Length then
raise Argument_Error;
end if;
case BLAS_Precision is
when Single =>
SROTM (X'Length, X, 1, Y, 1, PARAM);
when Double =>
DROTM (X'Length, X, 1, Y, 1, PARAM);
when Unsupported =>
raise Unsupported_Precision_Error;
end case;
end ROTM;
----------
-- ROTG --
----------
procedure SROTG (
A, B : in out Float_Type'Base;
C, S : out Float_Type'Base
);
pragma Import (Fortran, SROTG, Name_Prepend & "srotg" & Name_Append);
procedure DROTG (
A, B : in out Float_Type'Base;
C, S : out Float_Type'Base
);
pragma Import (Fortran, DROTG, Name_Prepend & "drotg" & Name_Append);
procedure ROTG (
A, B : in out Float_Type'Base;
C, S : out Float_Type'Base
) is
begin
case BLAS_Precision is
when Single =>
SROTG (A, B, C, S);
when Double =>
DROTG (A, B, C, S);
when Unsupported =>
raise Unsupported_Precision_Error;
end case;
end ROTG;
-----------
-- ROTMG --
-----------
procedure SROTMG (
D1, D2 : in out Float_Type'Base;
A : in out Float_Type'Base;
B : in Float_Type'Base;
PARAM : out Modified_Givens
);
pragma Import (Fortran, SROTMG, Name_Prepend & "srotmg" & Name_Append);
procedure DROTMG (
D1, D2 : in out Float_Type'Base;
A : in out Float_Type'Base;
B : in Float_Type'Base;
PARAM : out Modified_Givens
);
pragma Import (Fortran, DROTMG, Name_Prepend & "drotmg" & Name_Append);
procedure ROTMG (
D1, D2 : in out Float_Type'Base;
A : in out Float_Type'Base;
B : in Float_Type'Base;
PARAM : out Modified_Givens
) is
begin
case BLAS_Precision is
when Single =>
SROTMG (D1, D2, A, B, PARAM);
when Double =>
DROTMG (D1, D2, A, B, PARAM);
when Unsupported =>
raise Unsupported_Precision_Error;
end case;
end ROTMG;
----------
-- SCAL --
----------
procedure SSCAL (
N : in Fortran_Integer;
ALPHA : in Float_Type'Base;
X : in out Vector;
INCX : in Fortran_Integer
);
pragma Import (Fortran, SSCAL, Name_Prepend & "sscal" & Name_Append);
procedure DSCAL (
N : in Fortran_Integer;
ALPHA : in Float_Type'Base;
X : in out Vector;
INCX : in Fortran_Integer
);
pragma Import (Fortran, DSCAL, Name_Prepend & "dscal" & Name_Append);
procedure SCAL (
N : in Natural;
ALPHA : in Float_Type'Base;
X : in out Vector;
INCX : in Integer
) is
begin
-- Use of INCX rather than abs INCX is deliberate
if N > 0 and (N - 1) * INCX >= X'Length then
raise Argument_Error;
end if;
case BLAS_Precision is
when Single =>
SSCAL (Fortran_Integer (N), ALPHA, X, Fortran_Integer (INCX));
when Double =>
DSCAL (Fortran_Integer (N), ALPHA, X, Fortran_Integer (INCX));
when Unsupported =>
raise Unsupported_Precision_Error;
end case;
end SCAL;
procedure SCAL (
ALPHA : in Float_Type'Base;
X : in out Vector
) is
begin
case BLAS_Precision is
when Single =>
SSCAL (X'Length, ALPHA, X, 1);
when Double =>
DSCAL (X'Length, ALPHA, X, 1);
when Unsupported =>
raise Unsupported_Precision_Error;
end case;
end SCAL;
----------
-- SWAP --
----------
procedure SSWAP (
N : in Fortran_Integer;
X : in out Vector;
INCX : in Fortran_Integer;
Y : in out Vector;
INCY : in Fortran_Integer
);
pragma Import (Fortran, SSWAP, Name_Prepend & "sswap" & Name_Append);
procedure DSWAP (
N : in Fortran_Integer;
X : in out Vector;
INCX : in Fortran_Integer;
Y : in out Vector;
INCY : in Fortran_Integer
);
pragma Import (Fortran, DSWAP, Name_Prepend & "dswap" & Name_Append);
procedure SWAP (
N : in Natural;
X : in out Vector;
INCX : in Integer;
Y : in out Vector;
INCY : in Integer
) is
begin
if N > 0 and (
(N - 1) * abs INCX >= X'Length or (N - 1) * abs INCY >= Y'Length
) then
raise Argument_Error;
end if;
case BLAS_Precision is
when Single =>
SSWAP (
Fortran_Integer (N),
X,
Fortran_Integer (INCX),
Y,
Fortran_Integer (INCY)
);
when Double =>
DSWAP (
Fortran_Integer (N),
X,
Fortran_Integer (INCX),
Y,
Fortran_Integer (INCY)
);
when Unsupported =>
raise Unsupported_Precision_Error;
end case;
end SWAP;
procedure SWAP (X, Y : in out Vector) is
begin
if X'Length /= Y'Length then
raise Argument_Error;
end if;
case BLAS_Precision is
when Single =>
SSWAP (X'Length, X, 1, Y, 1);
when Double =>
DSWAP (X'Length, X, 1, Y, 1);
when Unsupported =>
raise Unsupported_Precision_Error;
end case;
end SWAP;
end Real_BLAS;
^ permalink raw reply [relevance 5%]
* Re: Calling Ada in Fortran program
@ 2000-01-27 0:00 5% ` Stephen Leake
0 siblings, 0 replies; 123+ results
From: Stephen Leake @ 2000-01-27 0:00 UTC (permalink / raw)
"sylvie.gore" <sylvie.gore@libertysurf.fr> writes:
> I am looking for any information about calling Ada procedures from a
> Fortran program; is it necessary to use some C intermediate functions ?
> Have you already done it with a specific environment ? what are the
> constraints (compilers, code rules ...) ?
The Ada standard defines the package Interfaces.Fortran. Find out if
the compilers you are interested in support this package. Or, make it
a requirement!
-- Stephe
^ permalink raw reply [relevance 5%]
* Re: help on interfacing with fortran
2000-01-16 0:00 5% help on interfacing with fortran Paolo M. Pumilia
@ 2000-01-16 0:00 7% ` Gisle S�lensminde
0 siblings, 0 replies; 123+ results
From: Gisle S�lensminde @ 2000-01-16 0:00 UTC (permalink / raw)
In article <38818E32.FD90616B@cstc.org>, Paolo M. Pumilia wrote:
>
>I would like to interface a set of fortran soubroutines and functions
>to main Ada procedure.
>Here are enclosed three functions and a subroutine which i am working
>on, at present. They are all stored in a single file, that i used to
>compile and link to its fortran main code.
>
>The Ada procedure makes one call to the subroutine start_carry(idum),
>getting an integer number (idum) in return
>
>Then the function rnor(idum) will be called, returnig a real*8 random
>number.
>
>How to perform such calls?
>
>I took a look at tha ARM, but its contents appears rather cryptic to me.
>I have been reading a few introductive manuals (Lovelace, Dodrill-tutor,
>etc) but they don't cover this topic very well.
>Interfacing is completely new in my experience. Could those four fortran
>codes be kept within a single file or should they be included into an
>Ada package or procedure?
>A procedure for each function or subroutine should be prepared? How do
>calls between fortran functions (not involving Ada code) will be
>performed?
Here is a pice of code that do what you tried to do. Since it seems
that you have some problem with the Ada syntax in general, I have
tried to make some hopefully useful comments in the code. The code
seemed to work on SGI IRIX 6.5 with gnat 3.11b and g77. The code was
compiled with:
g77 -c -fno-second-underscore rnor.f
gnatmake ada_main.adb -largs rnor.o
with Interfaces.Fortran;
use Interfaces.Fortran;
procedure Ada_Main is
package Fortran renames Interfaces.Fortran;
-- I use the "Fortran types" decleard in interfaces.fortran,
-- which match the types used by the fortran compiler.
dummy : Fortran.Fortran_Integer;
-- This is how external fortran subroutines is declared.
-- Fist a specification, followed by a pragma import.
procedure start_carry (dummy : in out Fortran.Fortran_Integer);
pragma Import (Fortran, Start_Carry,"start_carry_");
-- Unlike Fortran, functions in Ada do not allow
-- out parameters in functions.
function rnor(dum : in Fortran.Fortran_Integer) return Fortran.Real;
-- The pragma imports use the optional third parameter that
-- specifies the link name. Somtimes this is neccesary, since
-- different compilers on a single platform may give functions
-- and subroutines different link names, by inserting underscores.
pragma Import (Fortran, Rnor, "rnor_");
A : Fortran.Real;
begin
-- And here comes the calls
start_carry(dummy);
a := rnor(dummy);
end Ada_Main ;
>Here is my guess applied to Ada_Main procedure:
- Gisle S�lensminde (gisle@ii.uib.no)
^ permalink raw reply [relevance 7%]
* help on interfacing with fortran
@ 2000-01-16 0:00 5% Paolo M. Pumilia
2000-01-16 0:00 7% ` Gisle S�lensminde
0 siblings, 1 reply; 123+ results
From: Paolo M. Pumilia @ 2000-01-16 0:00 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 1714 bytes --]
I would like to interface a set of fortran soubroutines and functions
to main Ada procedure.
Here are enclosed three functions and a subroutine which i am working
on, at present. They are all stored in a single file, that i used to
compile and link to its fortran main code.
The Ada procedure makes one call to the subroutine start_carry(idum),
getting an integer number (idum) in return
Then the function rnor(idum) will be called, returnig a real*8 random
number.
How to perform such calls?
I took a look at tha ARM, but its contents appears rather cryptic to me.
I have been reading a few introductive manuals (Lovelace, Dodrill-tutor,
etc)
but they don't cover this topic very well.
Interfacing is completely new in my experience. Could those four fortran
codes be kept within a single file or should they be included into an
Ada package or procedure?
A procedure for each function or subroutine should be prepared? How do
calls
between fortran functions (not involving Ada code) will be performed?
Here is my guess applied to Ada_Main procedure:
with Interfaces.Fortran;
use Interfaces.Fortran;
procedure Ada_Main;
dummy : integer
function rnor(dum : integer) : return float;
pragma Convention (Fortran, dummy);
pragma Convention (Fortran, dum);
procedure start_carry (dummy : in out integer) is
pragma Import (Fortran, start_carry);
... fortran code ? .......
function rnor(dum : integer) : return float is
pragma Import (Fortran, rnor);
... fortran code ? .......
begin Ada_Main
....
start_carry(dummy);
a := rnor(dum); -- supposing a is a float variable
....
end Ada_Main ;
Any suggestions and examples are welcome
thank you for your help
Paolo Pumilia
[-- Attachment #2: rnor.f --]
[-- Type: text/plain, Size: 2619 bytes --]
subroutine start_carry(idum)
idum=-10231
do iloop=1,1000
j=icarry(idum)
enddo
return
end
function icarry(idum)
implicit real*8(a-h,q-z)
parameter (ib=2**24,b=1.d0/ib)
integer*4 xn(-29:30)
if(idum.le.0)then
if(idum.eq.0)idum=13
do i=1,30
xn(i)=mod(iabs(idum)*i,37)
xn(i-30)=xn(i)
enddo
ic=0
idum=30
endif
i1=idum-24
i2=idum-10
idn=xn(i2)-xn(i1)-ic
if(idn.lt.0)then
idn=idn+ib
ic=1
else
ic=0
endif
idum=idum+1
if(idum.gt.30)idum=1
xn(idum)=idn
xn(idum-30)=idn
icarry=idn
return
end
function rcarry(idum)
implicit real*8(a-h,q-z)
parameter (ib=2**24,b=1.d0/ib)
rcarry=b*icarry(idum)
return
end
C
C MARSAGLIA,G. & TSANG,W.W. ,SIAM J.SCIE. & STAT.COMP.,5,349(1984)
C
FUNCTION RNOR(SEED)
IMPLICIT REAL*8(A-H,M,Q-Z)
! pol 29.jun.1997 ?? real*8 pc
INTEGER*4 SEED
parameter (i23=2**23,rmax=1.d0/i23)
DIMENSION V(65)
DATA V /.3409450d0,.4573146d0,.5397792d0,.6062427d0,.6631690d0,
1.7136974d0,.7596124d0,.8020356d0,.8417227d0,.8792102d0,.9148948d0,
2.9490791d0,.9820005d0,1.013848d0,1.044780d0,1.074924d0,1.104391d0,
31.133273d0,1.161653d0,1.189601d0,1.217181d0,1.244452d0,1.271463d0,
41.298265d0,1.324901d0,1.351412d0,1.377839d0,1.404221d0,1.430593d0,
51.456991d0,1.483452d0,1.510012d0,1.536706d0,1.563571d0,1.590645d0,
61.617968d0,1.645579d0,1.673525d0,1.701850d0,1.730604d0,1.759842d0,
71.789622d0,1.820009d0,1.851076d0,1.882904d0,1.915583d0,1.949216d0,
81.983924d0,2.019842d0,2.057135d0,2.095992d0,2.136644d0,2.179371d0,
92.224517d0,2.272518d0,2.323934d0,2.379500d0,2.440222d0,2.507511d0,
+2.583466d0,2.671391d0,2.776994d0,2.776994d0,2.776994d0,2.776994d0/
DATA AA,B,C/12.37586d0,.4878992d0,12.67706d0/
1 C1,C2,PC,XN/.9689279d0,1.301198d0,.1958303d-1,2.776994d0/
I=icarry(seed)-i23
J=MOD(IABS(I),64)+1
RNOR=I*RMAX*V(J+1)
IF(DABS(RNOR).LE.V(J))RETURN
C
X=(DABS(RNOR)-V(J))/(V(J+1)-V(J))
Y=rcarry(seed)
S=X+Y
IF(S.GT.C2)GOTO 11
IF(S.LE.C1)RETURN
IF(Y.GT.C-AA*DEXP(-.5D0*(B-B*X)**2))GOTO 11
IF(DEXP(-.5D0*V(J+1)**2)+Y*PC/V(J+1).LE.DEXP(-.5D0*RNOR**2))RETURN
C
22 X=.3601016D0*DLOG(rcarry(seed))
IF(-2.D0*DLOG(rcarry(seed)).LE.X**2)GOTO 22
RNOR=DSIGN(XN-X,RNOR)
RETURN
11 RNOR=DSIGN(B-B*X,RNOR)
RETURN
END
^ permalink raw reply [relevance 5%]
* Announcing GNAT version 3.12p for Linux and Sparc Solaris
@ 1999-10-19 0:00 1% Robert Dewar
0 siblings, 0 replies; 123+ results
From: Robert Dewar @ 1999-10-19 0:00 UTC (permalink / raw)
A new public release of GNAT version 3.12p, is now
available at
ftp://cs.nyu.edu/pub/gnat
for GNU/Linux and Sparc Solaris. Other versions to follow very
shortly, as well as RPM's for Linux (from the GNAT/Linux
group).
This release coincides with the opening day of Sig Ada :-)
Robert B. K. Dewar
Ada Core Technologies
The following is a list of new features in version 3.12,
as compared with version 3.11
-----------------------------
The standard GNAT library (on Unix systems) now contains a
Makefile
called Makefile.adalib which allows recompilation of the
runtime
with different compilation options or different configuration
pragmas.
GNAT now handles C, C++ and Fortran convention boolean types
specially.
In all these cases, zero/non-zero semantics is used, so that
any
non-zero value is treated as equivalent to True. This means
that
the implementation of Interfaces.Fortran.LOGICAL is more
accurate,
and provides a convenient way of importing C int values used
as
boolean values.
GNORT now permits the use of allocators and it is also
possible to
explicitly raise Program_Error. These calls are supported by
user
defined subprograms. See GNORT documentation for full details.
A new package, GNAT.Current_Exception is provided for access
to the
current exception name and information. This is provided for
compatibility
with other Ada 83 compilers. See g-curexc.ads for a full
description of
this package.
A new gnatbind option, -shared, enables the use of a shared
GNAT library
when available (currently DEC Unix, SGI IRIX and OpenVMS).
Static GNAT library is the default on all targets but VMS and
SGI IRIX.
A new tool is provided, gnatdll. This is an NT/Win9x specific
tool
to help in constructing DLLs.
Complete rewrite of the section of NT/Win9x specific features
and
documentation of the GNAT technology in this area. This
section now
clearly explains and documents how to use the NT/Win9x
specific
features of the GNAT technology.
The compiler is now built with options -gnatpn instead of
-gnata.
This means that the front end of the compiler is considerably
faster, up to 2-3 times faster in some cases. The cases where
you
will see the biggest speed up are in -gnatc compilations with
no
code generation, or if very large specs are with'ed from
smaller
units.
If pragma Suppress is used in the gnat.adc file, this now
properly
suppresses exceptions in all files compiled in the presence of
this
gnat.adc file (Suppress pragmas in gnat.adc were previously
ignored,
which is in accordance with the RM, but certainly not what is
wanted!)
On Digital Unix 4.0D, the run time now takes advantage of the
full
range of priorities (0 .. 63).
In -gnatc mode, an existing up to date ali file is no longer
destroyed.
In particular this means that the -gnatc -gnatt compilations
used by
ASIS do not destroy existing ali files.
A new switch -gnaty activates style checking features in the
compiler.
These roughly correspond to the checking done by the special
internal
-gnatg flag, except that -gnaty allows extensive choice of
which checks
are to be performed, and also allows parametrization, e.g. of
the indent
level that is enforced.
The handling of aggregates has been optimized in many cases,
generating
more efficient code and less memory usage.
The binder now generates an Ada package as the main program by
default
instead of a C program. The generated files are called
b~xxx.ads/adb,
where xxx is the name of the main program. The -C switch for
both
gnatbind and gnatlink can be used to get the old behavior of
generating
the main program in C.
The compilation switches are now stored in the ali file (lines
starting
with A). This is used to implement the corresponding ASIS
option to
retrieve the command line arguments.
A new pragma Finalize_Storage_Only has been implemented. It
indicates
that a Finalize routine is present only for the purposes of
releasing
storage, and that thus the Finalize call can be omitted in
some cases
(e.g. for objects declared at the library level).
A function and a procedure to retreive the current working
directory
have been added in g-dirope.ad[sb].
Gcov, a test coverage program is now distributed with GNAT.
See the gcc
documentation for its use.
pragma Task_Info is now available for AiX and can be used to
specify the
scheduling contention scope of each Ada task.
New switches -nostdinc and -nostdlib for gnatmake and
gnatbind. New
switch -nostdinc for gcc/gnat1 and gnatls. -nostdinc turns off
looking
for sources in the system default directory. -nostdlib turns
off looking
for library files in the system default directory.
[VMS] Wildcard directory specifications accepted and expanded
in /SEARCH
qualifiers and ADA_{INCLUDE,OBJECTS}_PATH logicals.
Add support for Windows NT Resources. Under NT there are two
new tools.
RCL the resource compiler and res2coff to convert a binary
resources
file to a coff object file to be linked with a program.
A new package GNAT.Traceback provides non-symbolic tracebacks
at
run time on Solaris and Linux.
A new package GNAT.Traceback.Symbolic provides symbolic
tracebacks at
run time on Solaris and Linux.
A new package GNAT.Regpat implements the full V7 regular
expression
matching, including such features as anchors, and is thus a
more
complete implementation than that in GNAT.Regexp, which is
retained
for compatibility (and is in any case more appropriate for
certain
functions).
The packages Calendar and Ada.Real_Time for the NT/Win9x
implementation now
use a high resolution clock providing a resolution of 1
micro-sec.
A new convention DLL has been added to simplify the
development of DLL's
using the NT/Win9x port of GNAT..
The convention Stdcall is now available for variables as well
as
subprograms for the NT/Win9x port of GNAT.
A restricted version of the run time is now provided. This
version of
the run time is automatically used if the appropriate set of
restrictions
is used. A new pragma Restricted_Run_Time sets this set of
restrictions.
The restricted run-time is more efficient for the set of
allowed operations.
A new pragma Ravenscar establishes the set of restrictions
that corresponds
with the Ravenscar profile for limited tasking. This is a more
restrictive
set than Restricted_Run_Time, so use of pragma Ravenscar will
also cause the
restricted run time to be used.
A new restriction identifier No_Complex_Barriers has been
added which
causes barriers to be restricted to simple boolean variables
declared
within the protected type. This is one of the Ravenscar
restrictions.
A new restriction identifier No_Select_Statements has been
added which
completely eliminates the use of select statements. This is
one of the
Ravenscar restrictions
The list of switches printed out when the -gnath option is
used now includes
common gcc switches.
The handling of protected objects with no entries has been
simplified and
optimized.
A new switch -gnatR causes the compiler to output
representation information
for declared arrays and records.
A new switch -gnatD causes the compiler to generate files with
names
x.dg (where x is the source file name) that contain the
expanded (-gnatG)
code and to force debugging information to refer to these
files. This
allows source level debugging using the expanded code.
The package GNAT.Command_Line has been updated to handle
sections on
the command line, as in gnatmake (-largs, -bargs, ...). There
is also
a new character '!' to specify that a switch must have a
parameter, and
that there must be no space between the two. Finally, a new
special switch
'*' has been created, to match any item on the command line.
Shared passive partitions are fully implemented, including
support for
protected objects that provide global locking capability. The
implementation
allows the use of shared passive partitions to communicate
between separate
programs as well as between partitions of a single distibuted
program, and
also provides for automatic persistance from one run to
another.
A new flag -O for gnatbind gives a complete list of objects
that are
needed by the Ada part of the program.
The sorting packages GNAT.Heap_Sort_A, GNAT.Heap_Sort_G,
GNAT.Bubble_Sort_A
and GNAT. Bubble_Sort_G use subtype Natural instead of
Positive for the
number of items to sort, so it is no longer an error to sort
an empty
range of items.
A new package GNAT.Threads (in files g-thread.ads/adb)
provides a general
facility for foreign code (e.g. written in C) to create
threads in a
manner known to the Ada run-time system, so that these threads
can
freely call Ada code that uses explicit or implicit tasking
constructs.
The Assert pragma now permits expressions of types derived
from Boolean
instead of requiring Standard.Boolean itself.
A new flag -z for gnatmake and gnatbind allows the more
convenient
compilation/binding/linking of an Ada program without a main
subprogram.
The execution of such a program is identical to the one of the
program
with an empty main subprogram with a "with" clause on the main
package.
The output format of gnatxref has been modified to be in
columnar
format so that it is easier to read.
The gnatfind utility now accepts wild cards in the file name
to allow
a set of files to be searched, and this works on all operating
systems.
The gnatprep utility now supports boolean expressions (and,
or, and
then, or else, =, 'Defined), and has a new command line switch
to
define symbols.
A new optimization circuit removes many subscript checks in
loops in
the cases where the range of the loop can be determined to be
in range
of the subscript.
The location (file and line number) at which an exception was
raised now
appears by default in the exception message, and the message
for an
unhandled exception includes this information.
Zero cost exceptions are now implemented in DEC Unix and on
SGI Irix.
On these two targets, zero cost exception handling is the
standard
default. You can select longjmp/setjmp exception handling
(smaller
executables) by using the -gnatL switch on all compilations
including
the library units. The switch -gnatZ can be used to enable
zero cost
exceptions on certain other targets including NT, but these
are partial
implementations in which exceptions cannot be propagated
through C
code (but for all Ada programs, this will work correctly).
In the DEC Unix version, foreign threads (those created
outside Ada) are
now recognized automatically and converted to Ada tasks for
proper
treatment by the Ada run time as Ada tasks.
24-bit packed components are now permitted in GNORT mode
provided that
the alignment of the component type is explicitly set to 1.
A new attribute System'To_Address (X) has exactly the same
result value
as System.Storage_Elements.To_Address (X), except that the
result is a
static value if the input value is static, allowing its use in
a package
to which pragma Preelaborate applies.
It is now permissible to declare library variables whose
nominal type is
unconstrained String in GNORT mode if the initializing
expression is a
string literal.
Sent via Deja.com http://www.deja.com/
Before you buy.
^ permalink raw reply [relevance 1%]
* Re: [A bit OT] Problems with GNAT 3.11p
@ 1999-09-26 0:00 1% ` Robert Dewar
0 siblings, 0 replies; 123+ results
From: Robert Dewar @ 1999-09-26 0:00 UTC (permalink / raw)
In article <37ECE188.7AF1E2B@yukyonline.co.yuky>,
the middleman <charles.dand@yukyonline.co.yuky> wrote:
> I agree with you. I am guilty of not reading the
> documentation!
well we all do that sometimes, and the fact is that many
kinds of program really don't need documentation. For instance
I have used powerpoint for ages and know it quite well, but
never read any documentation.
> And i'd
> say that NG's are getting to a sad state where people just ask
questions
> without looking into it much themselves.
Well of course in this situation you really needed to ask the
newsgroup anyway, and got the valuable information about the
RPM's that you needed, so that's not so terrible :-) :-)
> Normally I would do a bit more
> work myself but on this occason I think I have an good excuse
> (excueses.....excuses!!). I had been up all night messing
around with 3D
> on my Voodoo Banshee (and I'm sure those of you who have tried
to get
> one of those to work with linux will agree, it can get very
> frustrating).
Sometimes I must say I find it hard to believe that anyone can
get anything working, we have all been there!
> Once I had succeded with that I moved on to installing
> GNAT. when I got these problems I couldn't be bothered reading
> anything
> so I just posted a question.
Pick up the RPM, and things should be smooth. Note that we have
given the GNAT/Linux team advance access to the 3.12 version,
so they should have the RPM's available for 3.12p almost
simultaneously with the 3.12p release. That's the idea.
> Just to say that I am guilty thats all.
Well I apologize if I was too fierce reacting -- it's always
frustrating on the other end when you work hard on the
documentation and it does not get read :-)
P.S. If you are using GNAT, take the time to read the manuals
at some point, you will be surprised how much useful stuff
is there!
> P.S. I know i should have read the documenation before even
> trying to install it but to be honest I don't think that many
> people do that.
It's often worth just glancing at a top level readme file, even
if you don't have time for the full doc!
> P.P.S Good news that GNAT 3.12p is out soon
Yup, and I think you will find a lot of good stuff there.
Here for reference is the list of features new in 3.12:
Enum_Rep can now be applied to integer types and objects. This
allows its use on (<>) formal discrete types in generic packages
and subprograms.
A preliminary version of the Data Decomposition Annex is now
available for use in ASIS. This preliminary version supports
only the simple typ model, and does not yet allow queries with
Portable_Data arguments.
The -gnatR switch can now be used in conjunction with the -gnatc
switch to obtain representation information without requiring a
full compile.
The standard GNAT library (on Unix systems) now contains a
Makefile called Makefile.adalib which allows recompilation of
the runtim with different compilation options or different
configuration pragmas.
GNAT now handles C, C++ and Fortran convention boolean types
specially. In all these cases, zero/non-zero semantics is used,
so that any non-zero value is treated as equivalent to True.
This means that the implementation of Interfaces.Fortran.LOGICAL
is more accurate and provides a convenient way of importing C
int values used as boolean values.
GNORT now permits the use of allocators and it is also possible
to explicitly raise Program_Error. These calls are supported by
user defined subprograms. See GNORT documentation for full
details.
A new package, GNAT.Current_Exception is provided for access to
the current exception name and information. This is provided for
compatibility with other Ada 83 compilers. See g-curexc.ads for
a full description of this package.
A new gnatbind option, -shared, enables the use of a shared GNAT
library when available (currently DEC Unix, SGI IRIX and
OpenVMS). Static GNAT library is the default on all targets but
VMS and SGI IRIX.
A new tool is provided, gnatdll. This is an NT/Win9x specific
tool to help in constructing DLLs.
Complete rewrite of the section of NT/Win9x specific features
and documentation of the GNAT technology in this area. This
section now clearly explains and documents how to use the
NT/Win9x specific features of the GNAT technology.
The compiler is now built with options -gnatpn instead of
-gnata. This means that the front end of the compiler is
considerably faster, up to 2-3 times faster in some cases. The
cases where you will see the biggest speed up are in -gnatc
compilations with no code generation, or if very large specs are
with'ed from smaller units.
If pragma Suppress is used in the gnat.adc file, this now
properly suppresses exceptions in all files compiled in the
presence of this gnat.adc file (Suppress pragmas in gnat.adc
were previously ignored, which is in accordance with the RM, but
certainly not what is wanted!)
On Digital Unix 4.0D, the run time now takes advantage of the
full range of priorities (0 .. 63).
In -gnatc mode, an existing up to date ali file is no longer
destroyed. In particular this means that the -gnatc -gnatt
compilations used by ASIS do not destroy existing ali files.
A new switch -gnaty activates style checking features in the
compiler. These roughly correspond to the checking done by the
special internal -gnatg flag, except that -gnaty allows
extensive choice of which checks are to be performed, and also
allows parametrization, e.g. of the indent level that is
enforced.
The handling of aggregates has been optimized in many cases,
generating more efficient code and less memory usage.
The binder now generates an Ada package as the main program by
default instead of a C program. The generated files are called
b~xxx.ads/adb, where xxx is the name of the main program. The -C
switch for both gnatbind and gnatlink can be used to get the old
behavior of generating the main program in C.
The compilation switches are now stored in the ali file (lines
starting with A). This is used to implement the corresponding
ASIS option to retrieve the command line arguments.
A new pragma Finalize_Storage_Only has been implemented. It
indicates that a Finalize routine is present only for the
purposes of releasing storage, and that thus the Finalize call
can be omitted in some cases (e.g. for objects declared at the
library level).
A function and a procedure to retrieve the current working
directory have been added in g-dirope.ad[sb].
Gcov, a test coverage program is now distributed with GNAT. See
the gcc documentation for its use.
pragma Task_Info is now available for AiX and can be used to
specify the scheduling contention scope of each Ada task.
New switches -nostdinc and -nostdlib for gnatmake and gnatbind.
New switch -nostdinc for gcc/gnat1 and gnatls. -nostdinc turns
off looking for sources in the system default directory.
-nostdlib turns off looking for library files in the system
default directory.
[VMS] Wildcard directory specifications accepted and expanded in
/SEARCH qualifiers and ADA_{INCLUDE,OBJECTS}_PATH logicals.
Add support for Windows NT Resources. Under NT there are two new
tools. RCL the resource compiler and res2coff to convert a
binary resources file to a coff object file to be linked with a
program.
A new package GNAT.Traceback provides non-symbolic tracebacks at
run time on Solaris and Linux.
A new package GNAT.Traceback.Symbolic provides symbolic
tracebacks at run time on Solaris and Linux.
A new package GNAT.Regpat implements the full V7 regular
expression matching, including such features as anchors, and is
thus a more complete implementation than that in GNAT.Regexp,
which is retained for compatibility (and is in any case more
appropriate for certain functions).
The packages Calendar and Ada.Real_Time for the NT/Win9x
implementation now use a high resolution clock providing a
resolution of 1 micro-sec.
A new convention DLL has been added to simplify the development
of DLL's using the NT/Win9x port of GNAT..
The convention Stdcall is now available for variables as well as
subprograms for the NT/Win9x port of GNAT.
A restricted version of the run time is now provided. This
version of the run time is automatically used if the appropriate
set of restrictions is used. A new pragma Restricted_Run_Time
sets this set of restrictions. The restricted run-time is more
efficient for the set of allowed operations.
A new pragma Ravenscar establishes the set of restrictions that
corresponds with the Ravenscar profile for limited tasking. This
is a more restrictive set than Restricted_Run_Time, so use of
pragma Ravenscar will also cause th restricted run time to be
used.
A new restriction identifier No_Complex_Barriers has been added
which causes barriers to be restricted to simple boolean
variables declare within the protected type. This is one of the
Ravenscar restrictions.
A new restriction identifier No_Select_Statements has been added
which completely eliminates the use of select statements. This
is one of the Ravenscar restrictions
The list of switches printed out when the -gnath option is used
now includes common gcc switches.
The handling of protected objects with no entries has been
simplified and optimized.
A new switch -gnatR causes the compiler to output representation
information for declared arrays and records.
A new switch -gnatD causes the compiler to generate files with
names x.dg (where x is the source file name) that contain the
expanded (-gnatG) code and to force debugging information to
refer to these files. This allows source level debugging using
the expanded code.
The package GNAT.Command_Line has been updated to handle
sections on the command line, as in gnatmake (-largs, -bargs,
...). There is also a new character '!' to specify that a switch
must have a parameter, and that there must be no space between
the two. Finally, a new special switch '*' has been created, to
match any item on the command line.
Shared passive partitions are fully implemented, including
support for protected objects that provide global locking
capability. The implementation allows the use of shared passive
partitions to communicate between separate programs as well as
between partitions of a single distibuted program, and also
provides for automatic persistance from one run to another.
A new flag -O for gnatbind gives a complete list of objects that
are needed by the Ada part of the program.
The sorting packages GNAT.Heap_Sort_A, GNAT.Heap_Sort_G,
GNAT.Bubble_Sort_A and GNAT. Bubble_Sort_G use subtype Natural
instead of Positive for the number of items to sort, so it is no
longer an error to sort an empty range of items.
A new package GNAT.Threads (in files g-thread.ads/adb) provides
a general facility for foreign code (e.g. written in C) to
create threads in a manner known to the Ada run-time system, so
that these threads can freely call Ada code that uses explicit
or implicit tasking constructs.
The Assert pragma now permits expressions of types derived from
Boolean instead of requiring Standard.Boolean itself.
A new flag -z for gnatmake and gnatbind allows the more
convenient compilation/binding/linking of an Ada program
without a main subprogram. The execution of such a program is
identical to the one of the program with an empty main
subprogram with a "with" clause on the main package.
The output format of gnatxref has been modified to be in
columnar format so that it is easier to read.
The gnatfind utility now accepts wild cards in the file name to
allow a set of files to be searched, and this works on all
operating systems.
The gnatprep utility now supports boolean expressions (and, or,
and then, or else, =, 'Defined), and has a new command line
switch to define symbols.
A new optimization circuit removes many subscript checks in
loops in the cases where the range of the loop can be determined
to be in range of the subscript.
The location (file and line number) at which an exception was
raised now appears by default in the exception message, and the
message for an unhandled exception includes this information.
Zero cost exceptions are now implemented in DEC Unix and on SGI
Irix. On these two targets, zero cost exception handling is the
standard default. You can select longjmp/setjmp exception
handling (smaller executables) by using the -gnatL switch on all
compilations including the library units. The switch -gnatZ can
be used to enable zero cos exceptions on certain other targets
including NT, but these are partial implementations in which
exceptions cannot be propagated through C code (but for all Ada
programs, this will work correctly).
In the DEC Unix version, foreign threads (those created outside
Ada) are now recognized automatically and converted to Ada tasks
for proper treatment by the Ada run time as Ada tasks.
24-bit packed components are now permitted in GNORT mode
provided that the alignment of the component type is explicitly
set to 1.
A new attribute System'To_Address (X) has exactly the same
result value as System.Storage_Elements.To_Address (X), except
that the result is a static value if the input value is static,
allowing its use in a package to which pragma Preelaborate
applies.
It is now permissible to declare library variables whose nominal
type is unconstrained String in GNORT mode if the initializing
expression is a string literal.
Robert Dewar
Ada Core Tecnologies
Sent via Deja.com http://www.deja.com/
Before you buy.
^ permalink raw reply [relevance 1%]
* Re: Ada95 + FORTRAN 77
@ 1999-09-06 0:00 6% ` lafage8770
1999-09-06 0:00 6% ` Matthew Heaney
1999-09-06 0:00 4% ` Preben Randhol
0 siblings, 2 replies; 123+ results
From: lafage8770 @ 1999-09-06 0:00 UTC (permalink / raw)
In article <m3hfl8ihzd.fsf@kiuk0156.chembio.ntnu.no>,
Preben Randhol <randhol@pvv.org> wrote:
> I have read (think it was on the net) that one can bind Fortran and
> Ada95 together. Does anybody know if one can use Fortran 77?
Yes, for instance g77 cooperates well with gnat on my GNU/Linux box.
> I have a calculation program written in FORTRAN 77 and want to just
> make a graphical interface to it so that it will be easier to do
> calculations. I want to use Ada95 and GTK+. So I'm wondering if
> anybody know of a working example for the Ada95 - FORTRAN 77
> connection (don't have to be any GUI) that I could look at?
First, I will send you an example which has been given
on this list
(by Sune Falck on Fri, 12 Dec 1997 20:03:46 +0200)
-------------------------------------------------------------------
-- file ftest.adb
with Ada.Text_IO; use Ada.Text_IO;
with Ada.Float_Text_IO; use Ada.Float_Text_IO;
procedure Ftest is
procedure Adder (A : in Float; B: in Float; Sum : out Float);
pragma Import (Fortran, Adder, Link_Name => "adder_");
A : Float := 12.0;
B : Float := 13.0;
Sum : Float;
begin
Adder (A, B, Sum);
Put (A); Put (B); Put ('='); Put (Sum); New_Line;
end Ftest;
-------------------------------------------------------------------
file adder.f:
SUBROUTINE ADDER (A, B, SUM)
REAL*4 A
REAL*4 B
REAL*4 SUM
SUM = A + B
END
-------------------------------------------------------------------
g77 -c adder.f
gnatmake ftest -largs adder.o
... and it works
AND NOW even better: how to pass common ?
(It works, but I do not know if this is the ``proper way''
and would appreciate any comment)
-------------------------------------------------------------------
file common_basic.ads:
with Interfaces.Fortran; use Interfaces.Fortran;
package Common_Basic is
type Basic_Common is record
X, Y, Z : Double_Precision;
end record;
Basic : Basic_Common;
pragma Import(Fortran, Basic, Link_Name => "basic_");
end Common_Basic;
-------------------------------------------------------------------
file ada_application.adb:
with Interfaces.Fortran; use Interfaces.Fortran;
with Ada.Text_IO; use Ada.Text_IO;
with Ada.Float_Text_IO; use Ada.Float_Text_IO;
with Common_Basic; use Common_Basic;
procedure Ada_Application is
procedure Compute(T : in Double_Precision);
pragma Import(Fortran, Compute, Link_Name => "compute_");
begin
Basic.X :=1.0;
Basic.Y :=2.0;
Basic.Z :=3.0;
Put(Float(Basic.X));
Put(Float(Basic.Y));
Put(Float(Basic.Z));
New_Line;
Compute(0.0);
Put(Float(Basic.X));
Put(Float(Basic.Y));
Put(Float(Basic.Z));
New_Line;
end Ada_Application;
-------------------------------------------------------------------
file compute.f:
subroutine compute(t)
implicit none
c double precision t
real*8 t
double precision x,y,z
common /basic/ x,y,z
write(*,*)'t : ',t
write(*,*)'x : ',x
write(*,*)'y : ',y
write(*,*)'z : ',z
z=sqrt(z)
return
end
-------------------------------------------------------------------
g77 -c compute.f
gnatmake ada_application -largs compute.o
Et voila !
-------------------------------------------------------------------
--
Vincent Lafage
``Qui est un plumeur de faisan ? ''
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
^ permalink raw reply [relevance 6%]
* Re: Ada95 + FORTRAN 77
1999-09-06 0:00 6% ` lafage8770
@ 1999-09-06 0:00 6% ` Matthew Heaney
1999-09-06 0:00 0% ` Robert Dewar
1999-09-06 0:00 4% ` Preben Randhol
1 sibling, 1 reply; 123+ results
From: Matthew Heaney @ 1999-09-06 0:00 UTC (permalink / raw)
In article <7r07rr$gap$1@nnrp1.deja.com> , lafage8770@my-deja.com wrote:
> procedure Adder (A : in Float; B: in Float; Sum : out Float);
You should be using the types in Interfaces.Fortran, and you should also
have a pragma Convention.
> pragma Import (Fortran, Adder, Link_Name => "adder_");
>
> A : Float := 12.0;
> B : Float := 13.0;
> Sum : Float;
> begin
> Adder (A, B, Sum);
> Put (A); Put (B); Put ('='); Put (Sum); New_Line;
>
> end Ftest;
> -------------------------------------------------------------------
> file adder.f:
> SUBROUTINE ADDER (A, B, SUM)
> REAL*4 A
> REAL*4 B
> REAL*4 SUM
The reason you need to use the scalar types declared in Interfaces.Fortran
is that you have no guarantee that REAL*4 is the same as an Ada Float type.
> SUM = A + B
> END
> file common_basic.ads:
> with Interfaces.Fortran; use Interfaces.Fortran;
>
> package Common_Basic is
> type Basic_Common is record
> X, Y, Z : Double_Precision;
> end record;
> Basic : Basic_Common;
You have the scalar types right, but you still need a pragma Convention for
your record type. Otherwise, how do you know that the representation of the
record on the Ada side matches the rep on the Fortran side?
> pragma Import(Fortran, Basic, Link_Name => "basic_");
> end Common_Basic;
^ permalink raw reply [relevance 6%]
* Re: Ada95 + FORTRAN 77
1999-09-06 0:00 4% ` Preben Randhol
@ 1999-09-06 0:00 5% ` Robert Dewar
1999-09-06 0:00 5% ` Preben Randhol
0 siblings, 1 reply; 123+ results
From: Robert Dewar @ 1999-09-06 0:00 UTC (permalink / raw)
In article <m3so4sgprj.fsf@kiuk0156.chembio.ntnu.no>,
Preben Randhol <randhol@pvv.org> wrote:
> Thanks! It worked very nice. I also noticed that one have to
be
> careful with the variable types. Changing, in the F77 program,
REAL*4
> to DOUBLE PRECISION resulted in a bug in the output. But when
I added
> Interfaces.Fortran and used Double_Precision it worked fine
again :-)
Well yes, of course you must be careful to have corresponding
types, and typically systems will not be able to check this
in Ada-Fortran interfacing (actually most Fortran compilers
don't even check this in Fortran-Fortran interfacing).
Do if you are using DOUBLE PRECISION in the Fortran program,
you must use Interfaces.Fortran.Double_Precision.
In GNAT, you can simply use Long_Float, and this will always
work, because GNAT always defines
type Fortran_Integer is new Integer;
type Real is new Float;
type Double_Precision is new Long_Float;
One other point is to be careful of type Logical in the
Fortran interface. This is defined to be a new Boolean, but
with very unusual (zero/non-zero) semantics.
There are no ACVC tests to ensure that this is done right, and
it is quite a lot of specialized mechanism in the compiler to
deal with this very non-standard Boolean type. So if you rely
on this, be careful to check that your compiler handles this.
The proper handling of Fortran Logical was only recently added
to GNAT (for version 3.12). At the same time, we also
implemented a rather nice feature:
type C_Bool is new Boolean;
pragma Convention (C, C_Bool);
the semantics of this boolean will be like C, zero/non-zero,
rather than normal Ada representation semantics. This can make
interfacing to booleans in C quite a bit cleaner and more
abstract (otherwise you have to explicitly treat the C logical
values as integers on the Ada sign with zero/non-zero semantics)
Robert Dewar
Ada Core Technologies
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
^ permalink raw reply [relevance 5%]
* Re: Ada95 + FORTRAN 77
1999-09-06 0:00 5% ` Robert Dewar
@ 1999-09-06 0:00 5% ` Preben Randhol
0 siblings, 0 replies; 123+ results
From: Preben Randhol @ 1999-09-06 0:00 UTC (permalink / raw)
Robert Dewar <dewar@gnat.com> writes:
| Do if you are using DOUBLE PRECISION in the Fortran program,
| you must use Interfaces.Fortran.Double_Precision.
|
| In GNAT, you can simply use Long_Float, and this will always
| work, because GNAT always defines
|
| type Fortran_Integer is new Integer;
| type Real is new Float;
| type Double_Precision is new Long_Float;
I see, but this will only work when compiled on GNAT and reduce
portability? I'm new so I don't know if there are any other Ada
compilers out there. :-)
--
Preben Randhol oO "Don't think about domination, think
[randhol@pvv.org] .` ; about freedom, it doesn't dominate."
[www.pvv.org/~randhol/] \ G -- RMS, LinuxWorld 1999.
`_) n o m e
^ permalink raw reply [relevance 5%]
* Re: Ada95 + FORTRAN 77
1999-09-06 0:00 6% ` lafage8770
1999-09-06 0:00 6% ` Matthew Heaney
@ 1999-09-06 0:00 4% ` Preben Randhol
1999-09-06 0:00 5% ` Robert Dewar
1 sibling, 1 reply; 123+ results
From: Preben Randhol @ 1999-09-06 0:00 UTC (permalink / raw)
lafage8770@my-deja.com writes:
| First, I will send you an example which has been given
| on this list
| (by Sune Falck on Fri, 12 Dec 1997 20:03:46 +0200)
[...]
Thanks! It worked very nice. I also noticed that one have to be
careful with the variable types. Changing, in the F77 program, REAL*4
to DOUBLE PRECISION resulted in a bug in the output. But when I added
Interfaces.Fortran and used Double_Precision it worked fine again :-)
--
Preben Randhol oO "Don't think about domination, think
[randhol@pvv.org] .` ; about freedom, it doesn't dominate."
[www.pvv.org/~randhol/] \ G -- RMS, LinuxWorld 1999.
`_) n o m e
^ permalink raw reply [relevance 4%]
* Re: Ada95 + FORTRAN 77
1999-09-06 0:00 6% ` Matthew Heaney
@ 1999-09-06 0:00 0% ` Robert Dewar
0 siblings, 0 replies; 123+ results
From: Robert Dewar @ 1999-09-06 0:00 UTC (permalink / raw)
In article <37d3b7de@news1.prserv.net>,
"Matthew Heaney" <matthew_heaney@acm.org> wrote:
> In article <7r07rr$gap$1@nnrp1.deja.com> ,
lafage8770@my-deja.com wrote:
>
> > procedure Adder (A : in Float; B: in Float; Sum : out
Float);
>
> You should be using the types in Interfaces.Fortran, and you
> should also have a pragma Convention.
Although this is true if you want to be sure to write code
that is portable between Ada 95 compilers, it is not really
necessary when using GNAT and g77, because the correspondence
between types (e.g. Real*4 and Float is in fact guaranteed).
It's always a bit of a difficult decision. The use of the types
in the interfaces packages often makes the interface a lot
heavier than it would be otherwise, so you have to make a
decision based on a trade off here.
The use of pragma Convention is a good idea anyway, because
a) it is syntactically light.
b) it warns the reader right away that Fortran is involved
c) if you have a compiler that properly implements annex G,
it also takes care of row- vs column- addressing of multi-dim
arrays.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
^ permalink raw reply [relevance 0%]
* Re: Linking FORTRAN77 to Ada83
@ 1999-06-10 0:00 4% ` bob
0 siblings, 0 replies; 123+ results
From: bob @ 1999-06-10 0:00 UTC (permalink / raw)
Here is an Ada spec for currently running code. Compiles and runs on GNAT
for IRIX(SGI) and Linux (Intel)
___________________________
-- %@(#)fortran_interface_s.a 1.3% %02 Mar 1998% - SCCS Control Line
-- 1.2 09-Feb-98 dab Added Stereo to Mono feedback
with Global_Defs;
with Interfaces.Fortran;
with Los_Vectors;
with OSM_Defs;
with Vectors;
with Unchecked_Deallocation;
package Fortran_Interface is
package Fortran renames Interfaces.Fortran;
package GD renames Global_Defs;
package vec renames vectors;
package LV renames Los_Vectors;
package OD renames OSM_Defs;
type Fortran_Truth_Type is
record
Time : GD.Epoch_Time_Type := 0.0;
State : LV.State_ECI_Type;
Unit_LOS : VEC.Vector(1..3) := (others => 0.0);
Intensity : GD.Real := 0.0;
Tgtid : GD.Int := 0;
Class_Id : GD.Int := 1;
Phase_Id : GD.Int := 1;
end record;
for Fortran_Truth_Type use
record
Time at 0 range 0..63;
State at 0 range 64..639;
Unit_LOS at 0 range 640..831;
Intensity at 0 range 832..895;
Tgtid at 0 range 896..927;
Class_Id at 0 range 928..959;
Phase_Id at 0 range 960..991;
end record;
type Fortran_Scan_Execution_type is
record
TFirst_Scan : GD.Epoch_Time_type := 0.0;
TLast_Scan : GD.Epoch_Time_type := 0.0;
Scan_Pointer : vec.vector(1..3) := (others => 0.0);
Platform_State : LV.State_Eci_Type := (others => (others =>
0.0));
Azfirst : GD.Real := 0.0;
Azlast : GD.Real := 0.0;
Sweep_Rate : GD.Real := 0.0;
Sensor_ID : GD.Int := 0;
Scan_ID : GD.Int := 0;
Platform_Id : GD.Int := 0;
Execute : GD.Boolean_Type := False;
end record;
for Fortran_Scan_Execution_type use
record
TFirst_Scan at 0 range 0..63;
TLast_Scan at 0 range 64..127;
Scan_Pointer at 0 range 128..319;
Platform_State at 0 range 320..895;
Azfirst at 0 range 896..959;
Azlast at 0 range 960..1023;
Sweep_Rate at 0 range 1024..1087;
Sensor_ID at 0 range 1088..1119;
Scan_ID at 0 range 1120..1151;
Platform_Id at 0 range 1152..1183;
Execute at 0 range 1208..1215;
end record;
type Fortran_Scan_Execution_Access_type is access
Fortran_Scan_Execution_type;
type Fortran_Sensor_Header_type is
record
NLOS : GD.Int := 0;
Scan_Execution : Fortran_Scan_Execution_type;
end record;
for Fortran_Sensor_Header_type use
record
NLOS at 0 range 0..31;
Scan_Execution at 0 range 64..1279;
end record;
type Fortran_Sensor_Header_Access_type is access
Fortran_Sensor_Header_type;
type Fortran_LOS_Vector_type;
type Fortran_LOS_Vector_Access_type is access Fortran_LOS_Vector_type;
type Fortran_LOS_Vector_type is
record
Epoch : GD.Epoch_Time_type := 0.0;
platstate : LV.State_Eci_Type;
Boresight : VEC.Vector(1..3) := (others => 0.0);
Unit_LOS : VEC.Vector(1..3) := (others => 0.0);
Unit_LOS_Rate : vec.vector(1..3) := (others => 0.0); -- Udot
vec
Unit_LOS_Accel : vec.vector(1..3) := (others => 0.0); --
Udotdot
Intensity : GD.Real := 0.0;
Second_Moments_ECI : VEC.Vector(1..3) := (others => 0.0);
AMA_ECI : VEC.Vector(1..3) := (others => 0.0);
RMA : GD.Real := 0.0;
Position_UV : vec.vector(1..2) := (others => 0.0);
Velocity_UV : vec.vector(1..2) := (others => 0.0);
Acceleration_UV : vec.vector(1..2) := (others => 0.0); --
06/12/95
Second_Moments_UV : VEC.Vector(1..3) := (others => 0.0);
AMA_UV : VEC.Vector(1..3) := (others => 0.0); -- uv
coordinates
truth : Fortran_Truth_Type;
Platform_ID : GD.Platform_ID_type :=
GD.Platform_ID_Type'First;
Detection_ID : GD.Int := 0;
Sensor_ID : GD.Int := 0;
Sensor_Band : GD.Int := 0;
Scan_ID : GD.Int := 0;
LOS_ID : GD.Int := 0;
Score_Type_Obj : GD.Int := 0;
osm_type : GD.Int := 0;
Num_Asso_Mono : GD.Int := 0; -- # of mono tracks using
this
Associated : Boolean := False;
end record;
for Fortran_LOS_Vector_type use
record
Epoch at 0 range 0..63;
platstate at 0 range 64..639;
Boresight at 0 range 640..831;
Unit_LOS at 0 range 832..1023;
Unit_LOS_Rate at 0 range 1024..1215;
Unit_LOS_Accel at 0 range 1216..1407;
Intensity at 0 range 1408..1471;
Second_Moments_ECI at 0 range 1472..1663;
AMA_ECI at 0 range 1664..1855;
RMA at 0 range 1856..1919;
Position_UV at 0 range 1920..2047;
Velocity_UV at 0 range 2048..2175;
Acceleration_UV at 0 range 2176..2303;
Second_Moments_UV at 0 range 2304..2495;
AMA_UV at 0 range 2496..2687;
truth at 0 range 2688..3679;
-- Fortran seems to allign this next field on an 8 byte boundary
Platform_ID at 0 range 3712..3743;
Detection_ID at 0 range 3744..3775;
Sensor_ID at 0 range 3776..3807;
Sensor_Band at 0 range 3808..3839;
Scan_ID at 0 range 3840..3871;
LOS_ID at 0 range 3872..3903;
Score_Type_Obj at 0 range 3904..3935;
osm_type at 0 range 3936..3967;
Num_Asso_Mono at 0 range 3968..3999;
Associated at 0 range 4024..4031;
end record;
type Fortran_LOS_Array_type is array ( GD.Int range <> ) of
Fortran_LOS_Vector_Access_type;
type Fortran_LOS_Array_Access_type is access Fortran_LOS_Array_type;
type Fortran_MDP_OSM_Type;
type Fortran_MDP_OSM_Access_Type is access Fortran_MDP_OSM_Type;
type Fortran_MDP_OSM_Type is
record
Epoch : GD.Epoch_Time_Type := 0.0;
Platform_State : OD.State_ECI_Type := (others => (others =>
0.0));
Boresight : VEC.Vector(1..3) := (others => 0.0);
Unit_LOS : OD.Unit_LOS_Type := (others => 0.0);
Unit_LOS_Rate : OD.Unit_LOS_Type := (others => 0.0);
Unit_LOS_Accel : OD.Unit_LOS_Type := (others => 0.0);
Intensity : GD.Real := 0.0;
Second_Moments_ECI : VEC.Vector(1..3) := (others => 0.0);
AMA_ECI : VEC.Vector(1..3);
RMA : GD.Real;
Truth : Fortran_Truth_Type;
Platform_ID : GD.Platform_ID_Type := 1;
Mono_ID : GD.Mono_ID_Type := 0;
Parent_ID : GD.Mono_ID_Type := 0;
Stereo_ID : GD.Stereo_ID_Type := 0;
Sensor : GD.Int := 0;
Sensor_Band : GD.Int := 0;
Detection_ID : GD.Int := 0;
OSM_Type : GD.Int := 0;
Object : GD.Int := 0;
Phase : GD.Int := 0;
Track_Status : GD.Int := 0;
Mono_Status : GD.Int := 0;
Mono_Type : GD.Int := 0;
end record;
for Fortran_MDP_OSM_Type use
record
Epoch at 0 range 0..63;
Platform_State at 0 range 64..639;
Boresight at 0 range 640..831;
Unit_LOS at 0 range 832..1023;
Unit_LOS_Rate at 0 range 1024..1215;
Unit_LOS_Accel at 0 range 1216..1407;
Intensity at 0 range 1408..1471;
Second_Moments_ECI at 0 range 1472..1663;
AMA_ECI at 0 range 1664..1855;
RMA at 0 range 1856..1919;
Truth at 0 range 1920..2911;
-- Fortran seems to allign this next field on an 8 byte boundary
Platform_ID at 0 range 2944..2975;
Mono_ID at 0 range 2976..3007;
Parent_ID at 0 range 3008..3039;
Stereo_ID at 0 range 3040..3071;
Sensor at 0 range 3072..3103;
Sensor_Band at 0 range 3104..3135;
Detection_ID at 0 range 3136..3167;
OSM_Type at 0 range 3168..3199;
Object at 0 range 3200..3231;
Phase at 0 range 3232..3263;
Track_Status at 0 range 3264..3295;
Mono_Status at 0 range 3296..3327;
Mono_Type at 0 range 3328..3359;
end record;
type Mono_State_Type is --Doug
record --Doug
Epoch : GD.Real; --Doug
initialization_epoch : GD.Real; --Doug
u_state : VEC.Vector(1..3); --Doug
v_state : VEC.Vector(1..3); --Doug
Mono_ID : GD.Int; --Doug
Parent_ID : GD.Int; --Doug
num_misses : GD.Int; --Doug
end record; --Doug
for Mono_State_Type use
record --Doug
Epoch at 0 range 0..63; --Doug
initialization_epoch at 0 range 64..127; --Doug
u_state at 0 range 128..319; --Doug
v_state at 0 range 320..511; --Doug
Mono_ID at 0 range 512..543; --Doug
Parent_ID at 0 range 544..575; --Doug
num_misses at 0 range 576..607; --Doug
end record; --Doug
-- types needed for the stereo to mono feed back
subtype MAX_STEREO_PTR is GD.Int range 1..1000; --We are limited to
1000 stereo tracks for now
type STEREO_LIST_TYPE is array (MAX_STEREO_PTR) of GD.Int;
type Fortran_Stereo_IDs is
record
NUM_STEREO_TRACKS : GD.Int;
STEREO_ID : STEREO_LIST_TYPE;
end record;
for Fortran_Stereo_IDs use
record
NUM_STEREO_TRACKS at 0 range 0..31;
STEREO_ID at 0 range 32..32031;
end record;
type MONO_TAG_STRUCT is
record
PLATFORM_ID : GD.Int;
MONO_ID : GD.Int;
end record;
for MONO_TAG_STRUCT use
record
PLATFORM_ID at 0 range 0..31;
MONO_ID at 0 range 32..63;
end record;
subtype MAX_VIEWS is GD.Int range 1..40;
type MONO_LIST_TYPE is array (MAX_VIEWS) of MONO_TAG_STRUCT;
type STEREO_COMPONENTS_STRUCT is
record
STEREO_ID : GD.Int;
NUM_MONOS : GD.Int;
MONO_TAG : MONO_LIST_TYPE;
end record;
for STEREO_COMPONENTS_STRUCT use
record
STEREO_ID at 0 range 0..31;
NUM_MONOS at 0 range 32..63;
MONO_TAG at 0 range 64..2623;
end record;
type STEREO_STATE_COV_STRUCT is
record
POSITION : VEC.Vector(1..3);
VELOCITY : VEC.Vector(1..3);
ACCELERATION : VEC.Vector(1..3);
COV : VEC.Vector(1..45); --triangular form of
9 by 9
LAST_UPDATE_TIME : GD.Real;
Stereo_ChiSq : GD.Real;
IMM_Filter_Used : GD.Int;
STEREO_ID : GD.Int;
end record;
for STEREO_STATE_COV_STRUCT use
record
POSITION at 0 range 0..191;
VELOCITY at 0 range 192..383;
ACCELERATION at 0 range 384..575;
COV at 0 range 576..3455; --triangular
form of 9 by 9
LAST_UPDATE_TIME at 0 range 3456..3519;
Stereo_ChiSq at 0 range 3520..3583;
IMM_Filter_Used at 0 range 3584..3615;
STEREO_ID at 0 range 3616..3647;
end record;
type Max_Establish_Track is range 1 .. 1200;
type Mono_State_Array_type is --Doug
array (Max_Establish_Track) of Mono_State_Type; --Doug
-- Binding code for calling Fortran routines
procedure TREX_READ_INIT_PARS;
pragma INTERFACE (FORTRAN, TREX_READ_INIT_PARS);
pragma IMPORT_PROCEDURE (
INTERNAL => TREX_READ_INIT_PARS,
EXTERNAL => "trex_read_init_pars_"
);
procedure TRTT_SGEN(SR_DX :GD.Int);
pragma INTERFACE (FORTRAN, TRTT_SGEN);
pragma IMPORT_PROCEDURE (
INTERNAL => TRTT_SGEN,
EXTERNAL => "trtt_sgen_",
PARAMETER_TYPES =>
(GD.Int),
MECHANISM => (REFERENCE)
);
procedure TRCA_SETUP_CAND_TRKS;
pragma INTERFACE (FORTRAN, TRCA_SETUP_CAND_TRKS);
pragma IMPORT_PROCEDURE (
INTERNAL => TRCA_SETUP_CAND_TRKS,
EXTERNAL => "trca_setup_cand_trks_"
);
procedure TRET_SETUP_ESTAB_TRKS;
pragma INTERFACE (FORTRAN, TRET_SETUP_ESTAB_TRKS);
pragma IMPORT_PROCEDURE (
INTERNAL => TRET_SETUP_ESTAB_TRKS,
EXTERNAL => "tret_setup_estab_trks_"
);
procedure TRET_ESTAB_TRKR(SR_DX :GD.Int;
NUM_ACTIVE :in out GD.Int);
pragma INTERFACE (FORTRAN, TRET_ESTAB_TRKR);
pragma IMPORT_PROCEDURE (
INTERNAL => TRET_ESTAB_TRKR,
EXTERNAL => "tret_estab_trkr_",
PARAMETER_TYPES =>
(GD.Int,GD.Int),
MECHANISM => (REFERENCE,REFERENCE)
);
procedure TRCA_CAND_TRKR(SR_DX :GD.Int);
pragma INTERFACE (FORTRAN, TRCA_CAND_TRKR);
pragma IMPORT_PROCEDURE (
INTERNAL => TRCA_CAND_TRKR,
EXTERNAL => "trca_cand_trkr_",
PARAMETER_TYPES =>
(GD.Int),
MECHANISM => (REFERENCE)
);
procedure TRCA_CAND_INIT(SR_DX :GD.Int);
pragma INTERFACE (FORTRAN, TRCA_CAND_INIT);
pragma IMPORT_PROCEDURE (
INTERNAL => TRCA_CAND_INIT,
EXTERNAL => "trca_cand_init_",
PARAMETER_TYPES =>
(GD.Int),
MECHANISM => (REFERENCE)
);
procedure TRWD_WEED_CAND(SR_DX :GD.Int;
NUM_NEW_OSMS :in out GD.Int;
NUM_CURRENT :in out GD.Int );
pragma INTERFACE (FORTRAN, TRWD_WEED_CAND);
pragma IMPORT_PROCEDURE (
INTERNAL => TRWD_WEED_CAND,
EXTERNAL => "trwd_weed_cand_",
PARAMETER_TYPES =>
(GD.Int, GD.Int, GD.Int),
MECHANISM => (REFERENCE,REFERENCE,REFERENCE)
);
procedure CLEANUP(SR_DX :GD.Int);
pragma INTERFACE (FORTRAN, CLEANUP);
pragma IMPORT_PROCEDURE (
INTERNAL => CLEANUP,
EXTERNAL => "cleanup_",
PARAMETER_TYPES =>
(GD.Int),
MECHANISM => (REFERENCE)
);
procedure StoreScanHeader (SR_DX:in out GD.Int;
HEADER : LOS_Vectors.Sensor_Header_type);
procedure Fortran_StoreScanHeader (SR_DX:in out GD.Int;
HEADER : Fortran_Sensor_Header_type);
pragma INTERFACE (FORTRAN, Fortran_StoreScanHeader);
pragma IMPORT_PROCEDURE (
INTERNAL => Fortran_StoreScanHeader,
EXTERNAL => "store_scan_header_",
PARAMETER_TYPES =>
(GD.Int,Fortran_Sensor_Header_type),
MECHANISM => (REFERENCE,REFERENCE)
);
procedure StoreOneLOS (LOS : LOS_Vectors.LOS_Vector_type);
procedure Fortran_StoreOneLOS (LOS : Fortran_LOS_Vector_type);
pragma INTERFACE (FORTRAN, Fortran_StoreOneLOS);
pragma IMPORT_PROCEDURE (
INTERNAL => Fortran_StoreOneLOS,
EXTERNAL => "store_one_los_",
PARAMETER_TYPES =>
(Fortran_LOS_Vector_type),
MECHANISM => (REFERENCE)
);
procedure SortScanData(SR_DX : GD.Int);
pragma INTERFACE (FORTRAN, SortScanData);
pragma IMPORT_PROCEDURE (
INTERNAL => SortScanData,
EXTERNAL => "sort_scan_data_",
PARAMETER_TYPES =>
(GD.Int),
MECHANISM => (REFERENCE)
);
procedure LoadOSM(I :GD.Int; osm : out OD.MDP_OSM_Type);
procedure Fortran_LoadOSM(I :GD.Int; osm :out Fortran_MDP_OSM_Type);
pragma INTERFACE (FORTRAN, Fortran_LoadOSM);
pragma IMPORT_PROCEDURE (
INTERNAL => Fortran_LoadOSM,
EXTERNAL => "load_osm_",
PARAMETER_TYPES =>
(GD.Int, Fortran_MDP_OSM_Type),
MECHANISM => (REFERENCE,REFERENCE)
);
procedure LoadMonoStates(SR_DX : in GD.Int;
num_current : in GD.Int;
mono_states :out Mono_State_Array_type
);
pragma INTERFACE (FORTRAN, LoadMonoStates);
pragma IMPORT_PROCEDURE (
INTERNAL => LoadMonoStates,
EXTERNAL => "load_mono_states_",
PARAMETER_TYPES =>
( GD.Int, GD.Int, Mono_State_Array_type),
MECHANISM => (REFERENCE,REFERENCE,REFERENCE)
);
procedure RELEASE_TRACK_POINTS(SR_DX : GD.Int);
pragma INTERFACE (FORTRAN, RELEASE_TRACK_POINTS);
pragma IMPORT_PROCEDURE (
INTERNAL => RELEASE_TRACK_POINTS,
EXTERNAL => "release_track_points_",
PARAMETER_TYPES =>
(GD.Int),
MECHANISM => (REFERENCE)
);
procedure TERMINATE_TRACKS(SR_DX : GD.Int);
pragma INTERFACE (FORTRAN, TERMINATE_TRACKS);
pragma IMPORT_PROCEDURE (
INTERNAL => TERMINATE_TRACKS,
EXTERNAL => "terminate_tracks_",
PARAMETER_TYPES =>
(GD.Int),
MECHANISM => (REFERENCE)
);
-- Routines to implement the Stereo to Mono feedback
procedure SetActiveStereoTracks(SR_DX:GD.Int; STEREO_IDS : in
Fortran_Stereo_IDs);
pragma INTERFACE (FORTRAN, SetActiveStereoTracks);
pragma IMPORT_PROCEDURE (
INTERNAL => SetActiveStereoTracks,
EXTERNAL => "setactivestereotracks_",
PARAMETER_TYPES =>
(GD.Int,Fortran_Stereo_IDs),
MECHANISM => (REFERENCE,REFERENCE)
);
procedure UpdateStereoComponents(STEREO_COMPONENTS : in
STEREO_COMPONENTS_STRUCT);
pragma INTERFACE (FORTRAN, UpdateStereoComponents);
pragma IMPORT_PROCEDURE (
INTERNAL => UpdateStereoComponents,
EXTERNAL => "updatestereocomponents_",
PARAMETER_TYPES =>
(STEREO_COMPONENTS_STRUCT),
MECHANISM => (REFERENCE)
);
procedure SetStereoState(STEREO_STATE : in STEREO_STATE_COV_STRUCT);
pragma INTERFACE (FORTRAN, SetStereoState);
pragma IMPORT_PROCEDURE (
INTERNAL => SetStereoState,
EXTERNAL => "setstereostate_",
PARAMETER_TYPES =>
(STEREO_STATE_COV_STRUCT),
MECHANISM => (REFERENCE)
);
procedure INIT_STEREO_FB_INC;
pragma INTERFACE (FORTRAN, INIT_STEREO_FB_INC);
pragma IMPORT_PROCEDURE (
INTERNAL => INIT_STEREO_FB_INC,
EXTERNAL => "init_stereo_fb_inc_"
);
end Fortran_Interface;
_______________________________________________
cheers..bob
Guy Calinsky <calinsky@sll.northrop.com> wrote in message
news:375ECA88.CF7CFF7E@sll.northrop.com...
> I have a subroutine written in FORTRAN that I need to link with my Ada
> 83 code, but I am getting an Undefined Symbol error on that subroutine.
> I followed the pragma example in the LRM (13.9).
> Here is a small app I created to test the concept:
> ----------------------
>
> with Text_io; use Text_io;
> with Long_Float_io; use Long_Float_io;
>
> procedure Ada_Main is
>
> procedure root(A : Long_Float; B : Long_Float; C : Long_Float; Result
> : out Long_Float);
> pragma Interface(Fortran, root);
>
> result : Long_Float;
>
> begin
>
> root(1.0, 2.0, 1.0, result);
> put("result = "); put(result); new_line;
>
> end Ada_Main;
> ----------------------
>
> My FORTRAN subroutine :
> subroutine root(a, b, c, x)
> implicit none
> real a, b, c, x
> x = SQRT(b**2 - 4.0 * a * c) / (2.0 * a)
> return
> end
> ----------------------
>
> My Make script :
> f77 -Xlist -g -C root.for
> ada ada_main.a
> a.ld -o ada_fortran_test ada_main root.o
> ----------------------
>
> Everything compiles ok and root.o does exist, yet I get this result :
> Undefined first referenced
> symbol in file
> root
> /home/calinsky/Fortran_Ada_Test/.objects/ada_main01
> ld: fatal: Symbol referencing errors. No output written to
> ada_fortran_test
>
>
> Any thoughts or ideas?
> Thanks,
> Guy
>
^ permalink raw reply [relevance 4%]
* Re: Very big Integers
1999-04-25 0:00 0% ` Matthew Heaney
@ 1999-04-29 0:00 0% ` bglbv
0 siblings, 0 replies; 123+ results
From: bglbv @ 1999-04-29 0:00 UTC (permalink / raw)
Matthew Heaney <matthew_heaney@acm.org> writes:
> > Also check out mpfun from netlib. It's in Fortran, but package
> > Interfaces.Fortran is your friend.
>
> Can you be more specific about the URLs? What is netlib, and where is
> it?
Sorry, I compose my news postings offline, which makes it a little
harder to check such things on the fly. I think the master WWW site
is at http://netlib.org (possibly with a leading www., but I seem
to recall that they don't follow that convention). Certainly there
are pointers to it at http://gams.nist.gov . There are also several
mirrors around the world.
^ permalink raw reply [relevance 0%]
* Re: Very big Integers
1999-04-24 0:00 5% ` bglbv
@ 1999-04-25 0:00 0% ` Matthew Heaney
1999-04-29 0:00 0% ` bglbv
0 siblings, 1 reply; 123+ results
From: Matthew Heaney @ 1999-04-25 0:00 UTC (permalink / raw)
bglbv@my-dejanews.com writes:
> Also check out mpfun from netlib. It's in Fortran, but package
> Interfaces.Fortran is your friend.
Can you be more specific about the URLs? What is netlib, and where is
it?
^ permalink raw reply [relevance 0%]
* Re: Very big Integers
@ 1999-04-24 0:00 5% ` bglbv
1999-04-25 0:00 0% ` Matthew Heaney
0 siblings, 1 reply; 123+ results
From: bglbv @ 1999-04-24 0:00 UTC (permalink / raw)
Samuel Mize <smize@imagin.net> writes:
> make it a new type instead of a subtype, i.e. make the declaration:
>
> type Big_Natural is range 0 .. 2**100;
>
> and see if it compiles.
Indeed, direct support for 100-bit integers is rare nowadays.
On some platforms, 128-bit floating point may come close to the
required 100 bits of mantissa. (In fact, on an IEEE machine it
should have slightly more than that. But the "100" probably wasn't
meant literally.)
> If not, you'll have to build your own type. There may be some
> huge-number packages around, check the repositories you can
> links to via http://www.adahome.com or http://www.acm.org/sigada .
Also check out mpfun from netlib. It's in Fortran, but package
Interfaces.Fortran is your friend.
^ permalink raw reply [relevance 5%]
* Re: identify floating-point types
1999-03-19 0:00 5% ` Nick Roberts
@ 1999-03-25 0:00 0% ` bglbv
0 siblings, 0 replies; 123+ results
From: bglbv @ 1999-03-25 0:00 UTC (permalink / raw)
"Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:
> Well, with some languages (notably C and C++), on some machines, there are
> multiple parameter (and memory format) conventions. But, I have to admit, I
> think, in practice, Fortran conventions tend to be pretty consistent, for
> any one particular architecture.
Except on Microsoft Windows platforms, where there seem to be as many
conventions as compiler vendors (except perhaps where DLLs are involved).
robert_dewar@my-dejanews.com wroteL
> |In article <7cpk9t$s5o$1@plug.news.pipex.net>,
> | "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
> |> In practise, you might need to check your Ada and Fortran
> |> compilers' documentation carefully, to see whether the
> |> types provided in Interfaces.Fortran do truly match the
> |> corresponding Fortran types (on some
> |> machines this will be a given thing, but not all).
> |
> |Nick why do you say this? Have you run into an Ada 95
> |compiler where the types did not match? If so, it would
> |be a clear bug!
The types only have to match if the Fortran implementation used is
among those officially supported by the Ada implementation. There is
no requirement in the Ada standard for a compiler to interface
correctly with all conceivable Fortrans on the same platform.
Nick's advice to check the documentation and see if that combination
of compilers is supported is spot on. *If it is supported*, then
the types should of course match.
^ permalink raw reply [relevance 0%]
* Re: identify floating-point types
1999-03-19 0:00 0% ` robert_dewar
@ 1999-03-19 0:00 5% ` Nick Roberts
1999-03-25 0:00 0% ` bglbv
0 siblings, 1 reply; 123+ results
From: Nick Roberts @ 1999-03-19 0:00 UTC (permalink / raw)
Well, with some languages (notably C and C++), on some machines, there are
multiple parameter (and memory format) conventions. But, I have to admit, I
think, in practice, Fortran conventions tend to be pretty consistent, for
any one particular architecture. There's no harm in checking to make
absolutely sure, though. (And, shocking as it may sound, compilers do have
bugs, occasionally ;-)
-------------------------------------
Nick Roberts
-------------------------------------
robert_dewar@my-dejanews.com wrote in message
<7csl7e$26b$1@nnrp1.dejanews.com>...
|In article <7cpk9t$s5o$1@plug.news.pipex.net>,
| "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
|> In practise, you might need to check your Ada and Fortran
|> compilers' documentation carefully, to see whether the
|> types provided in Interfaces.Fortran do truly match the
|> corresponding Fortran types (on some
|> machines this will be a given thing, but not all).
|
|Nick why do you say this? Have you run into an Ada 95
|compiler where the types did not match? If so, it would
|be a clear bug!
^ permalink raw reply [relevance 5%]
* Re: identify floating-point types
1999-03-17 0:00 7% ` identify floating-point types Nick Roberts
1999-03-18 0:00 7% ` Nick Roberts
@ 1999-03-19 0:00 0% ` robert_dewar
1999-03-19 0:00 5% ` Nick Roberts
1 sibling, 1 reply; 123+ results
From: robert_dewar @ 1999-03-19 0:00 UTC (permalink / raw)
In article <7cpk9t$s5o$1@plug.news.pipex.net>,
"Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
> In practise, you might need to check your Ada and Fortran
> compilers' documentation carefully, to see whether the
> types provided in Interfaces.Fortran do truly match the
> corresponding Fortran types (on some
> machines this will be a given thing, but not all).
Nick why do you say this? Have you run into an Ada 95
compiler where the types did not match? If so, it would
be a clear bug!
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
^ permalink raw reply [relevance 0%]
* Re: identify floating-point types
1999-03-17 0:00 7% ` identify floating-point types Nick Roberts
@ 1999-03-18 0:00 7% ` Nick Roberts
1999-03-19 0:00 0% ` robert_dewar
1 sibling, 0 replies; 123+ results
From: Nick Roberts @ 1999-03-18 0:00 UTC (permalink / raw)
Thinking about this a little more, you need to be careful that the type
'vector' matches the corresponding Fortran vector (array) type. I suspect
you will need the two separate packages, with:
for real'Size use Interfaces.Fortran.Real'Size;
in one, and:
for real'Size use Interfaces.Fortran.Double_Precision'Size;
in the other, to ensure that a change of representation has not been done.
In addition, I think you will need:
pragma Convention(Fortran,real);
pragma Convention(Fortran,vector);
to (help) ensure these types are stored in the same format as their Fortran
counterparts.
Hope this also helps!
-------------------------------------
Nick Roberts
-------------------------------------
^ permalink raw reply [relevance 7%]
* Re: identify floating-point types
[not found] <e4uxdrff6+w9@nedcu4>
@ 1999-03-17 0:00 7% ` Nick Roberts
1999-03-18 0:00 7% ` Nick Roberts
1999-03-19 0:00 0% ` robert_dewar
0 siblings, 2 replies; 123+ results
From: Nick Roberts @ 1999-03-17 0:00 UTC (permalink / raw)
Theoretically, you should be able to use the types Interfaces.Fortran.Real
and Interfaces.Fortran.Double_Precision, and these should ensure that your
Ada code uses the correct types to interface to the Fortran library (see
RM95 B.5).
In practise, you might need to check your Ada and Fortran compilers'
documentation carefully, to see whether the types provided in
Interfaces.Fortran do truly match the corresponding Fortran types (on some
machines this will be a given thing, but not all).
Otherwise, I think your approach is basically sound. One useful refinement
might be:
is_single: constant boolean:=
use_BLAS and
real'digits <= Interfaces.Fortran.Real'digits;
is_double: constant boolean:=
use_BLAS and
not is_single and
real'digits <= Interfaces.Fortran.Double_Precision'digits;
This will (theoretically) allow a wider choice of floating-point types to be
passed into instantiations of the generic package.
An alternative idea would be to define two different generic packages,
perhaps named 'Single_Precision_Sparse_Vector_Functions' and
'Double_Precision_Sparse_Vector_Functions' (or maybe something slightly more
succinct!), and have the 'real' generic parameter derived as appropriate,
e.g.:
generic
type real is new Interfaces.Fortran.Real;
type index is range <>;
type vector is array(index range <>) of real;
package Single_Precision_Sparse_Vector_Functions is
...
and:
generic
type real is new Interfaces.Fortran.Double_Precision;
type index is range <>;
type vector is array(index range <>) of real;
package Double_Precision_Sparse_Vector_Functions is
...
These would compel the users of the packages to use types derived from (and
therefore precision-compatible with) the Fortran types (or, more likely, to
use the Fortran types directly). You would then be spared, in the bodies of
these packages, the blight of 'if ... then .. else' statements all over the
place.
As an additional idea, you might be better off putting:
use_BLAS: constant boolean:= true; -- use Basic Linear Algebra Subroutines
in as one of the generic parameters, so that users of the package can choose
not to use BLAS, if they wish. Taking this a step further, you could define
two (or three) packages, one (or two) using BLAS and one not (thus avoiding
more 'if ... then ... else' blight).
(If you wanted to get _really_ fancy, you could declare an abstract tagged
type, say 'Abstract_Vector', with abstract operations corresponding to the
vector operations you require, and then derive two (concrete) types from
this abstract type, one implementing the operations using BLAS, and one not.
But this would _probably_ be slight overkill ;-)
You may also wish to investigate the optimisation possibilities of using the
Optimize (RM95 2.8) and Suppress (RM95 11.5) pragmas, and any other
optimisation facilities that may be provided by your compiler.
Hope this helps.
-------------------------------------
Nick Roberts
-------------------------------------
^ permalink raw reply [relevance 7%]
* Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP
1998-04-30 0:00 6% ` Robert I. Eachus
@ 1998-05-01 0:00 0% ` Fergus Henderson
1 sibling, 0 replies; 123+ results
From: Fergus Henderson @ 1998-05-01 0:00 UTC (permalink / raw)
eachus@spectre.mitre.org (Robert I. Eachus) writes:
>In article <6hvm8k$t3l$1@news.hal-pc.org> Jonathan Guthrie <jguthrie@brokersys.com> writes:
>
> > How does the Ada compiler implemetor know what C compiler is used in
> > that "particular environment in which the compiler operates"?
> > Telepathy?
>
> No, by the name used in the pragma. The conventions Ada, Intrinsic,
>Fortran, C, and COBOL are defined in the RM, as are the packages
>Interfaces.C, Interfaces.COBOL, and Interfaces.Fortran. Compilers are
>allowed to add support for other languages, and in the particular case
>mentioned above, they would choose one C compiler to correspond to the
>convention C, and others could be named Gcc, VisualC, etc. In practice,
>the compiler that corresponds to C is the one used to compile the OS.
It would also be easy to implement a command-line option or configuration
pragma to override the default meaning for the "C" convention
(e.g. by default "C" might mean "VisualC", but the user could
override it so that "C" would mean "gcc").
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
^ permalink raw reply [relevance 0%]
* Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP
@ 1998-04-30 0:00 6% ` Robert I. Eachus
1998-04-30 0:00 0% ` Urgent question: malloc and ada Larry Kilgallen
1998-05-01 0:00 0% ` Urgent question: malloc and ada...READ/NEW/FOLLOWUP Fergus Henderson
1 sibling, 1 reply; 123+ results
From: Robert I. Eachus @ 1998-04-30 0:00 UTC (permalink / raw)
In article <6hvm8k$t3l$1@news.hal-pc.org> Jonathan Guthrie <jguthrie@brokersys.com> writes:
> How does the Ada compiler implemetor know what C compiler is used in
> that "particular environment in which the compiler operates"?
> Telepathy?
No, by the name used in the pragma. The conventions Ada, Intrinsic,
Fortran, C, and COBOL are defined in the RM, as are the packages
Interfaces.C, Interfaces.COBOL, and Interfaces.Fortran. Compilers are
allowed to add support for other languages, and in the particular case
mentioned above, they would choose one C compiler to correspond to the
convention C, and others could be named Gcc, VisualC, etc. In practice,
the compiler that corresponds to C is the one used to compile the OS.
--
Robert I. Eachus
with Standard_Disclaimer;
use Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...
^ permalink raw reply [relevance 6%]
* Re: Urgent question: malloc and ada...
1998-04-30 0:00 6% ` Robert I. Eachus
@ 1998-04-30 0:00 0% ` Larry Kilgallen
0 siblings, 0 replies; 123+ results
From: Larry Kilgallen @ 1998-04-30 0:00 UTC (permalink / raw)
In article <EACHUS.98Apr30171942@spectre.mitre.org>, eachus@spectre.mitre.org (Robert I. Eachus) writes:
> No, by the name used in the pragma. The conventions Ada, Intrinsic,
> Fortran, C, and COBOL are defined in the RM, as are the packages
> Interfaces.C, Interfaces.COBOL, and Interfaces.Fortran. Compilers are
> allowed to add support for other languages, and in the particular case
> mentioned above, they would choose one C compiler to correspond to the
> convention C, and others could be named Gcc, VisualC, etc. In practice,
> the compiler that corresponds to C is the one used to compile the OS.
I find it strange that even in comp.lang.ada a distinguished contributor
would express the assumption that the operating system was written in C.
Larry Kilgallen
^ permalink raw reply [relevance 0%]
* Multilanguage Interfacing
@ 1998-03-01 0:00 6% Andy Willey
0 siblings, 0 replies; 123+ results
From: Andy Willey @ 1998-03-01 0:00 UTC (permalink / raw)
I am attempting to perform the following simple test to check out the
Ada-FORTRAN interface. I wish to call the FORTRAN routine "output" from
an Ada main routine "test". Using g77, I have compiled the FORTRAN
routine below and created a file called "output.o". Using GNAT, I have
compiled and bound the Ada main program below and created the file
"test.ali". Up to this point, no problems. However, when I attempt to
link the ada and FORTRAN together using gnatlink test.ali output.o, the
linker complains about unknown symbols in the FORTRAN module. Can
anyone explain why this isn't working? Thanks in advance.
-- Andy Willey, willeya@dr-inc.com
Summary of actions:
g77 -c output.f
gcc -c test.adb
gnatbind test.ali
gnatlink test.ali output.o
Ada Main routine contained in file test.adb:
with Interfaces.Fortran;
use Interfaces.Fortran;
procedure test is
procedure output; --Declare FORTRAN routine to be called
pragma Import (Fortran, output, "output_"); --This may be the problem
begin
output; --Call FORTRAN routine
end test;
FORTRAN Routine contained in file output.f:
subroutine output
write(05,*)'Test Successful!'
return
end
**End of message**
^ permalink raw reply [relevance 6%]
* Re: Ada-FORTRAN Interfacing
@ 1998-02-25 0:00 6% ` Laurent Guerby
0 siblings, 0 replies; 123+ results
From: Laurent Guerby @ 1998-02-25 0:00 UTC (permalink / raw)
Andy Willey <willeya@dr-inc.com> writes:
> I am attempting to link Ada and FORTRAN modules together. I am using
> GNAT Ada and the GNU FORTRAN compiler. If anyone knows of any
> documentation or examples that specifically address the Ada-FORTRAN
> interface, please let me know.
Have a look in cs.nyu.edu:/pub/gnat/contrib, there is a full
binding for the LAPACK FORTRAN libraries, I think it has been tested out
with g77. Ada 95/Fortran interface is very easy, you just need to know
about the Convention pragma for arrays and look at Interfaces.FORTRAN
for the types to use. No pointer mess here ;-).
I know there are some quite active people doing Ada/FORTRAN things,
may be they don't read comp.lang.ada anymore?
> Thanks -- Andy
> willeya@dr-inc.com
--
Laurent Guerby <guerby@gnat.com>, Team Ada, Linux/GNU addict
"Use the Source, Luke. The Source will be with you, always (GPL)."
^ permalink raw reply [relevance 6%]
* Re: Is Interfaces.Fortran Mandatory or Optional?
1997-10-03 0:00 12% ` John Harbaugh
@ 1997-10-04 0:00 5% ` Robert A Duff
0 siblings, 0 replies; 123+ results
From: Robert A Duff @ 1997-10-04 0:00 UTC (permalink / raw)
In article <3435292A.39C2@boeing.com>,
John Harbaugh <johnh.s.harbaugh2@boeing.com> wrote:
>Robert A Duff wrote:
><snip>
>> See B.2(12,13). There's no requirement to support interface to any
>> particular language. It would be silly -- suppose there's no Fortran
>> compiler on some machine. Is the Ada compiler vendor supposed to write
>> a Fortran compiler?
>>
>B.2(12,13) is implementation advice, not a requirement. It seems rather
>obscure to conclude that an implementation, by not following the advice,
>is free to provide any, some, or none of the children of Ada.
Yes, I agree it's not clear. But what else could we do? Surely we
can't require interface to COBOL on machines that have no COBOL
compiler. Perhaps it would have been more honest to put Annex B in the
"Specialized Needs (ie optional) Annex" category.
>... Too bad
>the RM is not a forthright in this matter as it is say in the
>dissallowal of decimal types.
True, but some would instead say, "Too bad decimal types are optional."
;-)
>Besides, I thought the RM defined an interface to an ISO-conformant
>object module.
I don't know of any ISO-defined object module format. As far as I can
tell, there are a bazillion "standard" object file formats, and another
bazillion calling conventions, and some machines and OS's support some,
and some machines and OS's support others. Please tell me I'm wrong:
I'd love to see some standardization in this area, but surely it's not
easy: an interface to another language involves calling conventions, and
calling conventions depend on the machine architecture (eg how many
registers are there, and what sort of instructions are they allowed in
and so forth).
>... This does not imply that the implementor provide
>other-language compilers. Is it not the case that C++ was not included
>in Annex B because it is not yet an ISO standard?
That's part of it, but it's also the case that it's just hard to define
all the details. We didn't define an interface to Common Lisp,
either...
>> See also AARM-B.5(17.a), which points out the exact issue you're asking
>> about.
>
> 17.a Ramification: The means by which the Complex type is
>provided in Interfaces.Fortran creates a dependence of
>Interfaces.Fortran on Numerics.Generic_Complex_Types (see G.1.1). This
>dependence is intentional and unavoidable, if the Fortran-compatible
>Complex type is to be useful in Ada code without duplicating facilities
>defined elsewhere.
>
>You're right, this does capture the issue. It does not, IMHO, resolve
>the issue.
OK, so what should we have done instead? Require that compilers that
support interface-to-Fortran also support annex G? No, that's overkill.
Require all Ada compilers to support interface to Fortran? No, that
doesn't make sense if there's no Fortran compiler for that target.
(Remember, we could be talking about some embedded system, here.)
Require that interface-to-fortran be supported if there *is* a Fortran
compiler? No, that makes no sense -- suppose I write an Ada compiler
for machine X, and there's no Fortran compiler, but then 6 months later
somebody writes a Fortran compiler. Is my Ada compiler correct for 6
months, and then somehow magically becomes incorrect because somebody
(perhaps I've never heard of) wrote a Fortran compiler? Does it matter
whether or not that Fortran compile is widely used?
Just what do you think the Ada standard ought to have said in this area?
>Gripeingly yours (and thanks for your response),
You're welcome, I'm sure.
- Bob
^ permalink raw reply [relevance 5%]
* Re: Is Interfaces.Fortran Mandatory or Optional?
1997-10-02 0:00 6% ` Robert A Duff
@ 1997-10-03 0:00 12% ` John Harbaugh
1997-10-04 0:00 5% ` Robert A Duff
0 siblings, 1 reply; 123+ results
From: John Harbaugh @ 1997-10-03 0:00 UTC (permalink / raw)
Robert A Duff wrote:
<snip>
> See B.2(12,13). There's no requirement to support interface to any
> particular language. It would be silly -- suppose there's no Fortran
> compiler on some machine. Is the Ada compiler vendor supposed to write
> a Fortran compiler?
>
B.2(12,13) is implementation advice, not a requirement. It seems rather
obscure to conclude that an implementation, by not following the advice,
is free to provide any, some, or none of the children of Ada. Too bad
the RM is not a forthright in this matter as it is say in the
dissallowal of decimal types.
Besides, I thought the RM defined an interface to an ISO-conformant
object module. This does not imply that the implementor provide
other-language compilers. Is it not the case that C++ was not included
in Annex B because it is not yet an ISO standard?
> See also AARM-B.5(17.a), which points out the exact issue you're asking
> about.
17.a Ramification: The means by which the Complex type is
provided in Interfaces.Fortran creates a dependence of
Interfaces.Fortran on Numerics.Generic_Complex_Types (see G.1.1). This
dependence is intentional and unavoidable, if the Fortran-compatible
Complex type is to be useful in Ada code without duplicating facilities
defined elsewhere.
You're right, this does capture the issue. It does not, IMHO, resolve
the issue.
>
> A compiler might support interface to Fortran, and support just that
> portion of Annex G that is needed. For example, it might support the
> Generic_Complex_Types thing, but disobey the strict accuracy
> requirements of Annex G.
>
> But that's all just legalistic mumbo-jumbo. If your machine supports
> Fortran (as many do ;-)), and you want it, then gripe at your Ada
> compiler vendor until they support interface to Fortran, and support it
> well. In practise, it's not really an RM issue.
>
> - Bob
Gripeingly yours (and thanks for your response),
- John
^ permalink raw reply [relevance 12%]
* Is Interfaces.Fortran Mandatory or Optional?
@ 1997-10-02 0:00 13% John Harbaugh
1997-10-02 0:00 6% ` Robert A Duff
0 siblings, 1 reply; 123+ results
From: John Harbaugh @ 1997-10-02 0:00 UTC (permalink / raw)
RM 1.1.2 identifies Annex B as part of the core language, and Annex G as
a Specialized Needs Annex. Furthermore
17 All implementations shall conform to the core language. In
addition, an
implementation may conform separately to one or more Specialized Needs
Annexes.
RM B.5 (mandatory) specifies Interfaces.Fortran as
4 with Ada.Numerics.Generic_Complex_Types; -- see G.1.1
pragma Elaborate_All(Ada.Numerics.Generic_Complex_Types);
package Interfaces.Fortran is ...
My question is: How can an implementation claim to support Annex B if it
does not also support Annex G?
Any clarification would be greatly appreciated.
- John
^ permalink raw reply [relevance 13%]
* Re: Is Interfaces.Fortran Mandatory or Optional?
1997-10-02 0:00 13% Is Interfaces.Fortran Mandatory or Optional? John Harbaugh
@ 1997-10-02 0:00 6% ` Robert A Duff
1997-10-03 0:00 12% ` John Harbaugh
0 siblings, 1 reply; 123+ results
From: Robert A Duff @ 1997-10-02 0:00 UTC (permalink / raw)
In article <3433C603.4404@boeing.com>,
John Harbaugh <johnh.s.harbaugh2@boeing.com> wrote:
>My question is: How can an implementation claim to support Annex B if it
>does not also support Annex G?
See B.2(12,13). There's no requirement to support interface to any
particular language. It would be silly -- suppose there's no Fortran
compiler on some machine. Is the Ada compiler vendor supposed to write
a Fortran compiler?
See also AARM-B.5(17.a), which points out the exact issue you're asking
about.
A compiler might support interface to Fortran, and support just that
portion of Annex G that is needed. For example, it might support the
Generic_Complex_Types thing, but disobey the strict accuracy
requirements of Annex G.
But that's all just legalistic mumbo-jumbo. If your machine supports
Fortran (as many do ;-)), and you want it, then gripe at your Ada
compiler vendor until they support interface to Fortran, and support it
well. In practise, it's not really an RM issue.
- Bob
^ permalink raw reply [relevance 6%]
* Regarding: Extracting contents of binary data files
[not found] <342eedac.49311445@newsbeta.alt.net>
@ 1997-09-29 0:00 5% ` Anonymous
0 siblings, 0 replies; 123+ results
From: Anonymous @ 1997-09-29 0:00 UTC (permalink / raw)
On Sun, 28 Sep 1997 05:45:30 GMT, andy.cornell.nospam@ibm.net wrote:
> Hi:
>
> I need to extract the contents of some packed binary files (WMO GRIB
> files, to be exact). The data items are contained in a (big-endian)
> continuous stream of bits (no unused bits between data items). The
> number of bits per item doesn't vary within a file, but varies from
> file to file, depending on precision required. The data items are
> unsigned integers, which get converted back to the original real
> values using reference values contained in the header portion of the
> file. The start of the data stream is byte-aligned (I think that's the
> correct terminology), but obviously the following data item's
> alignment with byte boundaries varies.
>
> I have a Fortran routine which unpacks these files; it reads the
> entire file into an integer array, then performs bit-shift operations
> (IAND, IOR, ISHFT) on bytes to extract and byte-align the data.
>
> My questions are:
> 1) Is this the best approach using Ada?
> 2) If so, how do I do the bit-shifting in Ada?
> 3) Are there existing Ada library routines available to do this?
>
> I am using GNAT 3.09 OS/2 (I'll upgrade soon). I am a novice
> programmer (one year of university CS 4 years ago) who is new to Ada;
> I discovered it while reading McConnell's "Code Complete" from
> Microsoft Press. I like what I've seen of Ada so far.
>
> Thanks in advance.
>
> Andy Cornell
> andy dot cornell at ibm dot net
>
> P.S. I'd like to stick with portable solutions as I eventually plan to
> get a big-endian UN*X box.
>
>
You have some options. If you're happy with the FORTRAN routine, why not
keep it and call it from Ada? GNAT provides package Interfaces.Fortran
for this purpose.
If you want to write it in Ada, modular types provide for bitwise
logical operations. The modular types defined in package Interfaces also
have shift operations defined for them. So you could read the stream a
byte at a time and use these operations to extract the bit-packed data.
Finally, you might be able to use representation clauses to let you read
all the data with a single operation, and have the compiler figure out
how to extract the individual items. GNAT is pretty good about letting
you have components in records that are not aligned on byte boundaries.
Jeff Carter PGP:1024/440FBE21
My real e-mail address: ( carter @ innocon . com )
"Illegitimate-faced bugger-folk!"
Monty Python & the Holy Grail
--
Jeff Carter PGP:1024/440FBE21
"Illegitimate-faced bugger-folk!"
Monty Python & the Holy Grail
^ permalink raw reply [relevance 5%]
* Re: VMS to Unix (was: Is there a Fortran to Ada translator)
1997-02-17 0:00 0% ` Mats Weber
@ 1997-02-26 0:00 5% ` Oliver Kellogg
0 siblings, 0 replies; 123+ results
From: Oliver Kellogg @ 1997-02-26 0:00 UTC (permalink / raw)
Thanks for your comments Robert, Mats. I can see your point.
Frustrated by the permanent necessity of type casting I have
given up using Interfaces.Fortran altogether -- at the price of
forsaking absolute portability to other systems (it so happens that in
my case, Fortran_Integer is the same size as Integer.)
--Oliver
^ permalink raw reply [relevance 5%]
* importing fortran routines to GNAT
@ 1997-02-21 0:00 6% Pasi J. Hakala
0 siblings, 0 replies; 123+ results
From: Pasi J. Hakala @ 1997-02-21 0:00 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 986 bytes --]
Hi!
I'm a sworn FORTRAN-programmer finally trying to learn a more
advanced language (ADA). Now, I still have lots of fortran
subroutines that I want to use, but somehow all the information
on how to do that in GNAT (3.05 I think) doesn't seem to apply
to me... :(
I've attached two files to this message: amain.adb is a
very simple main program that calls subsum.f (an even more simple
fortran subroutine). Now, HOW CAN I MAKE THE ADA MAIN
PROGRAM TO SEE THE SUBROUTINE???!!!
Here's what I've done (This is under OS/2 with g77, gcc 2.7... and
emx 0.9c):
- gcc -c amain.adb (no complaints)
- g77 -c subsum.f (no complaints)
- gnatbind amain.ali (no complaints)
- gnatlink amain.ali subsum.o
which results in 'cannot find object _subsum etc....
So can please someone help a poor astronomer on a way from
fortran to ADA....or otherwise I'll stick to fortran for
another Hubble-time......
Cheers, Pasi
[-- Attachment #2: amain.adb --]
[-- Type: text/plain, Size: 489 bytes --]
with Text_Io; use Text_Io;
with Interfaces.Fortran; use Interfaces.Fortran;
procedure Amain is
package Int_Io is new Integer_IO (Integer); use Int_Io;
package Flt_Io is new Float_IO (Float); use Flt_Io;
procedure subsum(In1 : in Real; In2 : in Real ; Outsum : out Real);
pragma import(Fortran,subsum);
i1,i2,ou : Real;
begin
ou:=0.0;
i1:=1.0;
i2:=2.0;
--
-- Call the imported fortran routine
--
subsum(i1,i2,ou);
New_Line;
Put(Float(ou));
end;
\x1a
[-- Attachment #3: subsum.f --]
[-- Type: text/plain, Size: 114 bytes --]
SUBROUTINE SUBSUM(IN1,IN2,OUT)
REAL IN1,IN2,OUT
C
OUT=IN1+IN2
RETURN
END
\x1a
^ permalink raw reply [relevance 6%]
* Re: VMS to Unix (was: Is there a Fortran to Ada translator)
1997-02-16 0:00 6% ` Oliver Kellogg
1997-02-17 0:00 0% ` Mats Weber
@ 1997-02-17 0:00 5% ` Robert Dewar
1 sibling, 0 replies; 123+ results
From: Robert Dewar @ 1997-02-17 0:00 UTC (permalink / raw)
Oliver asks
<<Talking of Fortran, how come the types Fortran_Integer, Real, Complex
etc. in package Interfaces.Fortran are derived types not subtypes?
It seems to me this unnecessarily complicates integration of Fortran and
Ada code.>>
This would introduce nasty implementation dependencies, since of course
in different implementations the base types would differ, so on one
implementation you might be able to assign Fortran_Integer to Integer
without a conversion and on another you would not be able to.
The extra complication introduced by the derived types is precisely
what is needed to ensure proper portability, which is the whole idea
of this interface package.
^ permalink raw reply [relevance 5%]
* Re: VMS to Unix (was: Is there a Fortran to Ada translator)
1997-02-16 0:00 6% ` Oliver Kellogg
@ 1997-02-17 0:00 0% ` Mats Weber
1997-02-26 0:00 5% ` Oliver Kellogg
1997-02-17 0:00 5% ` Robert Dewar
1 sibling, 1 reply; 123+ results
From: Mats Weber @ 1997-02-17 0:00 UTC (permalink / raw)
Oliver Kellogg wrote:
> Talking of Fortran, how come the types Fortran_Integer, Real, Complex
> etc. in package Interfaces.Fortran are derived types not subtypes?
Subtypes of what types ? The fact that they are derived from
Standard.Integer, Standard.Float, etc. in GNAT is just because they
happen to have the same ranges.
It could very well be that on an implementation, a Fortran integer is 32
bits and an Ada standard.integer is 64 bits.
In the standard, they are given as
type Fortran_Integer is range <implementation defined>;
and GNAT chose to derive them from the standard types instead of writing
type Fortran_Integer is range Integer'First .. Integer'Last;
^ permalink raw reply [relevance 0%]
* Re: VMS to Unix (was: Is there a Fortran to Ada translator)
@ 1997-02-16 0:00 6% ` Oliver Kellogg
1997-02-17 0:00 0% ` Mats Weber
1997-02-17 0:00 5% ` Robert Dewar
0 siblings, 2 replies; 123+ results
From: Oliver Kellogg @ 1997-02-16 0:00 UTC (permalink / raw)
Talking of Fortran, how come the types Fortran_Integer, Real, Complex
etc. in package Interfaces.Fortran are derived types not subtypes?
It seems to me this unnecessarily complicates integration of Fortran and
Ada code.
Oliver Kellogg
Munich, Bavaria
^ permalink raw reply [relevance 6%]
* Fortran to call Ada
@ 1996-06-27 0:00 5% Peter Hermann
0 siblings, 0 replies; 123+ results
From: Peter Hermann @ 1996-06-27 0:00 UTC (permalink / raw)
I would be grateful if somebody could inform me about experiences:
A large Fortran-system to call a subsystem written in Ada.
The main program should be (must be) Fortran due to several reasons.
My own experiences, very short:
Experimenting with GNAT, I managed to produce an executable
on SGI with the successful link step done by
"f77 *.o libgnat_all_gathered_on_my_own.a"
(this did not work under DECalphaOSF/1, however).
gnatlink made problems, too.
All the fortran types offered in package interfaces.fortran
(except complex) were in the param list
but i had a couple of incompatibilies, presumably in the
parameter handling of native SGI and gcc.
Some worked, some did not, especially when returning to the
calling Fortran routine.
--
Peter Hermann Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)
^ permalink raw reply [relevance 5%]
* Re: Gnat 2.06 Ada95 (unix) File format????
@ 1996-06-27 0:00 5% ` Peter Hermann
0 siblings, 0 replies; 123+ results
From: Peter Hermann @ 1996-06-27 0:00 UTC (permalink / raw)
Robert Dewar (dewar@cs.nyu.edu) wrote:
: strings and passing them by value), that for 3.06 we have decided to abandon
: the absolute guarantee of Ada-C callings sequence compatibility by default
: for this particular case.
this is justified, imho.
At interfaces fortran/ada or c/ada I would restrict myself to
the standard types offered in the packages interfaces.<language>
if ever possible.
--
Peter Hermann Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)
^ permalink raw reply [relevance 5%]
* Aggregate assignment problem with gnat under irix
@ 1996-05-31 0:00 5% Ullar Kask
0 siblings, 0 replies; 123+ results
From: Ullar Kask @ 1996-05-31 0:00 UTC (permalink / raw)
Hello,
I am doing numerical simulations using Ada and encoutered a problem with
aggregate assignment. The same type of statement, viz.,
A.all := (others => (others => 0.0));
where A.all is an NxN array (declared as unconstrained), works great in simple
procedures but fails in a task body. I don't understand what may be
the reason.
To be more specific, consider the following piece of code (compiles cleanly
with irix5.3 binary distribution of gnat 3.04 under irix5.2):
--------------------------------------------------------------------------------
with Ada.Text_IO, Interfaces.Fortran, Ada.Exceptions;
use Ada.Text_IO;
procedure Aggr_Tst is
subtype Real is Interfaces.Fortran.Real;
type Matrix_Type is array (Integer range <>, Integer range <>) of Real;
pragma Convention( Fortran, Matrix_Type);
type Matrix_Type_Access is access Matrix_Type;
type Grid_Type is (COARSE, MEDIUM, FINE);
Lhs : array (Grid_Type) of Matrix_Type_Access;
Grid_Length : array (Grid_Type) of Positive;
Grid : Grid_Type;
task Some_Task is
entry Entry_Point( G : in Grid_Type);
end Some_Task;
task body Some_Task is
Grid : Grid_Type;
begin
accept Entry_Point( G : in Grid_Type) do
Grid := G;
end Entry_Point;
--
-- Some work is being done here with Lhs(Grid).all
-- After that, try to initialize it again:
begin
-- The following statement raises STORAGE_ERROR:
Lhs(Grid).all := (others => (others => 0.0));
-- So does this:
-- Lhs(Grid).all := (Lhs(Grid).all'RANGE(1) =>
-- (Lhs(Grid).all'RANGE(2) => 0.0));
-- And this:
-- Lhs(Grid).all := (-Grid_Length(Grid) .. Grid_Length(Grid) =>
-- (-Grid_Length(Grid) .. Grid_Length(Grid) => 0.0));
-- Only the following double-loop does the job:
-- for I in Lhs(Grid).all'RANGE(1) loop
-- for J in Lhs(Grid).all'RANGE(2) loop
-- Lhs(Grid)(I,J) := 0.0;
-- end loop;
-- end loop;
exception
when O: others =>
Put_Line( "***Lhs initialization failed!*** Exception " &
Ada.Exceptions.Exception_Name(O) & " raised in task body.");
raise;
end;
Put_Line( "Lhs initialized again in task body.");
end Some_Task;
begin
-- Some values assigned to Grid and Grid_Length(Grid):
Grid := COARSE;
Grid_Length(Grid) := 100;
-- Allocate matrix:
Lhs(Grid) := new Matrix_Type(-Grid_Length(Grid) .. Grid_Length(Grid),
-Grid_Length(Grid) .. Grid_Length(Grid));
-- Initialize matrix:
begin
Lhs(Grid).all := (others => (others => 0.0)); -- This works fine
exception -- No exceptions raised here
when Q: others =>
Put_Line( "***Lhs initialization failed!*** Exception " &
Ada.Exceptions.Exception_Name(Q) & " raised in main procedure");
raise;
end;
Put_Line( "Lhs initialized in main procedure.");
-- Do some work with the matrix:
Some_Task.Entry_Point( Grid);
end Aggr_Tst;
------------------------------END OF CODE SAMPLE--------------------------------
Has the STORAGE_ERROR raised in the task body (under irix) something to do
with the size of the task stack? How it happens that such an aggregate
assignment is possible outside a task body but fails inside?
Any comments on the issue are appreciated!
Thanks a lot!
================================================================================
�llar Kask
Center for Relativity, University of Texas, Austin
email: ullar@einstein.ph.utexas.edu
ph. (512) 471-5905
http://wwwrel.ph.utexas.edu/Members/ullar/
^ permalink raw reply [relevance 5%]
* Re: Using complex from interfaces.fortran.
1995-02-22 22:40 13% Using complex from interfaces.fortran Brian Hanson
@ 1995-02-28 22:21 12% ` Tucker Taft
0 siblings, 0 replies; 123+ results
From: Tucker Taft @ 1995-02-28 22:21 UTC (permalink / raw)
Brian Hanson (brh@cray.com) wrote:
: I was looking at the package Interfaces.Fortran. Suppose you want to work
: with complex numbers. There is a type defined in this package called Complex
: and you can do all the normal stuff with it but suppose you wish to output a
: complex number. How to do it?
: with Interfaces.Fortran; use Interfaces.fortran;
: with ada.text_io.complex_io;
: procedure test is
: package complex_io is new ada.text_io.complex_io
: (single_precision_complex_types);
: with complex_io;
^^^^ "use" presumably
: a, b, c: complex;
: begin
: a := (1.7, 2.8);
: b := (9.5, 6.2);
: c := a * b + complex'(2.3, 0.0);
: put(c);
: end;
: My expectation is that the put not compile because it expects the type
: single_precision_complex_types.complex and not the complex defined in
: fortran.
: Is this true.
Yes, that is your problem.
: ... If so, does it not make using complex from package fortran
: very awkward for io and functions like sin, cos which are also accessed
: via a generic package with a package parameter?
Yes, this seems like an unintended consequence of making
Interfaces.Fortran.Complex a derived type. A subtype would
probably have been better, though that would require the
user to do a "use type Interfaces.Fortran.Complex" rather
than a "use Interfaces.Fortran" to get direct visibility
to the operators (not so terrible IMHO). Oh well, you can't
win them all.
In any case, you can work around the problem in two ways.
One, insert an explicit conversion in the call on "Put", e.g.:
Put(Single_Precision_Complex_Types.Complex(C));
or two, avoid use of Interfaces.Fortran.Complex and instead
use Interfaces.Fortran.Single_Precision_Complex_Types.Complex
directly. In the latter case, you might want to locally
declare "Complex" to be a subtype of
Single_Precision_Complex_Types.Complex and then do a
"use type Complex;"
: -- Brian Hanson
: -- brh@cray.com
: ps. I attempted to try this with gnat 2.03 but got compile errors for
: the package instantiation. So I do not know if it is gnat that is wrong
: or my program that is wrong.
The instantiation looks OK. GNAT might not fully support
formal package parameters yet; send a report to gnat-report
to find out for sure.
-Tucker Taft stt@inmet.com
^ permalink raw reply [relevance 12%]
* Using complex from interfaces.fortran.
@ 1995-02-22 22:40 13% Brian Hanson
1995-02-28 22:21 12% ` Tucker Taft
0 siblings, 1 reply; 123+ results
From: Brian Hanson @ 1995-02-22 22:40 UTC (permalink / raw)
I was looking at the package Interfaces.Fortran. Suppose you want to work
with complex numbers. There is a type defined in this package called Complex
and you can do all the normal stuff with it but suppose you wish to output a
complex number. How to do it?
with Interfaces.Fortran; use Interfaces.fortran;
with ada.text_io.complex_io;
procedure test is
package complex_io is new ada.text_io.complex_io
(single_precision_complex_types);
with complex_io;
a, b, c: complex;
begin
a := (1.7, 2.8);
b := (9.5, 6.2);
c := a * b + complex'(2.3, 0.0);
put(c);
end;
My expectation is that the put not compile because it expects the type
single_precision_complex_types.complex and not the complex defined in
fortran.
Is this true. If so, does it not make using complex from package fortran
very awkward for io and functions like sin, cos which are also accessed
via a generic package with a package parameter?
-- Brian Hanson
-- brh@cray.com
ps. I attempted to try this with gnat 2.03 but got compile errors for
the package instantiation. So I do not know if it is gnat that is wrong
or my program that is wrong.
--
----
-- Brian Hanson
-- brh@cray.com
^ permalink raw reply [relevance 13%]
* Array mappings
@ 1994-12-10 20:55 4% ` Michael Feldman
0 siblings, 0 replies; 123+ results
From: Michael Feldman @ 1994-12-10 20:55 UTC (permalink / raw)
In article <3c4g1u$uh6@watnews1.watson.ibm.com>,
Norman H. Cohen <ncohen@watson.ibm.com> wrote:
>The way to use ISUB when passing PL/I arrays to Fortran (or, as it was
>called back then, FORTRAN) is to declare an ordinary array that is filled
>in column-major (i.e., as Fortran expects it). If, inisde the PL/I
>program, you want to view the data as arranged in row-major order, then
>declare an ISUB that creates a virtual transposed copy of the array.
^^^^^^^
OK, this makes it clear.
>It is the ordinary array that is passed to Fortran, so it is unnecessary
>to create a transposed copy of the array. (If the array is to be passed
>from one PL/I procedure to another, the ordinary array can be passed and
>the ISUB declaration repeated in the called procedure.)
Aha. This is nice stuff. Perhaps I moved to other things before this
was implemented (or at least well-known) in PL/I.
That this was implemented in PL/I in the mid-70's, or even earlier,
a fact presumably known to the Ada 83 designers, makes me even more
curious why a similar facility was not provided in Ada 83. pragma Interface
handles the subprogram interface but there is no corresponding way
to handle the data structure interface.
This is odd - Ada 93 deliberately leaves array mappings (like all
representations) unspecified, so (presumably) as to allow flexibility
in the implementations. Was a pragma equivalent to Convention thought
to be "feature overkill"?
Finally, even if it was not predefined, such an implementation-defined
pragma would have been legal. Given that there were quite a number of
implementation-defined pragmas in Ada 83 - including such things as
Export, to allow callbacks - why did not this one turn up. I am still
waiting for an implementer to say "we looked at that market carefully
and concluded it was not worth the trouble." Till then, I stick to
my conjecture that nobody really looked at all that Fortran and
thought about how to sell into that crowd.
It's water over the dam, of course, because of Interfaces.Fortran in
Ada 95. But will we see timely implementations of it (other than GNAT,
which supports it in version 2)?
Mike Feldman
^ permalink raw reply [relevance 4%]
* Re: Why don't large companies use Ada?
1994-12-04 22:39 6% ` Michael Feldman
@ 1994-12-06 3:29 0% ` Keith Thompson
1 sibling, 0 replies; 123+ results
From: Keith Thompson @ 1994-12-06 3:29 UTC (permalink / raw)
In <3btgfs$m8c@felix.seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes:
> Don't take this personally, but the "all you should..." attitude is, in
> my experience, quite typical of computer folks who don't understand, or
> don't want to understand, what it takes to get a customer to buy.
> They don't focus on making it easy for the customer, by _really_
> understanding the customer's needs and mentality.
I don't (fully) understand, but I'd like to; that's why I'm posting.
> >This should
> >be only a small fraction of the effort required to interface to Fortran
> >(for Ada, matching the types and writing the Interface pragmas; for
> >PL/I, ???). Could it be that the engineers were using this as an excuse
> >to stick with Fortran, or am I missing something?
>
> You hit the nail right on the head. Of course they were using it as an
> excuse. And IBM apparently did not understand the extent to which non-
> technical considerations affect a choice of language.
So an estimate of the actual impact should be based, not on the total
number of engineers who rejected PL/I because of the indexing problem,
but on the subset of that total who wouldn't have found some other excuse
to reject it. (I don't suppose anyone has any figures on this. 8-)})
> In my experience, interfacing between languages - certainly for the
> kind of fairly simple vector/matrix interfaces the typical Fortranner
> would use (the _subprograms_ aren't simple but the _interfaces_
> tend to be) - is, to a very large extent,a matter of getting the
> data structures to agree. I don't understand your "small fraction"
> assertion.
Interfacing is the easy part. I'm assuming that the bulk of the effort
is simply learning the other language; interfacing PL/I to Fortran isn't
even an issue if you're unwilling to use PL/I in the first place. For an
engineer who isn't primarily a programmer, but who has learned to use
Fortran as an engineering tool, learning another programming language
(PL/I, Ada, C, whatever) could be a significant obstacle, regardless
of how smoothly the two languages can be interfaced. The problem
(I'm guessing) isn't just "it indexes arrays backwards", but "it
isn't Fortran". (No offense to engineers; I'd rather run a Fortran
program written by an engineer that drive across a bridge designed by
a programmer 8-)}.)
Hmm. How difficult (or possible) would it be to create an Ada "thick
binding" interface to a Fortran library that handles the index swapping?
I suppose it depends on the Fortran library. Presumably a solution that
actually re-maps the arrays would be unacceptable due to performance
problems. Has anyone ever looked into this possibility, though?
Disclaimers: I've never used Fortran, beyond a few tiny test programs.
I've heard about these big Fortran libraries, but I know very little about
them. I've never used PL/I at all. I seldom use multidimensional arrays.
I probably don't know what I'm talking about; if I did, I'd probably be
on the other side of this discussion.
> That Interfaces.Fortran and Pragma Convention exist in Ada 9X tells me
> that _somebody_ is now taking this issue seriously. All the more support
> for my assertion that we should have taken it seriously 10 years ago.
I agree (I think) that adding these to Ada 9X is A Good Thing. Note that,
since Convention is a representation pragma, compilers will be required
to implement array re-mapping (transposition?) for type conversions:
type Ada_Array is array(1 .. 100, 1 .. 100) of Float;
type Fortran_Array is new Ada_Array;
pragma Convention(Fortran, Fortran_Array);
A: Ada_Array := ...;
F: Fortran_Array := Fortran_Array(A);
Implementers take note.
--
Keith Thompson (The_Other_Keith) kst@alsys.com
TeleSoft^H^H^H^H^H^H^H^H Alsys, Inc.
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
/user/kst/.signature: I/O error (core dumped)
^ permalink raw reply [relevance 0%]
* Re: Why don't large companies use Ada?
@ 1994-12-06 2:48 5% ` Michael Feldman
0 siblings, 0 replies; 123+ results
From: Michael Feldman @ 1994-12-06 2:48 UTC (permalink / raw)
In article <3c05t4$ceg@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>if you are writing PL/1, you use ISUB to swap indices of arrays automatically
>
But the IBM chap who posted a note about this pointed out that ISUB
in fact _transposes_ the array. That's expensive in both time and
space. In Ada, because the storage mapping is unspecified in the LRM,
an implementer can choose to go column-major if his target audience
is doing a bunch of Fortran interfacing.
Indeed, an implementation-dependent pragma could be used to let the
programmer inform the compiler that certain array types were to look
"Fortran-ish". This would all be perfectly legal, and - unless I am
missing something really fundamental - not terribly hard to implement.
Unhappily, no Ada implementer took advantage of this opportunity to
make Ada more Fortran-friendly. Happily, Ada 95 standardizes the
whole thing with Interfaces.Fortran.
Mike Feldman
^ permalink raw reply [relevance 5%]
* Re: Why don't large companies use Ada?
@ 1994-12-04 22:39 6% ` Michael Feldman
1994-12-06 3:29 0% ` Keith Thompson
0 siblings, 2 replies; 123+ results
From: Michael Feldman @ 1994-12-04 22:39 UTC (permalink / raw)
In article <D07zvq.L3p@alsys.com>, Keith Thompson <kst@alsys.com> wrote:
>In <3bo4il$3lb@felix.seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes:
>I'll take your word for this, but I still find it difficult to understand.
>If you're writing new PL/I or Ada code to interface to existing Fortran
>libraries, all you should need to do is swap the indices; there should
>be no need to physically transpose the arrays themselves.
Yes, that's true. The transposition is mental.
Don't take this personally, but the "all you should..." attitude is, in
my experience, quite typical of computer folks who don't understand, or
don't want to understand, what it takes to get a customer to buy.
They don't focus on making it easy for the customer, by _really_
understanding the customer's needs and mentality.
>This should
>be only a small fraction of the effort required to interface to Fortran
>(for Ada, matching the types and writing the Interface pragmas; for
>PL/I, ???). Could it be that the engineers were using this as an excuse
>to stick with Fortran, or am I missing something?
You hit the nail right on the head. Of course they were using it as an
excuse. And IBM apparently did not understand the extent to which non-
technical considerations affect a choice of language.
In my experience, interfacing between languages - certainly for the
kind of fairly simple vector/matrix interfaces the typical Fortranner
would use (the _subprograms_ aren't simple but the _interfaces_
tend to be) - is, to a very large extent,a matter of getting the
data structures to agree. I don't understand your "small fraction"
assertion.
There are big Fortran libraries out there (e.g. IMSL)
whose interfaces consist of a couple of arrays and (maybe) some
bounds parameters (which in "pure" Ada would be handled by
unconstrained array types). An engineer trying to use these
from PL/1 would have to keep all his arrays in transposed form,
which would make his new PL/1 code look pretty unintuitive -
what would naturally be a row suddenly becomes a column.
Why bother, if nobody is forcing you to use PL/1?
The Ada community could have observed this phenomenon, and gone
after those engineers with an Ada 83 equivalent of Interfaces.Fortran
and Pragma Convention. Nothing in LRM83 prevented an implementer from
doing it. To my knowledge, not one vendor thought all those engineers
in (say) the Fortran-dependent DoE labs were worth supporting.
My offer is still open: if _one_ implementer steps up and says "Mike, we
_did_ take a serious look at that community and our market studies
showed that it wouldn't pan out", and gave a reason or two, I'll
promise to get off the hobbyhorse.
That Interfaces.Fortran and Pragma Convention exist in Ada 9X tells me
that _somebody_ is now taking this issue seriously. All the more support
for my assertion that we should have taken it seriously 10 years ago.
Mike Feldman
^ permalink raw reply [relevance 6%]
* Re: Interfaces.Ada
1994-11-01 18:06 6% ` Interfaces.Ada Michael Feldman
1994-11-01 21:04 5% ` Interfaces.Ada Matt Kennel
@ 1994-11-03 11:15 6% ` Robert Dewar
1 sibling, 0 replies; 123+ results
From: Robert Dewar @ 1994-11-03 11:15 UTC (permalink / raw)
"Fortran generally requires parameters to be passed by reference"
a common myth, but one that has never been true, not even array parameters
are required to be passed by reference in Fortran.
In fact the Ada permission to pass composites either by copy or by
reference is conciously copied from the Fortran standard!
Back to GNAT and Fortran. The only piece of functionality that I see
missing is the columnwise arrays (which has nothing to do with either
pragma Import, or with Interfaces.Fortran, but rather with pragma
Convention applied to an array.
^ permalink raw reply [relevance 6%]
* Re: Interfaces.Ada
1994-11-01 21:04 5% ` Interfaces.Ada Matt Kennel
@ 1994-11-02 6:24 0% ` Tucker Taft
0 siblings, 0 replies; 123+ results
From: Tucker Taft @ 1994-11-02 6:24 UTC (permalink / raw)
In article <396agd$9bt@network.ucsd.edu>,
Matt Kennel <mbk@inls1.ucsd.edu> wrote:
>Michael Feldman (mfeldman@seas.gwu.edu) wrote:
>: >will work)? I am using Sun Sparc. Thank you.
>
>: I think Robert Dewar has commented on the best way (currently) to
>: interface Fortran programs to GNAT. Interfaces.Fortran, and especially
>: the data structures interface - which will provide column-mapped
>: multi-dimensional arrays, etc. simply has not been implemented yet.
>
>I've always wondered about one thing:
>
> When people make new langauges why do they implement the C storage
> layout for multi-dimensional arrays instead of that of Fortran? E.g.
> as it seems, Ada9x, Modula-3.
Note that Ada doesn't "implement the C storage layout" for
arrays. Ada 83 doesn't specify the order. However, implementors
naturally have chosen the layout implied by the way that
array aggregates are written, where the second index varies
fastest as you move through memory.
For example, in the following array aggregate:
((1,2,3), (4,5,6), (7,8,9))
One would naturally expect the second dimension to vary
fastest, by just looking at the syntax for the aggregate.
But to reiterate, there is nothing in Ada 83 that requires
a particular layout.
In Ada 9X, the Convention pragma may be used to specify
Fortran-style array layout.
Also, it is a bit funny to call the non-Fortran order the
"C storage layout" for multi-dimensional arrays. C was
certainly not the first language to vary the last dimension
fastest. Algol 60 used the non-Fortran order (or at least suggested
it in the same sense that Ada's array aggregate notation
suggests it). So it has a long history, though clearly not
as relevant a history as Fortran's choice to modern numerics.
It is also of course possible to simply reverse the indices
when defining and using a multidimensional array in an implementation
that has the non-Fortran order, so it doesn't seem like
an insurmountable barrier in any case.
> Given that most matrix algorithms are in Fortran why be backwards? (and
> ones in C usually use some sort of non-compatible dope-vector thing anyway
> because C doesn't have variable matrix sizes.)
Calling the non-Fortran order "backwards" reminds me of the
typical non-Britisher comment about the "backwards" nature
of the British drive-on-the-left rule ;-).
> Why not make the default just like Fortran? I don't think one way is
> particularly more "natural" than the other so now that Fortran chose one
> convention why not stay with it?
The array aggregate notation suggests that the non-Fortran order
is somewhat more natural in Ada.
> The only thing I can figure out is that it is a childish attitude
> like "bleah fortran sucks so we'll be different". I don't believe this
> is true so what is the real reason? Is it that compelling?
It didn't come out of any desire to be different. I believe it
was simply that Ada comes more from the Algol school of languages
than the Fortran school of languages.
>: Mike Feldman
>
>--
>-Matt Kennel mbk@inls1.ucsd.edu
>-Institute for Nonlinear Science, University of California, San Diego
>-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
>-*** lyapunov.ucsd.edu, username "anonymous".
-Tucker Taft stt@inmet.com
Intermetrics, Inc.
Cambridge, MA 02138
^ permalink raw reply [relevance 0%]
* Re: Interfaces.Ada
1994-11-01 18:06 6% ` Interfaces.Ada Michael Feldman
@ 1994-11-01 21:04 5% ` Matt Kennel
1994-11-02 6:24 0% ` Interfaces.Ada Tucker Taft
1994-11-03 11:15 6% ` Interfaces.Ada Robert Dewar
1 sibling, 1 reply; 123+ results
From: Matt Kennel @ 1994-11-01 21:04 UTC (permalink / raw)
Michael Feldman (mfeldman@seas.gwu.edu) wrote:
: >will work)? I am using Sun Sparc. Thank you.
: I think Robert Dewar has commented on the best way (currently) to
: interface Fortran programs to GNAT. Interfaces.Fortran, and especially
: the data structures interface - which will provide column-mapped
: multi-dimensional arrays, etc. simply has not been implemented yet.
I've always wondered about one thing:
When people make new langauges why do they implement the C storage
layout for multi-dimensional arrays instead of that of Fortran? E.g.
as it seems, Ada9x, Modula-3.
Given that most matrix algorithms are in Fortran why be backwards? (and
ones in C usually use some sort of non-compatible dope-vector thing anyway
because C doesn't have variable matrix sizes.)
Why not make the default just like Fortran? I don't think one way is
particularly more "natural" than the other so now that Fortran chose one
convention why not stay with it?
The only thing I can figure out is that it is a childish attitude
like "bleah fortran sucks so we'll be different". I don't believe this
is true so what is the real reason? Is it that compelling?
: Mike Feldman
--
-Matt Kennel mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-*** lyapunov.ucsd.edu, username "anonymous".
^ permalink raw reply [relevance 5%]
* Re: Interfaces.Ada
1994-10-31 15:33 6% Interfaces.Ada Kyongsuk Pace
@ 1994-11-01 18:06 6% ` Michael Feldman
1994-11-01 21:04 5% ` Interfaces.Ada Matt Kennel
1994-11-03 11:15 6% ` Interfaces.Ada Robert Dewar
0 siblings, 2 replies; 123+ results
From: Michael Feldman @ 1994-11-01 18:06 UTC (permalink / raw)
In article <9409317836.AA783621232@smtpgw.fnoc.navy.mil>,
Kyongsuk Pace <pacek@FNOC.NAVY.MIL> wrote:
>Let me try the same question again. The organization I work has tons of
>Fortran programs and we really need to have the interface capability
>between Fortran and Ada.
>
>I tried to use pragma import in GNAT to use some Fortran programs.
>However, pragma for Fortran is not implemented yet according to Robert
>Dewar. I got this response from Robert Dewar after I sent the question to
>gnat-report! I read about interfaces.Fortran in one of Mike Feldman's
>postings in info-Ada. Can you (Mike Feldman) tell me where I can get it
>and how to use it with GNAT (i.e., does it require any changes before it
>will work)? I am using Sun Sparc. Thank you.
I think Robert Dewar has commented on the best way (currently) to
interface Fortran programs to GNAT. Interfaces.Fortran, and especially
the data structures interface - which will provide column-mapped
multi-dimensional arrays, etc. simply has not been implemented yet.
I suggested to CLA readers that they look in RM9X 5.0 to see what
these language interfaces will look like in an implementation that
supports them fully. I did not (mean to) imply that GNAT was currently
supporting anything but C.
I am not at all familiar with GCC F77, so I'm not a good one to ask for
details on how to do the interfacing to GNAT (especially while we wait
for the full Interfaces.Fortran to be done). Robert Dewar has suggested
that the scalar data types are the same in all the GNU languages;
Fortran generally requires parameters to be passed by reference; typically
this has been done in Ada 83 by using the 'Address attribute to pass an
address from Ada to Fortran. (NOTE: an Ada access type is not
necessaily the same thing, as has been discussed at length here recently).
Handling arrays is something you'll have to look at closely, until there's
a full Interfaces.Fortran to make it easier.
If you are really hurting to get started, maybe the NYU folks can help, but
I'm hesitant to suggest this because they are up to their ears
finishing the compiler. Maybe Robert will comment again on CLA.
BTW - I've always advocated that each organization set up a small group
or even a single individual who becomes the local expert on language
interfacing, and that this group or person be tasked with writing
whatever interfacing "glue" is necessary to make the Ada side of the
interface as clean and clear as possible to the rest of the project.
Try to avoid distributing 'Address calls and suchlike throughout a
big program, for example - go through a project-specific interface
layer if need be. Do not assume that the performance hit will be
unacceptable.
Is there a CLA reader out there who has experience in interfacing
to Fortran?
Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman - chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University - Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet)
------------------------------------------------------------------------
Ada on the World-Wide Web: http://lglwww.epfl.ch/Ada/
------------------------------------------------------------------------
"Non illegitimi carborundum." (Don't let the bastards grind you down.)
------------------------------------------------------------------------
^ permalink raw reply [relevance 6%]
* Interfaces.Ada
@ 1994-10-31 15:33 6% Kyongsuk Pace
1994-11-01 18:06 6% ` Interfaces.Ada Michael Feldman
0 siblings, 1 reply; 123+ results
From: Kyongsuk Pace @ 1994-10-31 15:33 UTC (permalink / raw)
Let me try the same question again. The organization I work has tons of
Fortran programs and we really need to have the interface capability
between Fortran and Ada.
I tried to use pragma import in GNAT to use some Fortran programs.
However, pragma for Fortran is not implemented yet according to Robert
Dewar. I got this response from Robert Dewar after I sent the question to
gnat-report! I read about interfaces.Fortran in one of Mike Feldman's
postings in info-Ada. Can you (Mike Feldman) tell me where I can get it
and how to use it with GNAT (i.e., does it require any changes before it
will work)? I am using Sun Sparc. Thank you.
Susie Pace
=====================================================================
Kyongsuk Pace
Fleet Numerical Meteorology and
Oceanography Center pacek@fnoc.navy.mil
7 Grace Hopper Ave, stop 1 408-656-4367
Monterey, CA 93943-5501 fax:408-656-4489
=====================================================================
^ permalink raw reply [relevance 6%]
* Re: Interfaces.Fortran
1994-10-28 17:13 6% ` Interfaces.Fortran paus
@ 1994-10-30 17:19 5% ` Robert Dewar
0 siblings, 0 replies; 123+ results
From: Robert Dewar @ 1994-10-30 17:19 UTC (permalink / raw)
Well sure, it would be neater to say pragma Interface (Fortran, and we will
certainly put that in soon, but it probably has the same effect as
pragma Interface (C, so it's an elegance issue, not a functoinality issue).
Now of course pragma Convention (Fortran, arr), where arr is a multi
dimensional array is more significant, because that causes proper column
wise storage. We don't have that in GNAT et, but definitely plan to
implement it.
Finally pragma export is indeed useful, and is definitely high on our
priority list. The valuable feature is the ability to specify link names.
Right now, all library entities in GNAT are by default exported with their
default names (all lower case with periods replaced by __ (double underline).
From C you can of course use these names directly, not very elegant, but
it certainly works (we use this extensively in GNAT, writing typically)
#define Enter_Name sem_util__enter_name
so that we can from then on use the "proper" name in the C code, but it
would certainly be nicer to be able to give a clean link name, and we
definitely have plans to implement this!
Note that the version of GNAT about to be released *does* finally have
pragma Import for variables, which will be useful.
So I don't know quite what you were asking me if I was sure about, but I
hope the above answers your questions.
^ permalink raw reply [relevance 5%]
* Re: Interfaces.Fortran
1994-10-26 22:28 12% ` Interfaces.Fortran Robert Dewar
@ 1994-10-28 17:13 6% ` paus
1994-10-30 17:19 5% ` Interfaces.Fortran Robert Dewar
0 siblings, 1 reply; 123+ results
From: paus @ 1994-10-28 17:13 UTC (permalink / raw)
In article <38ml76$e28@gnat.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes:
>
> Second, pragma interface FOrtran is not implemented, but are you sure you
> need it! on most GCC targets it won't have any effect anyway.
>
Robert,
are you shure? I'm also missing pragma interface Fortran (and even more
pragma export). On all UNIX systems that I know there is no problem
interfacing gcc code with the code from a non-gcc Fortran compiler.
So, pragma interface Fortran would help to make the interfacing to
Fortran code more elegant and would help to avoid doing this via pragma
interface C.
Michael
--
|----------------------------------------------------------------------|
|Dipl.-Ing. Michael Paus (Member: Team Ada) |
|University of Stuttgart, Inst. of Flight Mechanics and Flight Control |
|Forststrasse 86, 70176 Stuttgart, Germany |
|Phone: (+49) 711-121-1434 FAX: (+49) 711-634856 |
|Email: Michael.Paus@ifr.luftfahrt.uni-stuttgart.de (NeXT-Mail welcome)|
^ permalink raw reply [relevance 6%]
* Re: Interfaces.Fortran
1994-10-26 15:40 12% Interfaces.Fortran Kyongsuk Pace
@ 1994-10-26 22:28 12% ` Robert Dewar
1994-10-28 17:13 6% ` Interfaces.Fortran paus
0 siblings, 1 reply; 123+ results
From: Robert Dewar @ 1994-10-26 22:28 UTC (permalink / raw)
First, the usual reminder, please at least copy questions about GNAT to
gnat-report if you want them seen and answered by members of the devlopment
team!
Second, pragma interface FOrtran is not implemented, but are you sure you
need it! on most GCC targets it won't have any effect anyway.
Third, interfaces.fortran is implemented, though untested, but it is
basically unnecessary in the GNAT environment on most targets.
One thing to understand about the interfaces packages is that they are
basically there to bridge the gap between language xyz data structures
and Ada data structures. Most of the time, in the GCC environment, no
such bridge is needed.
The best thing would be to send a message to gnat-report saying exactly
what you are interested in doing.
^ permalink raw reply [relevance 12%]
* Interfaces.Fortran
@ 1994-10-26 15:40 12% Kyongsuk Pace
1994-10-26 22:28 12% ` Interfaces.Fortran Robert Dewar
0 siblings, 1 reply; 123+ results
From: Kyongsuk Pace @ 1994-10-26 15:40 UTC (permalink / raw)
I tried to use pragma import in GNAT to use some Fortran programs.
However, pragma for Fortran is not implemented yet according to Robert
Dewar. I read about interfaces.Fortran in one of Mike Feldman's postings
in info-Ada. Can you tell me where I can get it and how to use it with
GNAT (i.e., does it require any changes before it will work)? I am using
Sun Sparc. Thank you.
Susie Pace
=====================================================================
Kyongsuk Pace
Fleet Numerical Meteorology and
Oceanography Center pacek@fnoc.navy.mil
7 Grace Hopper Ave, stop 1 408-656-4367
Monterey, CA 93943-5501 fax:408-656-4489
=====================================================================
^ permalink raw reply [relevance 12%]
* Re: Is C/C++ the future?
@ 1994-10-26 2:09 5% ` Michael Feldman
0 siblings, 0 replies; 123+ results
From: Michael Feldman @ 1994-10-26 2:09 UTC (permalink / raw)
In article <38k5dg$kko@source.asset.com>,
Michael M. Bishop <bishopm@source.asset.com> wrote:
>It may certainly be true that most Ada projects (certainly large ones)
>require interfaces to external code written in other languages. You're
>also correct in saying that this condition does not make Ada an
>incomplete language. In fact, I believe that the ability to easily
>integrate code written in other languages with Ada code is one of the
>big strengths of Ada. It's vitally important to me because I'm
>developing a Motif application in Ada.
That you are interfacing to Motif code written in C is not due to Ada's
being an incomplete _language_, only due to the fact that not every
library in the world has been (re-)written in Ada.
Indeed, it would be quite foolish to rewrite every bit of existing
library code in Ada - why re-invent the wheel? I'm at a loss to
understand why anyone would trash Ada because the Motif people
chose to write their stuff in C? Ada 83 compilers provide pretty good,
pretty standard, interfaces to other languages, and Ada 9X is improving
that substantially.
Take a look at the niceties in Interfaces.C, Interfaces.Cobol, and
Interfaces.Fortran.
It has always baffled me why anyone would consider the desire (or
need) to link to existing libraries, whatever their language of origin,
as a _disadvantage_ of Ada. Bizarre.
Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman - chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University - Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet)
------------------------------------------------------------------------
Ada on the World-Wide Web: http://lglwww.epfl.ch/Ada/
------------------------------------------------------------------------
"Non illegitimi carborundum." (Don't let the bastards grind you down.)
------------------------------------------------------------------------
^ permalink raw reply [relevance 5%]
* Re: Creating markets (long)
@ 1994-09-11 17:44 5% ` Michael Feldman
0 siblings, 0 replies; 123+ results
From: Michael Feldman @ 1994-09-11 17:44 UTC (permalink / raw)
In article <34tetc$dmk@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>Note that's it's not necessarily easy. IBM put a huge amount of resources into
>trying to promose PL/1 as a successor to COBOL, and clearly failed, although I
>think some of this can be ascribed to lousy early implementations (the Sears
>reversal was a watershed in this process).
I think those of us who were around in the late 60s and early 70s all have
our opinions about what brought PL/I down. Recall that IBM also was hoping
that PL/I would displace _Fortran_. IMHO, they blew it by (gratuitously,
for those times) mapping multidimensional arrays row-major, thereby
crippling the ability to reuse "legacy" Fortran, which mapped column-major.
(I do not think there was any special technical reason to switch to row
major, nor were there row-major languages wiuth which PL/I had to
interface; that's why I said the PL.I design decision was gratuitous.)
It may be sheer coincidence, but I like to think that Ada 83's policy
of letting _implementers_ determine storage mappings was partially a response
to this. A sharp implementer who wanted to penetrate the Fortran community
could build a nice interface to legacy Fortran, uninhibited by a gratuitously
incompatible array mapping scheme.
Unfortunately, I don't think any implementers took this possibility seriously,
and as far as I know, Ada implementations all go row-major.
Ada 94's Interfaces.Fortran is taking this seriously, though. Of course,
the Fortran community has taken the ten years to develop the Fortran
90 standard, which gives them yet another excuse to avoid Ada. Oh well.
(And gives the Ada vendors yet another excuse to avoid trying to
penetrate.)
Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman - chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University - Washington, DC 20052 USA
202-994-5253 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet)
"Pork is all that stuff the government gives the other guys."
------------------------------------------------------------------------
^ permalink raw reply [relevance 5%]
Results 1-123 of 123 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
1994-09-10 20:59 Creating markets (long) Michael Feldman
1994-09-10 23:19 ` Robert Dewar
1994-09-11 17:44 5% ` Michael Feldman
1994-10-15 17:01 Is C/C++ the future? R. William Beckwith
1994-10-21 11:56 ` James Hopper
1994-10-25 19:36 ` Brad Brahms
1994-10-25 23:46 ` Michael M. Bishop
1994-10-26 2:09 5% ` Michael Feldman
1994-10-26 15:40 12% Interfaces.Fortran Kyongsuk Pace
1994-10-26 22:28 12% ` Interfaces.Fortran Robert Dewar
1994-10-28 17:13 6% ` Interfaces.Fortran paus
1994-10-30 17:19 5% ` Interfaces.Fortran Robert Dewar
1994-10-31 15:33 6% Interfaces.Ada Kyongsuk Pace
1994-11-01 18:06 6% ` Interfaces.Ada Michael Feldman
1994-11-01 21:04 5% ` Interfaces.Ada Matt Kennel
1994-11-02 6:24 0% ` Interfaces.Ada Tucker Taft
1994-11-03 11:15 6% ` Interfaces.Ada Robert Dewar
1994-11-28 14:02 Why don't large companies use Ada? Robert Dewar
1994-12-02 5:25 ` Robert Dewar
1994-12-02 21:45 ` Michael Feldman
1994-12-03 5:43 ` Keith Thompson
1994-12-04 22:39 6% ` Michael Feldman
1994-12-05 22:57 ` Robert Dewar
1994-12-06 2:48 5% ` Michael Feldman
1994-12-06 3:29 0% ` Keith Thompson
1994-12-06 13:06 Paige Vinall
1994-12-07 14:15 ` Norman H. Cohen
1994-12-10 20:55 4% ` Array mappings Michael Feldman
1995-02-22 22:40 13% Using complex from interfaces.fortran Brian Hanson
1995-02-28 22:21 12% ` Tucker Taft
1996-05-31 0:00 5% Aggregate assignment problem with gnat under irix Ullar Kask
1996-06-12 0:00 Gnat 2.06 Ada95 (unix) File format???? Mike Ibarra
1996-06-15 0:00 ` James E. Hopper
1996-06-15 0:00 ` Ronald Cole
1996-06-15 0:00 ` Robert Dewar
1996-06-20 0:00 ` Michael Feldman
1996-06-21 0:00 ` Ronald Cole
1996-06-23 0:00 ` Robert Dewar
1996-06-27 0:00 5% ` Peter Hermann
1996-06-27 0:00 5% Fortran to call Ada Peter Hermann
1997-02-12 0:00 VMS to Unix (was: Is there a Fortran to Ada translator) W. Wesley Groleau (Wes)
1997-02-16 0:00 6% ` Oliver Kellogg
1997-02-17 0:00 0% ` Mats Weber
1997-02-26 0:00 5% ` Oliver Kellogg
1997-02-17 0:00 5% ` Robert Dewar
1997-02-21 0:00 6% importing fortran routines to GNAT Pasi J. Hakala
[not found] <342eedac.49311445@newsbeta.alt.net>
1997-09-29 0:00 5% ` Regarding: Extracting contents of binary data files Anonymous
1997-10-02 0:00 13% Is Interfaces.Fortran Mandatory or Optional? John Harbaugh
1997-10-02 0:00 6% ` Robert A Duff
1997-10-03 0:00 12% ` John Harbaugh
1997-10-04 0:00 5% ` Robert A Duff
1998-02-24 0:00 Ada-FORTRAN Interfacing Andy Willey
1998-02-25 0:00 6% ` Laurent Guerby
1998-03-01 0:00 6% Multilanguage Interfacing Andy Willey
1998-04-07 0:00 Urgent question: malloc and ada Guido Tesch
1998-04-09 0:00 ` Joe Gwinn
1998-04-10 0:00 ` Urgent question: malloc and ada...READ/NEW/FOLLOWUP Larry Kilgallen
1998-04-12 0:00 ` Joe Gwinn
1998-04-14 0:00 ` Robert Dewar
1998-04-16 0:00 ` Joe Gwinn
1998-04-17 0:00 ` Robert Dewar
1998-04-18 0:00 ` Joe Gwinn
1998-04-18 0:00 ` Robert Dewar
1998-04-25 0:00 ` Joe Gwinn
1998-04-26 0:00 ` Robert Dewar
1998-04-26 0:00 ` Jonathan Guthrie
1998-04-30 0:00 6% ` Robert I. Eachus
1998-04-30 0:00 0% ` Urgent question: malloc and ada Larry Kilgallen
1998-05-01 0:00 0% ` Urgent question: malloc and ada...READ/NEW/FOLLOWUP Fergus Henderson
[not found] <e4uxdrff6+w9@nedcu4>
1999-03-17 0:00 7% ` identify floating-point types Nick Roberts
1999-03-18 0:00 7% ` Nick Roberts
1999-03-19 0:00 0% ` robert_dewar
1999-03-19 0:00 5% ` Nick Roberts
1999-03-25 0:00 0% ` bglbv
1999-04-23 0:00 Very big Integers Denny
1999-04-23 0:00 ` Samuel Mize
1999-04-24 0:00 5% ` bglbv
1999-04-25 0:00 0% ` Matthew Heaney
1999-04-29 0:00 0% ` bglbv
1999-06-09 0:00 Linking FORTRAN77 to Ada83 Guy Calinsky
1999-06-10 0:00 4% ` bob
1999-09-06 0:00 Ada95 + FORTRAN 77 Preben Randhol
1999-09-06 0:00 6% ` lafage8770
1999-09-06 0:00 6% ` Matthew Heaney
1999-09-06 0:00 0% ` Robert Dewar
1999-09-06 0:00 4% ` Preben Randhol
1999-09-06 0:00 5% ` Robert Dewar
1999-09-06 0:00 5% ` Preben Randhol
1999-09-25 0:00 [A bit OT] Problems with GNAT 3.11p the middleman
1999-09-25 0:00 ` Robert Dewar
1999-09-25 0:00 ` the middleman
1999-09-26 0:00 1% ` Robert Dewar
1999-10-19 0:00 1% Announcing GNAT version 3.12p for Linux and Sparc Solaris Robert Dewar
2000-01-16 0:00 5% help on interfacing with fortran Paolo M. Pumilia
2000-01-16 0:00 7% ` Gisle S�lensminde
2000-01-24 0:00 Calling Ada in Fortran program sylvie.gore
2000-01-27 0:00 5% ` Stephen Leake
2000-05-11 0:00 5% BLAS binding Duncan Sands
[not found] <391BC1F5.DFB47045@maths.unine.ch>
2000-05-12 0:00 0% ` BLAS Duncan Sands
2000-05-13 0:00 0% ` BLAS Larry Kilgallen
2000-05-12 0:00 BLAS Duncan Sands
2000-05-12 0:00 6% ` BLAS Gautier
2000-05-19 0:00 LLQ: -1 a valid boolean? Ted Dennison
2000-05-19 0:00 5% ` Jeff Carter
2000-05-20 0:00 5% ` Ted Dennison
2000-05-21 0:00 6% ` Robert Dewar
2000-05-23 0:00 0% ` Ted Dennison
2000-05-23 0:00 0% ` David C. Hoos, Sr.
2000-05-23 0:00 0% ` Robert Dewar
2001-08-12 15:28 Trying to pass strings to Fortan routines Jack Scheible
2001-08-12 18:17 5% ` tmoran
2001-08-13 18:28 0% ` Jack Scheible
2001-11-01 22:05 Naturals and discrete types Clueless
2001-11-02 17:24 4% ` Ted Dennison
2001-11-26 15:15 14% Problematic type definition in Interfaces.Fortran Jacob Sparre Andersen
2002-07-20 0:57 6% Passing Unconstrained Arrays from FORTRAN to an Ada95 subunit Karen Carron
2003-02-25 11:17 Container libraries Jano
2003-02-26 17:51 ` Jean-Pierre Rosen
2003-02-27 12:04 ` Preben Randhol
2003-03-01 10:02 13% ` A question relating to package interfaces.fortran Zheng Long Gen
2003-11-24 22:05 New Language Design: (Cray, Sun prep radical software models for petaflops systems) Warren W. Gay VE3WWG
2003-11-25 11:05 ` Preben Randhol
2003-11-25 14:15 ` Warren W. Gay VE3WWG
2003-11-26 11:33 ` Dan Nagle
2003-11-26 15:25 5% ` Georg Bauhaus
2003-11-27 12:33 6% ` Dan Nagle
2004-05-01 1:00 A couple of questions Yeric
2004-05-01 15:12 ` Yeric
2004-05-01 15:37 4% ` Ed Falis
2004-07-26 21:44 [Ann] More Ada0Y packages for Ada95! Martin Dowie
2004-07-27 5:59 ` Martin Dowie
2004-07-31 19:15 ` Martin Dowie
2004-08-02 7:38 ` Jano
2004-08-02 10:02 ` Martin Dowie
2004-08-02 10:25 ` Jano
2004-08-02 12:59 ` Georg Bauhaus
2004-08-02 13:51 ` Martin Dowie
2004-08-02 15:54 ` Georg Bauhaus
2004-08-03 10:09 ` Fortran Interface (Was:Re: [Ann] More Ada0Y packages for Ada95!) Dan Nagle
2004-08-03 14:39 ` Wes Groleau
2004-08-03 18:15 ` Fortran Interface Georg Bauhaus
2004-08-06 11:46 5% ` Dr Steve Sangwine
2005-01-10 14:29 5% Interfacing Gnat to Fortran Complex*16 Steve Sangwine
2007-07-25 6:50 Just a thought! Xianzheng Zhou
2007-07-25 12:43 3% ` anon
2007-07-26 23:37 0% ` Xianzheng Zhou
2007-08-10 23:34 gnatmake, gnat2007. Linking to lapack and blas using with Ada.Numerics.Generic_Real_Arrays; Nasser Abbasi
2007-08-12 1:01 ` Jerry
2007-08-12 9:53 5% ` Marc Enzmann
2009-06-28 17:56 unsigned type anon
2009-06-28 19:54 ` tmoran
2009-06-29 13:36 ` Rob Solomon
2009-06-29 14:18 ` Ludovic Brenta
2009-07-03 1:41 ` Rob Solomon
2009-07-03 7:12 ` Learning Ada (Was: unsigned type) Jacob Sparre Andersen
2009-07-03 22:20 ` anon
2009-07-04 14:53 ` Georg Bauhaus
2009-07-05 23:21 ` anon
2009-07-06 0:05 6% ` Ludovic Brenta
2010-04-12 4:12 How to exit a loop with keyboard input Jerry
2010-04-12 10:36 ` Jerry
2010-04-12 15:14 ` Tero Koskinen
2010-04-12 20:04 ` Simon Wright
2010-04-13 19:51 ` Jerry
2010-04-13 21:22 5% ` Simon Wright
2010-04-15 3:39 0% ` Jerry
2010-07-24 11:57 Interfacing Ada with C Ada novice
2010-07-24 16:38 ` Simon Wright
2010-07-24 17:58 ` Ada novice
2010-07-25 8:29 ` Simon Wright
2010-07-25 12:21 ` Ada novice
2010-07-25 23:21 5% ` Simon Wright
2010-07-26 1:24 0% ` John B. Matthews
2010-09-01 20:13 ANN: Ada 2005 Math Extensions, 20100901 release Simon Wright
2010-09-02 15:40 ` Ada novice
2010-09-02 22:12 ` jonathan
2010-09-03 2:08 ` John B. Matthews
2010-09-03 5:58 6% ` Simon Wright
2010-09-03 13:48 0% ` John B. Matthews
2010-09-30 6:17 simple question on long_float/short_float Nasser M. Abbasi
2010-09-30 6:58 5% ` J-P. Rosen
2010-09-30 8:31 0% ` Nasser M. Abbasi
2010-09-30 8:45 7% ` Nasser M. Abbasi
2010-09-30 9:59 0% ` Mark Lorenzen
2010-09-30 13:30 5% ` Peter C. Chapin
2010-09-30 15:56 4% ` Adam Beneschan
2010-10-02 9:11 6% ` Nasser M. Abbasi
2010-10-02 9:48 4% ` Dmitry A. Kazakov
2010-10-02 10:45 0% ` cjpsimon
2010-10-02 16:52 4% ` Jeffrey Carter
2011-05-27 20:50 6% Interfacing Ada multidimensional arrays with Fortran David Sauvage
2011-05-28 9:41 7% ` Simon Wright
2011-05-28 16:45 ` Simon Wright
2011-06-09 7:55 7% ` David Sauvage
2012-04-25 7:47 What would you like in Ada202X? Martin
2012-05-06 18:48 ` Niklas Holsti
2012-07-03 15:41 ` Pascal Obry
2012-07-03 15:50 ` Pascal Obry
2012-07-04 11:41 ` Ada novice
2012-07-04 12:30 ` Nasser M. Abbasi
2012-07-04 17:55 ` Simon Wright
[not found] ` <0o59v7djiffnl7sqdpp2uiso78oa9hb8sb@invalid.netcom.com>
2012-07-04 20:34 ` shai.lesh
2012-07-04 22:26 ` Simon Wright
2012-07-05 15:55 5% ` johnscpg
2012-07-05 16:57 0% ` Simon Wright
2012-07-06 9:26 my cheat sheet note on installation of the Ada binding to Blas and Lapack Nasser M. Abbasi
2012-07-08 0:50 5% ` Nasser M. Abbasi
2012-07-06 18:38 Free AMD Core Math Library (BLAS/LAPACK) + Ada Ada novice
[not found] ` <d21d15b6-424d-4e96-9457-43d53d9239b9@googlegroups.com>
2012-07-15 16:47 ` Simon Wright
2012-07-15 17:42 ` Ludovic Brenta
2012-07-15 18:41 ` Simon Wright
2012-07-15 20:06 ` Ludovic Brenta
2012-07-15 20:41 ` Simon Wright
2012-07-15 21:24 ` Ada novice
2012-07-15 22:20 ` Simon Wright
2012-07-16 7:56 ` Ada novice
2012-07-16 9:27 ` Simon Wright
[not found] ` <374bd898-5683-4350-8812-e3cae186ab2b@googlegroups.com>
2012-07-16 11:36 ` Simon Wright
2012-07-16 13:08 ` Ada novice
2012-07-16 19:51 ` Ludovic Brenta
[not found] ` <cfd19c01-91e7-4e01-b2e8-e89f6c18764e@googlegroups.com>
2012-07-16 22:14 ` Simon Wright
2012-07-24 13:09 ` Ada novice
2012-07-24 13:54 ` Nasser M. Abbasi
2012-07-24 14:18 ` Simon Wright
2012-07-24 15:19 ` Nasser M. Abbasi
2012-07-24 15:27 ` Ada novice
2012-07-24 15:40 ` Ada novice
2012-07-24 16:41 5% ` Nasser M. Abbasi
2012-07-24 17:36 ` Ada novice
2012-07-24 22:13 ` Nasser M. Abbasi
2012-07-25 5:36 4% ` Ada novice
2012-07-25 6:13 ` Nasser M. Abbasi
2012-07-25 8:56 4% ` Ada novice
2012-07-25 9:26 0% ` Georg Bauhaus
2012-07-08 0:08 5% How to initialize a matrix of one column only? Nasser M. Abbasi
2012-07-08 0:20 0% ` Nasser M. Abbasi
2012-07-08 1:47 0% ` John B. Matthews
2012-07-08 7:43 0% ` Stephen Leake
2012-07-12 0:38 6% Lapack Ada binding matrices/vectors issue, how to best to resolve? Nasser M. Abbasi
2012-07-12 0:45 0% ` Nasser M. Abbasi
2012-07-28 3:22 basic question on nested packages Nasser M. Abbasi
2012-07-28 5:27 ` Nasser M. Abbasi
2012-07-28 5:36 ` Shark8
2012-07-28 9:01 5% ` Nasser M. Abbasi
2012-07-31 6:37 5% fyi, small update to Ada LAPACK and BLAS binding Nasser M. Abbasi
2012-07-31 8:59 0% ` Niklas Holsti
2012-12-27 18:48 A thicker binding for Lapack jpwoodruff
2012-12-27 19:18 ` Shark8
2012-12-29 18:36 ` jpwoodruff
2012-12-29 19:59 8% ` Simon Wright
2012-12-30 18:05 ` jpwoodruff
2012-12-30 19:41 ` Simon Wright
2013-01-01 0:24 6% ` jpwoodruff
2014-04-07 14:34 Statistics Poul-Erik Andreasen
2014-04-08 21:34 ` Statistics gautier_niouzes
2014-04-09 0:24 ` Statistics Poul-Erik Andreasen
2014-04-09 6:37 ` Statistics Simon Wright
2014-04-09 7:58 ` Statistics J-P. Rosen
2014-04-09 9:52 6% ` Statistics Simon Wright
2019-06-24 23:33 Making the same mistake as the broken C interface to fortran Chris M Moore
2019-07-02 20:57 ` Simon Wright
2019-07-03 7:06 ` Chris M Moore
2019-07-03 19:02 ` Randy Brukardt
2019-07-03 21:31 ` Chris M Moore
2019-07-04 8:38 6% ` Simon Wright
2019-07-05 13:49 0% ` Chris M Moore
2019-07-05 17:44 0% ` Simon Wright
2019-07-07 16:33 0% ` Chris M Moore
2021-02-06 21:59 Pure Aspect on Library-Level Function Jeffrey R. Carter
2021-02-07 11:09 ` AdaMagica
2021-02-11 2:53 4% ` Randy Brukardt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox