shifting bits

shifting bits

[fabio de francesco]

Hello.

I had to pack/unpack some variables into/from one. In order to get the
result I chose to shift the variables' bits using multiplications and
divisions by powers of two.

1) Does Ada have a built-in shift operand like C++ "<<" and ">>" ?
2) Can only variables of modular type be shifted ? If yes, why ?
3) Will the following code produce some "shl" and "shr" machine
instruction ?

date_y := date_y * 2**9;	-- shift left	
year := integer((date / 2**9) and offset_year); --shift right and
"and" offset

I thank you all in advance.

Ciao,
Fabio De Francesco.


P.S. The following is the complete code in the case someone wanted to
read it in the whole. I/O routines and values checks have been cut to
the minimum or removed.

with Ada.Text_IO, Ada.Integer_Text_IO;
use Ada.Text_IO, Ada.Integer_Text_IO;

procedure packed_date is

    type date_type is mod 2**20;
    date, date_y, date_m, date_d : date_type := 0;
    offset_year : constant date_type := 2**11-1;
    offset_month : constant date_type := 2**4-1;
    offset_day : constant date_type := 2**5-1;
    year : integer range 1900 .. 2099 := 1900;
    month : integer range 1 .. 12 := 1;
    day : integer range 1 .. 31 := 1;
    
begin

    get (year);
    date_y := date_type(year);
    date_y := date_y * 2**9;
    get (month);
    date_m := date_type(month);
    date_m := date_m * 2**5;
    get (day);
    date_d := date_type(day);
    date := date_y or date_m or date_d;
    day := integer(date and offset_day);
    put(day);
    month := integer( (date / 2**5) and offset_month );
    put(month);
    year := integer( (date / 2**9) and offset_year );
    put(year);
    
end packed_date;

Re: shifting bits

[Jim Rogers]

fmdf@tiscali.it (fabio de francesco) wrote in 
news:ba2f9c57.0408281738.61a48643@posting.google.com:

> Hello.
> 
> I had to pack/unpack some variables into/from one. In order to get the
> result I chose to shift the variables' bits using multiplications and
> divisions by powers of two.
> 
> 1) Does Ada have a built-in shift operand like C++ "<<" and ">>" ?

Ada provides similar bit shifting operations in the package Interfaces.
Those operations are defined for specific instances of modular types.

> 2) Can only variables of modular type be shifted ? If yes, why ?

Even in C and C++ bit shifting is only correct for unsigned types.
Think about what would happen if you shift a sign bit. The 
resulting values would be really nasty depending upon the state of
the sign bit.

Modular types are Ada's unsigned types.

Jim Rogers

Re: shifting bits

[Martin Krischik]

Jim Rogers wrote:

> fmdf@tiscali.it (fabio de francesco) wrote in
> news:ba2f9c57.0408281738.61a48643@posting.google.com:
> 
>> Hello.
>> 
>> I had to pack/unpack some variables into/from one. In order to get the
>> result I chose to shift the variables' bits using multiplications and
>> divisions by powers of two.
>> 
>> 1) Does Ada have a built-in shift operand like C++ "<<" and ">>" ?
> 
> Ada provides similar bit shifting operations in the package Interfaces.
> Those operations are defined for specific instances of modular types.
> 
>> 2) Can only variables of modular type be shifted ? If yes, why ?
> 
> Even in C and C++ bit shifting is only correct for unsigned types.
> Think about what would happen if you shift a sign bit. The
> resulting values would be really nasty depending upon the state of
> the sign bit.

And wen you still need the potentional dangerous operation you could address
map an unsigned type:

I : Interfaces.Integer_32;
U : Interfaces.Unsigned_32;

for U'Address use I'Address;

begin 
  I := 2* 30;
  Interfaces.Shift_Left (U, 1);

And I will have just the same wacky result als in C.

> Modular types are Ada's unsigned types.

To clarify: Range types alwas have sign - even when the range itself does
not allow a negative value.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: shifting bits

[Ludovic Brenta]

Fabio de Francesco writes:
> Hello.
>
> I had to pack/unpack some variables into/from one. In order to get the
> result I chose to shift the variables' bits using multiplications and
> divisions by powers of two.

Others have responded to the modular type part of your question, but I
suspect that modular types and shifting is not the best way to solve
your problem.  In Ada, you can express your problem much more cleanly,
using representation clauses:

procedure Packed_Date is
   type Day_Type is range 1 .. 31;
   for Day_Type'Size use 5;

   type Month_Type is range 1 .. 12;
   for Month_Type'Size use 4;

   type Year_Type is range 1900 .. 2099;
   for Year_Type'Size use 11;

   type Date_Type is record
      Day : Day_Type;
      Month : Month_Type;
      Year : Year_Type;
   end record;

   for Date_Type use record
      Day at 0 range 0 .. 4;
      Month at 0 range 5 .. 8;
      Year at 0 range 9 .. 19;
   end record;

   for Date_Type'Size use 20;

   Year, Month, Day : Integer;
   Date : Date_Type;
begin
   Get (Year);
   Date.Year := Year_Type (Year);
   Get (Month);
   Date.Month := Month_Type (Month);
   Get (Day);
   Date.Day := Day_Type (Day);
end Packed_Date;


The philosophy in Ada is: say what you want, and let the compiler do
the dirty work for you.

-- 
Ludovic Brenta.

Re: shifting bits

[fabio de francesco]

Jim Rogers <jimmaureenrogers@worldnet.att.net> wrote in message news:<Xns9553DDDC8BEA9jimmaureenrogers@204.127.36.1>...
> fmdf@tiscali.it (fabio de francesco) wrote in 
> news:ba2f9c57.0408281738.61a48643@posting.google.com:
> 
> > 2) Can only variables of modular type be shifted ? If yes, why ?
> 
> Even in C and C++ bit shifting is only correct for unsigned types.
> Think about what would happen if you shift a sign bit. The 
> resulting values would be really nasty depending upon the state of
> the sign bit.
> 
> Modular types are Ada's unsigned types.
> 
> Jim Rogers

Talking about C/C++ you may want to shift a signed numeric variable
one position by one to the right in order to either inspect or print
each single bit that composes the number.

In low-level code, If you know what you are shifting and why, you
won't have any bad result. May be that I'm used to Assembly where you
often do shifting with every type of value for the most unthinkable
reason.

Regards,
Fabio De Francesco

Re: shifting bits

[Ludovic Brenta]

Fabio de Francesco writes:
> Talking about C/C++ you may want to shift a signed numeric variable
> one position by one to the right in order to either inspect or print
> each single bit that composes the number.

In Ada, you would to an Unchecked_Conversion to an array of bits, and
access each bit by position number.  You can do that from any type.

> In low-level code, If you know what you are shifting and why, you
> won't have any bad result. May be that I'm used to Assembly where
> you often do shifting with every type of value for the most
> unthinkable reason.

In assembler, you can only do bit-shifting on data types that have a
"natural" size for your hardware (e.g. 8, 16, 32 and 64 bits).

Ada allows you to have types with arbitrary sizes, in particular when
embedding them into records, as in my earlier example where the Month
is on 4 bits, Day on 5 bits and Year on 11 bits.

This is why, in Ada, the bit-shifting operations are only defined (in
package Interfaces) for certain sizes on modular types, corresponding
to the target hardware's "natural" sizes.

-- 
Ludovic Brenta.

Re: shifting bits

[Stephen Leake]

fmdf@tiscali.it (fabio de francesco) writes:

> I had to pack/unpack some variables into/from one. In order to get the
> result I chose to shift the variables' bits using multiplications and
> divisions by powers of two.

You should also consider using a record with a representation clause;
that will be much more readable. Something like:

with Ada.Text_IO; use Ada.Text_IO;
procedure Packed_Date
is
   type Unsigned_4 is mod 2**4;
   type Unsigned_11 is mod 2**11;

   type Packed_Date_Type is record
      Year  : Unsigned_11;
      Month : Unsigned_4;
      Day   : Unsigned_4;
   end record;
   for Packed_Date_Type use record
      Year  at 0 range 9 .. 19;
      Month at 0 range 5 ..  8;
      Day   at 0 range 0 ..  4;
   end record;
   for Packed_Date_Type'Size use 20;

   Date : constant Packed_Date_Type :=
     (Year  => 1900,
      Month => 1,
      Day   => 2);

   type Double_Packed_Date_Type is record
      Date_1 : Packed_Date_Type;
      Date_2 : Packed_Date_Type;
   end record;

   Double_Date : constant Double_Packed_Date_Type := (Date, Date);

   type Packed_Double_Packed_Date_Type is record
      Date_1 : Packed_Date_Type;
      Date_2 : Packed_Date_Type;
   end record;
   pragma Pack (Packed_Double_Packed_Date_Type);

   Packed_Double_Date : constant Packed_Double_Packed_Date_Type := (Date, Date);
begin
   Put_Line ("Year => " & Unsigned_11'Image (Date.Year));
   Put_Line ("Month => " & Unsigned_4'Image (Date.Month));
   Put_Line ("Day => " & Unsigned_4'Image (Date.Day));

   Put_Line ("Date'size => " & Integer'Image (Date'Size));
   Put_Line ("Double_Date'size => " & Integer'Image (Double_Date'Size));
   Put_Line ("Packed_Double_Date'size => " & Integer'Image (Packed_Double_Date'Size));
end Packed_Date;

This compiles, and produces the output:

./packed_date.exe 
Year =>  1900
Month =>  1
Day =>  2
Date'size =>  24
Double_Date'size =>  48
Packed_Double_Date'size =>  40

I'm not sure I got the field sizes and locations correct; note how
much clearer that is with this code than with your original.

You do need to worry about byte endianness for this code; your shift
and mask code is endian-independent.

The object Date occupies 24 bits, because it must be an integral
number of bytes. Packed_Double_Date is packed as expected.

Note that the compiler will use shift and mask operations to access
these fields. And it has a chance to do it more efficiently than if
you code it, since it has more information to work with.

-- 
-- Stephe

Re: shifting bits

[Michael Bode]

fmdf@tiscali.it (fabio de francesco) writes:

> Talking about C/C++ you may want to shift a signed numeric variable
> one position by one to the right in order to either inspect or print
> each single bit that composes the number.

So you are viewing your integer or float number as an array of single
bits, right? Maybe you want to manipulate single bits in random order
too? In Ada you can write it that way:

with Ada.Text_Io; use Ada.Text_Io;

procedure Bits is

   type Bit_Array is array (0 .. Integer'Size-1) of Boolean;
   pragma Pack (Bit_Array);
   
   I : Integer := 42;
   A : Bit_Array;
   for A'Address use I'Address;
   
   Bool_Image : array (Boolean'Range) of Character := ('0', '1');
   
begin
   Put_Line ("Int: " & Integer'Image (I));
   for J in reverse 0 .. Integer'Size-1 loop
      Put (Bool_Image (A (J)));
   end loop;
end Bits;

Re: shifting bits

[tmoran]

There's an error in:
>   date_y := date_y * 2**9;
You need to subtract 1900 first.
>   year := integer( (date / 2**9) and offset_year );
You need to add 1900 after this.

Re: shifting bits

[tmoran]

>  type Year_Type is range 1900 .. 2099;
>  for Year_Type'Size use 11;
  While Gnat 3.15p for Windows appears to do this automatic offsetting
(subtracting/adding 1900) it's not portable Ada - other compilers say
those values don't fit in 11 bits.

Re: shifting bits

[Simon Wright]

Ludovic Brenta <ludovic.brenta@insalien.org> writes:

> In Ada, you would to an Unchecked_Conversion to an array of bits,
> and access each bit by position number.  You can do that from any
> type.

This is likely to be endian-dependent .. probably better to shift

-- 
Simon Wright                               100% Ada, no bugs.

Re: shifting bits

[fabio de francesco]

tmoran@acm.org wrote in message news:<McoYc.65221$9d6.60108@attbi_s54>...
> There's an error in:
> >   date_y := date_y * 2**9;
>  You need to subtract 1900 first.
> >   year := integer( (date / 2**9) and offset_year );
> You need to add 1900 after this.

I don't think so. I have run the compiled program and it works.

Anyway I think I will change the code following some interesting
advice from this group.

Ciao,
Fabio De Francesco.

Re: shifting bits

[tmoran]

> > There's an error in:
> > >   date_y := date_y * 2**9;
> >  You need to subtract 1900 first.
> I don't think so. I have run the compiled program and it works.
    The "Ada Way" generally tries to use logic in preference to
testing/debugging.  In this case, 2099 * 2**9 > 2**20.

Re: shifting bits

[Ole-Hjalmar Kristensen]

>>>>> "fdf" == fabio de francesco <fmdf@tiscali.it> writes:

    fdf> Hello.
    fdf> I had to pack/unpack some variables into/from one. In order to get the
    fdf> result I chose to shift the variables' bits using multiplications and
    fdf> divisions by powers of two.

    fdf> 1) Does Ada have a built-in shift operand like C++ "<<" and ">>" ?

Yes, defined for modular types.

    fdf> 2) Can only variables of modular type be shifted ? If yes, why ?

Portability, I guess. What happens if you shift a sigend type? If this
annoys you, you can always convert to an unsigned type.

    fdf> 3) Will the following code produce some "shl" and "shr" machine
    fdf> instruction ?

    fdf> date_y := date_y * 2**9;	-- shift left	
    fdf> year := integer((date / 2**9) and offset_year); --shift right and
    fdf> "and" offset

    fdf> I thank you all in advance.

    fdf> Ciao,
    fdf> Fabio De Francesco.

Have you considered just using a record and specifying which bits
should be allocated to the different fields instead? This would save
you the trouble of doing the packing/unpacking yourself....


<snip>

-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: shifting bits

[Dale Stanbrough]

In article <wvbreklpknew.fsf@sun.com>,
 Ole-Hjalmar Kristensen 
 <ole-hjalmar.kristensen@substitute_employer_here.com> wrote:

> 
> Have you considered just using a record and specifying which bits
> should be allocated to the different fields instead? This would save
> you the trouble of doing the packing/unpacking yourself....


Another useful trick is to declare a standard record type...

   type x is record
      field1 : sometype;
      field2 : anothertype;
   end record;


then create a derived type and give it a representation clause.

   type y is new x;

   -- apply rep clause for type y.



You can then read values into type y. Doing an assignment to
an object of type x unpacks the item automatically, and allows
for fast access to the components based on the natural alignments
that the compiler would choose.

E.g.

   xx : x;
   yy : y;

    read (yy);

    xx := (X) yy; -- unpacks

Going the other way also works.

Dale

-- 
dstanbro@spam.o.matic.bigpond.net.au

Re: shifting bits

[Martin Krischik]

fabio de francesco wrote:

Yet another idea (have not seen it before):

>     year : integer range 1900 .. 2099 := 1900;

type year_type is range 1900 .. 2099 := 1900;
for year_type'Size use 256;

>     month : integer range 1 .. 12 := 1;

type month_type range 1 .. 12 := 1;
for month_type'Size use 4;

>     day : integer range 1 .. 31 := 1;

type day_type range 1 .. 31 := 1;
for day_type'Size use 5;

And continue to build from there.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: shifting bits

[Georg Bauhaus]

Martin Krischik <krischik@users.sourceforge.net> wrote:
:>     month : integer range 1 .. 12 := 1;
: 
: type month_type range 1 .. 12 := 1;
: for month_type'Size use 4;

when I declare

   type month_type is range 1 .. 12;
   for month_type'Size use 4;

   m: month_type := 1;

the compiler chooses 8 (following the rule
"Object_Size must be 8, 16, 32, or multiple of 64"
I guess.)

   TIO.put_line("m's size: " & Natural'image(m'size));

prints

m's size:  8

Tried with GNATs. Do other compilers choose smaller
representations?


-- Georg

Re: shifting bits

[Jeffrey Carter]

Dale Stanbrough wrote:

>     xx := (X) yy; -- unpacks

Xx := X (Yy);

Apparently you've been spending too much time on the dark side.

-- 
Jeff Carter
"Now look, Col. Batguano, if that really is your name."
Dr. Strangelove
31

Re: shifting bits

[Jeffrey Carter]

Georg Bauhaus wrote:

> when I declare
> 
>    type month_type is range 1 .. 12;
>    for month_type'Size use 4;
> 
>    m: month_type := 1;
> 
> the compiler chooses 8 (following the rule
> "Object_Size must be 8, 16, 32, or multiple of 64"
> I guess.)
> 
>    TIO.put_line("m's size: " & Natural'image(m'size));
> 
> prints
> 
> m's size:  8

A specified 'Size effects the size in a packed composite type, but not 
for a stand-alone object. Try

type Month_List is array (Month_Type) of Month_Type;
pragma Pack (Month_List);

L : Month_List;

TIO.Put_Line ("L's size: " & Natural'image (L'Size) );

GNAT 3.15p/Win98 outputs

M's size:  8
L's size:  64

L has been padded to a multiple of 32, which is allowed because it's a 
stand-alone object, but is not 96, which is what you would get if each 
component were 8 bits.

-- 
Jeff Carter
"Now look, Col. Batguano, if that really is your name."
Dr. Strangelove
31

Re: shifting bits

[fabio de francesco]

tmoran@acm.org wrote in message news:<CSxYc.205551$8_6.140085@attbi_s04>...
> > > There's an error in:
> > > >   date_y := date_y * 2**9;
> > >  You need to subtract 1900 first.
> > I don't think so. I have run the compiled program and it works.
>     The "Ada Way" generally tries to use logic in preference to
> testing/debugging.  In this case, 2099 * 2**9 > 2**20.

Thank you, now I can see the problem with year > 2047.

Fabio De Francesco

Re: shifting bits

[Georg Bauhaus]

Jeffrey Carter <spam@spam.com> wrote:

: A specified 'Size effects the size in a packed composite type, but not 
: for a stand-alone object.

Ah. Nice language :-)
Thanks,
 Georg

ACM Queue Ada article

[tmoran]

"There's Still Some Life Left in Ada", Alexander Wolfe, ACM Queue Oct 2004

Re: ACM Queue Ada article

[Marc A. Criley]

<tmoran@acm.org> wrote:
> "There's Still Some Life Left in Ada", Alexander Wolfe, ACM Queue Oct 2004

Eh, you beat me to it!   :-)

It's a good article, and its publication happens to support my contention in
a recent off-topic posting that while ACM's official journal, Communications
of the ACM, is boring, self-absorbed, and irrelevant to the software
industry, their other publication, ACM Queue, invites reading, has practical
relevance, and is interesting.

(And I formed that opinion well _before_ this Ada article was published :-)

I checked the www.acmqueue.org website to see if there was some kind of
online link to the article, but the site doesn't even cover the October
issue as of the time of this posting.

Marc A. Criley
McKae Technologies
www.mckae.com

Re: ACM Queue Ada article

[skidmarks]

"Marc A. Criley" <mcNOSPAM@mckae.com> wrote in message news:<2svf7hF1prlutU1@uni-berlin.de>...
> <tmoran@acm.org> wrote:
> > "There's Still Some Life Left in Ada", Alexander Wolfe, ACM Queue Oct 2004
 the .. 
> ACM's official journal, Communications
> of the ACM, is boring, self-absorbed, and irrelevant to the software
> industry ...

FYI, there was a weather change about 1980. The CACM format was
changed from a broad-brush topic area of algorithms, design,
inventions, and etc., to a 'software for the layman' format. The
former CACM had some blockbuster things to present, and for people on
the "don't know", provided exciting areas for exploration. Since that
time, the CACM is oft ignored (at least by me) and I agree with your
comments.

Sorry.

art

SIGAda ad

[tmoran]

There's a nice full page ad ending with "SIGAda 2004 is a conference that
you need to attend."  Unfortunately it's in the December 2004 CACM (p. 100)
that I received Saturday.  People inclined to jokes about Ada's speed or
reliability will probably be amused.  Sigh.

Gnat STORAGE_ERROR

[tmoran]

Would some kind soul remind me how one gets more memory for a program
compiled by Gnat for Windows?  "-Wl,--stack=0x2000000" seems to be
an upper limit for successful linking, but inadequate for excecution.
(I recently doubled RAM and now I'm getting Storage_Error!)

Re: Gnat STORAGE_ERROR

[Alex R. Mosteo]

tmoran@acm.org wrote:
> Would some kind soul remind me how one gets more memory for a program
> compiled by Gnat for Windows?  "-Wl,--stack=0x2000000" seems to be
> an upper limit for successful linking, but inadequate for excecution.
> (I recently doubled RAM and now I'm getting Storage_Error!)

I have had success with 3.15p using

--Xlinker --stack=4000000,4000000

however in linux there seems to be some other limit imposed by ld (not 
just to Ada programs) that I've been unable to break (nor to get some 
other person to acknowledge that the problem really exists, but some 
obscure post in some unknown forum).

Re: Gnat STORAGE_ERROR

[Duncan Sands]

> however in linux there seems to be some other limit imposed by ld (not 
> just to Ada programs) that I've been unable to break (nor to get some 
> other person to acknowledge that the problem really exists, but some 
> obscure post in some unknown forum).

What does
	ulimit -s
return?

All the best,

Duncan.

Re: Gnat STORAGE_ERROR

[Alex R. Mosteo]

Duncan Sands wrote:
>>however in linux there seems to be some other limit imposed by ld (not 
>>just to Ada programs) that I've been unable to break (nor to get some 
>>other person to acknowledge that the problem really exists, but some 
>>obscure post in some unknown forum).
> 
> 
> What does
> 	ulimit -s
> return?

unlimited

I didn't get any linking error, it was simply that the stack size didn't 
seem to be honored and peaked at about 2MB. Eventually I removed my 
needs for so a big stack and didn't explore the matter further. It could 
be too a thing of old linux versions, or something I did wrong.

Re: Gnat STORAGE_ERROR

[Duncan Sands]

On Wed, 2005-05-25 at 12:05 +0200, Alex R. Mosteo wrote:
> Duncan Sands wrote:
> >>however in linux there seems to be some other limit imposed by ld (not 
> >>just to Ada programs) that I've been unable to break (nor to get some 
> >>other person to acknowledge that the problem really exists, but some 
> >>obscure post in some unknown forum).
> > 
> > 
> > What does
> > 	ulimit -s
> > return?
> 
> unlimited
> 
> I didn't get any linking error, it was simply that the stack size didn't 
> seem to be honored and peaked at about 2MB. Eventually I removed my 
> needs for so a big stack and didn't explore the matter further. It could 
> be too a thing of old linux versions, or something I did wrong.

If you don't use a Storage_Size pragma in a task then you get
(in s-parame.adb):

   ------------------------
   -- Default_Stack_Size --
   ------------------------

   function Default_Stack_Size return Size_Type is
   begin
      return 2 * 1024 * 1024;
   end Default_Stack_Size;

Ciao,

D.

Re: Gnat STORAGE_ERROR

[Alex R. Mosteo]

Duncan Sands wrote:
> On Wed, 2005-05-25 at 12:05 +0200, Alex R. Mosteo wrote:
> 
>>Duncan Sands wrote:
>>
>>>>however in linux there seems to be some other limit imposed by ld (not 
>>>>just to Ada programs) that I've been unable to break (nor to get some 
>>>>other person to acknowledge that the problem really exists, but some 
>>>>obscure post in some unknown forum).
>>>
>>>
>>>What does
>>>	ulimit -s
>>>return?
>>
>>unlimited
>>
>>I didn't get any linking error, it was simply that the stack size didn't 
>>seem to be honored and peaked at about 2MB. Eventually I removed my 
>>needs for so a big stack and didn't explore the matter further. It could 
>>be too a thing of old linux versions, or something I did wrong.
> 
> 
> If you don't use a Storage_Size pragma in a task then you get
> (in s-parame.adb):

I was using explicit sizes, but thank nonetheless.

>    ------------------------
>    -- Default_Stack_Size --
>    ------------------------
> 
>    function Default_Stack_Size return Size_Type is
>    begin
>       return 2 * 1024 * 1024;
>    end Default_Stack_Size;
> 
> Ciao,
> 
> D.
> 

Re: Gnat STORAGE_ERROR

[tmoran]

> I have had success with 3.15p using
>
> --Xlinker --stack=4000000,4000000

Doesn't seem to make any difference for me under Windows 2000.
Further, according to Task Manager the program when it STORAGE_ERRORs is
using 8.8MB and it's at a place where it is trying to allocate 4 MB on the
stack.  I would expect -Wl,--stack=0x2000000 to make about 32MB available.

Re: Gnat STORAGE_ERROR

[David C. Hoos, Sr.]

How big is your page file(s) allowed to grow?

Remember that if the stack is owned by a task,
the stack size is limited to the default task size,
unless you've specified a greater stack size with
pragma Storage_Size.
----- Original Message ----- 
From: <tmoran@acm.org>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada-france.org>
Sent: May 25, 2005 1:30 PM
Subject: Re: Gnat STORAGE_ERROR


>> I have had success with 3.15p using
>>
>> --Xlinker --stack=4000000,4000000
> 
> Doesn't seem to make any difference for me under Windows 2000.
> Further, according to Task Manager the program when it STORAGE_ERRORs is
> using 8.8MB and it's at a place where it is trying to allocate 4 MB on the
> stack.  I would expect -Wl,--stack=0x2000000 to make about 32MB available.
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada-france.org
> http://www.ada-france.org/mailman/listinfo/comp.lang.ada
> 
>

Re: Gnat STORAGE_ERROR

[Duncan Sands]

> > If you don't use a Storage_Size pragma in a task then you get
> > (in s-parame.adb):
> 
> I was using explicit sizes, but thank nonetheless.

>From the GNAT user's guide:


A.6 Linux-Specific Considerations 
 The default thread library under GNU/Linux has the following disadvantages compared to other native thread libraries: 
The size of the task's stack is limited to 2 megabytes. 
The signal model is not POSIX compliant, which means that to send a signal to the process, you need to send the signal to all threads, e.g. by using killpg().

Ciao,

D.

Re: Gnat STORAGE_ERROR

[Alex R. Mosteo]

Duncan Sands wrote:
>>> If you don't use a Storage_Size pragma in a task then you get (in
>>> s-parame.adb):
>> 
>> I was using explicit sizes, but thank nonetheless.
> 
> 
>> From the GNAT user's guide:
> 
> 
> A.6 Linux-Specific Considerations The default thread library under
> GNU/Linux has the following disadvantages compared to other native
> thread libraries: The size of the task's stack is limited to 2
> megabytes.

Argh. Thanks!

Re: Gnat STORAGE_ERROR

[tmoran]

> How big is your page file(s) allowed to grow?

C:pagefile.sys is 1.1GB and H:pagefile.sys is 1.5GB, total RAM is 1GB,
the program in question needs about 16MB (I compiled it with another Ada
compiler and Task Manager said it was using 15,790KB)  and the
stack=2000000 should, I think, allow 32MB.  Perhaps I should have
mentioned I have the stack checking turned on.  Perhaps if I turn that
off I won't get the STORAGE_ERROR? ;)

> Remember that if the stack is owned by a task,
> the stack size is limited to the default task size,
> unless you've specified a greater stack size with
> pragma Storage_Size.

  This is a vanilla single task numerical computation program.

Re: Gnat STORAGE_ERROR

[Björn Persson]

Duncan Sands wrote:
>>From the GNAT user's guide:
> 
> A.6 Linux-Specific Considerations 
>  The default thread library under GNU/Linux has the following disadvantages compared to other native thread libraries: 
> The size of the task's stack is limited to 2 megabytes. 
> The signal model is not POSIX compliant, which means that to send a signal to the process, you need to send the signal to all threads, e.g. by using killpg().

I would *guess* that the user's guide talks about Linuxthreads, not the 
newer NPTL. One would hope that the Native Posix Threading Library is 
Posix-compliant. The stack limit might of course be present in both, or 
it might not.

-- 
Bj�rn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

workaround, was Re: Gnat STORAGE_ERROR

[tmoran]

I compiled just the tight looping numerics as a dll with Gnat, then
compiled the rest of the program with Janus.  No more STORAGE_ERROR.
The Gnat-compiled subroutine does declare a local array of 4MB, but it
all seems to work.  Wish I knew why it didn't and why it now does.

Re: shifting bits

[tmoran]

Ada utility for Google Earth, NASA World Wind

[tmoran]

I've posted at
home.comcast.net/~tommoran4/scout091.zip
a zip file with readme.txt, Zoo.spc, and Scout.exe
I'll add the Ada source code after a bit of cleanup.

Scout aids finding locations and paths with Google Earth or NASA World
Wind by interconverting latitude & longitude decimal or degrees, minutes,
seconds, State Plane Coordinates, Metes and Bounds (only straight lines
for now).  Given a list of points in any of those forms, it will create
the Google Earth or World Wind path files to draw a path from point to
point.  It also can read Google Earth lat/lon format and convert to World
Wind format, or vice versa.  The current version is 0.91 and I'm adding to
it (and will post that code).  Suggestions welcomed.
tommoran4@comcast.net

Re: Ada utility for Google Earth, NASA World Wind

[Marc A. Criley]

tmoran@acm.org wrote:
> I've posted at
> home.comcast.net/~tommoran4/scout091.zip
> a zip file with readme.txt, Zoo.spc, and Scout.exe
> I'll add the Ada source code after a bit of cleanup.
> 
> Scout aids finding locations and paths with Google Earth or NASA World
> Wind by interconverting latitude & longitude decimal or degrees, minutes,
> seconds, State Plane Coordinates, Metes and Bounds (only straight lines
> for now).  Given a list of points in any of those forms, it will create
> the Google Earth or World Wind path files to draw a path from point to
> point.  It also can read Google Earth lat/lon format and convert to World
> Wind format, or vice versa.  The current version is 0.91 and I'm adding to
> it (and will post that code).  Suggestions welcomed.
> tommoran4@comcast.net

Enhancement request!!   :-)

First off, thanks for a fine program, for mapping and flyover geeks like 
me this is a big help.

Now, since of course there's no widespread standardization amongst 
consumer-oriented lat/long coordinate representations, Garmin's 
MapSource uses yet a different format.

Here's an example of a trackpoint line from an exported log (this is a 
single line, certain to have line wrapped in this posting):

Trackpoint	N34 52.676 W86 23.335	10/20/2004 9:07:00 AM			363 ft 
00:00:08	30.9 mph	46� true

It's trivial to cut this down to just the lat/long with an editor and 
end up with:

N34 52.676 W86 23.335

and I'd be happy if Scout would simply accept that as input.

If you'd like a full Log Export report from one of my geocaching trips 
(www.geocaching.com) for testing, which includes multiple tracks and 
vaious other device configuration information, let me know and I'll send 
it via email.

Thanks again!

-- Marc A. Criley
-- www.mckae.com
-- DTraq - XPath In Ada - XML EZ Out

Re: Ada utility for Google Earth, NASA World Wind

[tmoran]

> Enhancement request!!   :-)
>
> N34 52.676 W86 23.335
>
> and I'd be happy if Scout would simply accept that as input.
   Download version 0.95 from
home.comcast.net/~tommoran4/scout.zip
It has various other improvements too.

Re: Ada utility for Google Earth, NASA World Wind

[Rob Norris]

On Mon, 08 Aug 2005 08:27:32 -0500, "Marc A. Criley"
<mcNOSPAM@mckae.com> wrote:

>tmoran@acm.org wrote:
>> I've posted at
>> home.comcast.net/~tommoran4/scout091.zip
>> a zip file with readme.txt, Zoo.spc, and Scout.exe
>> I'll add the Ada source code after a bit of cleanup.
>> 
>Enhancement request!!   :-)
>
>First off, thanks for a fine program, for mapping and flyover geeks like 
>me this is a big help.
>
>Now, since of course there's no widespread standardization amongst 
>consumer-oriented lat/long coordinate representations, Garmin's 
>MapSource uses yet a different format.

Another enhancement request.

Support GPX format.

I think most are standardizing on XML scheme of GPX:

http://www.topografix.com/gpx.asp

Garmin MapSource (6.5 above supports GPX for example).

For an opensource implementation (C program I think) see somwhere in:

http://www.gpsbabel.org

I haven't seen GPX in Ada. Here's the chance :)

It's a pity I use Linux, maybe I'll have to fire up the Windows
partition to try Google Earth & maybe this scout program if someone
gets it to use GPX (could be me if the source becomes available).

Re: Ada utility for Google Earth, NASA World Wind

[tmoran]

> Another enhancement request.
>
> Support GPX format.
>
> I think most are standardizing on XML scheme of GPX:
   What is the relationship between the XML of GPX and the (apparent)
XML of Google Earth/Keyhole's .kml files?

> >tmoran@acm.org wrote:
> >> I've posted at
> >> home.comcast.net/~tommoran4/scout091.zip
> >> a zip file with readme.txt, Zoo.spc, and Scout.exe
> >> I'll add the Ada source code after a bit of cleanup.
  Change that to
home.comcast.net/~tommoran4/scout.zip
for the current release (right now, v 0.095).

Re: Ada utility for Google Earth, NASA World Wind

[Rob Norris]

On Wed, 10 Aug 2005 03:35:10 -0500, tmoran@acm.org wrote:

>> Another enhancement request.
>>
>> Support GPX format.
>>
>> I think most are standardizing on XML scheme of GPX:
>   What is the relationship between the XML of GPX and the (apparent)
>XML of Google Earth/Keyhole's .kml files?
>

Well apart from both being XML, there is some similarity.

It is possible to map parts from one to the other.

Some interesting info here:

http://cse-mjmcl.cse.bris.ac.uk/blog/2005/07/26/1122414882406.html

Re: Ada utility for Google Earth, NASA World Wind

[tmoran]

>> Another enhancement request.
>> Support GPX format.
> http://cse-mjmcl.cse.bris.ac.uk/blog/2005/07/26/1122414882406.html
  gpsbabel should convert your gpx to kml.  That was easy.  ;)
Scout was intended more for interactive, rather than batch, use, eg copy a
few coordinates in decimal degrees from World Wind, paste into Scout,
convert, paste result into Google Earth.  It's complementary to gpsbabel
in formats - there's no overlap (other than kml, of course).  It does
Google Earth <-> World Wind, State Plane Coordinates (often used for
property lines by county governments), and Metes and Bounds (surveyor
style).
  I'll try to post at least (the stable) part of the Ada source today.