From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org>
Newsgroups: comp.lang.ada
Subject: Re: ANN: Ada/SPARK ASN.1 implementation version 0.0.01
Date: Mon, 1 Aug 2016 12:47:34 -0700
Organization: Also freenews.netfront.net; news.tornevall.net;
 news.eternal-september.org
Message-ID: <nno90n$5pj$1@dont-email.me>
References: <3ac0fbcd-1f1c-40b8-b030-de03954f894f@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 1 Aug 2016 19:47:37 -0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="d7c030f56102b58a2c16dea977db88bb";
	logging-data="5939"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX18Vo6SfUtR82zQZUKep6qojQ0DDAm7U/W4="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
In-Reply-To: <3ac0fbcd-1f1c-40b8-b030-de03954f894f@googlegroups.com>
Cancel-Lock: sha1:/FpQz/w6ssG4+3rBBsH9ZXC5EQE=
Xref: news.eternal-september.org comp.lang.ada:31241
Date: 2016-08-01T12:47:34-07:00
List-Id: <comp.lang.ada>

On 08/01/2016 01:15 AM, Shark8 wrote:
> 
> I would certainly appropriate comments, criticism, and most especially contributions.

I took a look at the big-number pkg, and have the following suggestions:

If you want people to contribute to this effort, I'd suggest you use a coding
style more similar to that used in the ARM. You might also want to learn how to
spell "negative".

I don't see why it's desirable to specify the representation of the non-variable
parts of Big_Number.

I'd think it would be a good idea for code like this to be portable, in which
case it should avoid optional types such as Long_Long_Integer, and certainly not
assume it knows that it's 64 bits.

While it's unlikely to be an issue on modern processors, given your constant

Base : constant := 2 ** System.Word_Size;

there's no guarantee that declarations

type Digit is range 0 .. Base;

type Double_Digit is mod Base ** 2;

will be accepted. A more portable approach, and one which maximizes the size of
the digits used, is

type Double_Digit is mod System.Max_Binary_Modulus;

Digit_Size : constant := Double_Digit'Size / 2;

type Digit is mod Digit_Size;

This is the approach used by PragmARC.Unbounded_Integers.

HTH.

-- 
Jeff Carter
"We burst our pimples at you."
Monty Python & the Holy Grail
16