Any Large Integer Libraries Out There for the ARM?

I needed to multiply U128 = U96 * U32 on an ARM the other day, and did
a hack job in C.  It is logically correct, but it probably takes 3-10
times as long as assembly-language.

Are there any large integer and similar libraries out there for the
ARM?

The GMP is a great resource, of course, but it isn't very applicable
to embedded systems because of:

(a)Dynamic allocation.

(b)Variable-size operands, which mean looping and branching, which
causes pipelined RISC machines not to perform as well as they would if
the code were written in a linear way.

Anything out there?

Thanks, Dave Ashley

David T.  Ashley wrote:

> I needed to multiply U128 = U96 * U32 on an ARM the other day, and did
> a hack job in C.  It is logically correct, but it probably takes 3-10
> times as long as assembly-language.
> 
> Are there any large integer and similar libraries out there for the
> ARM?
> 
> The GMP is a great resource, of course, but it isn't very applicable
> to embedded systems because of:
> 
> (a)Dynamic allocation.
> 
> (b)Variable-size operands, which mean looping and branching, which
> causes pipelined RISC machines not to perform as well as they would if
> the code were written in a linear way.
> 
> Anything out there?

I've been working on untangling the OpenSSL bignum library free from 
OpenSSL.  I've found it confusing because of a lot of upward dependencies, 
and the fact that the ./configure intermingles option setting for the whole 
package.  One target that may be nearby is to group the options that only 
bignum needs into a single .h file.

	Mel.

On Wed, 18 Apr 2012 10:54:20 -0400, mwilson@the-wire.com wrote:

>David T.  Ashley wrote:
>
>> I needed to multiply U128 = U96 * U32 on an ARM the other day, and did
>> a hack job in C.  It is logically correct, but it probably takes 3-10
>> times as long as assembly-language.
>> 
>> Are there any large integer and similar libraries out there for the
>> ARM?
>> 
>> The GMP is a great resource, of course, but it isn't very applicable
>> to embedded systems because of:
>> 
>> (a)Dynamic allocation.
>> 
>> (b)Variable-size operands, which mean looping and branching, which
>> causes pipelined RISC machines not to perform as well as they would if
>> the code were written in a linear way.
>> 
>> Anything out there?
>
>I've been working on untangling the OpenSSL bignum library free from 
>OpenSSL.  I've found it confusing because of a lot of upward dependencies, 
>and the fact that the ./configure intermingles option setting for the whole 
>package.  One target that may be nearby is to group the options that only 
>bignum needs into a single .h file.
>
>	Mel.

Hi Mel,

I have obtained this domain name:

http://www.armlib.com/

and I'm slugging away on the weekends.

If there is enough synergy where you feel we might be able to work
together or exchange technical information, please write me directly.

My feeling based on the embedded work I've done is that there need to
be two variants of the library--classic ARM and Thumb.  That
assessment may need to be adjusted downward or upward.

Thanks and best regards, Dave A.

On Wed, 18 Apr 2012 11:12:24 -0400, David T. Ashley
<dashley@gmail.com> wrote:

>On Wed, 18 Apr 2012 10:54:20 -0400, mwilson@the-wire.com wrote:
>
>>David T.  Ashley wrote:
>>
>>> I needed to multiply U128 = U96 * U32 on an ARM the other day, and did
>>> a hack job in C.  It is logically correct, but it probably takes 3-10
>>> times as long as assembly-language.
>>> 
>>> Are there any large integer and similar libraries out there for the
>>> ARM?
>>> 
>>> The GMP is a great resource, of course, but it isn't very applicable
>>> to embedded systems because of:
>>> 
>>> (a)Dynamic allocation.
>>> 
>>> (b)Variable-size operands, which mean looping and branching, which
>>> causes pipelined RISC machines not to perform as well as they would if
>>> the code were written in a linear way.
>>> 
>>> Anything out there?
>>
>>I've been working on untangling the OpenSSL bignum library free from 
>>OpenSSL.  I've found it confusing because of a lot of upward dependencies, 
>>and the fact that the ./configure intermingles option setting for the whole 
>>package.  One target that may be nearby is to group the options that only 
>>bignum needs into a single .h file.
>>
>>	Mel.
>
>Hi Mel,
>
>I have obtained this domain name:
>
>http://www.armlib.com/
>
>and I'm slugging away on the weekends.
>
>If there is enough synergy where you feel we might be able to work
>together or exchange technical information, please write me directly.
>
>My feeling based on the embedded work I've done is that there need to
>be two variants of the library--classic ARM and Thumb.  That
>assessment may need to be adjusted downward or upward.
>
>Thanks and best regards, Dave A.

Also, I'm not sure if my news client actually provides information to
write me directly.

My e-mail address is:

gmail.com@dashley

and I'm sure you'll figure out the sophisticated encryption algorithm
used to prevent harvesting robots from making use of my e-mail
address.

Thanks, Dave A.

David T.  Ashley wrote:

> On Wed, 18 Apr 2012 10:54:20 -0400, mwilson@the-wire.com wrote:

>>I've been working on untangling the OpenSSL bignum library free from
>>OpenSSL.  [ ... ]
> 
> Hi Mel,
> 
> I have obtained this domain name:
> 
> http://www.armlib.com/
> 
> and I'm slugging away on the weekends.
> 
> If there is enough synergy where you feel we might be able to work
> together or exchange technical information, please write me directly.
> 
> My feeling based on the embedded work I've done is that there need to
> be two variants of the library--classic ARM and Thumb.  That
> assessment may need to be adjusted downward or upward.
> 
> Thanks and best regards, Dave A.

I'm still working to get my head around the physical requirements for 
packaging a release.  It seems as though a source->.a process would suit my 
needs best.  That way, ARM/THUMB can be decided project-by-project.

I've just started some due diligence and registered with github.

Somebody there has <https://github.com/wbhart/bsdnt> under a BSD license 
which might be what we're both looking for.

Otherwise, it might be a plan to put up a BSD licensed project based on the 
BSD licensed OpenSSL code.

	Mel.

On Wed, 18 Apr 2012 11:59:46 -0400, mwilson@the-wire.com wrote:
>
>I'm still working to get my head around the physical requirements for 
>packaging a release.  It seems as though a source->.a process would suit my 
>needs best.  That way, ARM/THUMB can be decided project-by-project.
>
>I've just started some due diligence and registered with github.

Hi Mel,

I have the same thoughts.  Assuming that ".a" is the standard suffix
for an ARM library, a library would be built from the smallest
compileable modules (typically a single function each), and the linker
will automatically bring in only what it needs to satisfy references.

With few exceptions, the source code would consist of source files
that each contain a single function or a single constant or variable
data structure.

There would have to be two libraries--one for ARM classic and one for
THUMB.

Nearly all of the assembly-language modules would be different for the
ARM vs. the THUMB libraries, but nearly all of the C functions would
be the same for both libraries, with the development tool settings
compiling for ARM or THUMB.

>Somebody there has <https://github.com/wbhart/bsdnt> under a BSD license 
>which might be what we're both looking for.

Thanks.  I will look at that.

>Otherwise, it might be a plan to put up a BSD licensed project based on the 
>BSD licensed OpenSSL code.

Thanks.  I'm not sure about the BSD license.  I'll look at that.

I believe it was Steve Ballmer of Microsoft who once wrote that
"open-source licenses attach themselves like a cancer to anything they
touch".

I disagree with that point of view (I fully support open-source
development), but they just aren't practical for embedded systems.

Someone who buys a washing machine doesn't want to see information
about software licenses anywhere, including the manufacturer's web
page.  It doesn't help them to use or understand the product.

Open-source is great.  Open-source licenses applied to small embedded
systems is not.

DTA

On 18/04/12 19:43, David T. Ashley wrote:
> On Wed, 18 Apr 2012 11:59:46 -0400, mwilson@the-wire.com wrote:
>>
>> I'm still working to get my head around the physical requirements for
>> packaging a release.  It seems as though a source->.a process would suit my
>> needs best.  That way, ARM/THUMB can be decided project-by-project.
>>
>> I've just started some due diligence and registered with github.
>
> Hi Mel,
>
> I have the same thoughts.  Assuming that ".a" is the standard suffix
> for an ARM library, a library would be built from the smallest
> compileable modules (typically a single function each), and the linker
> will automatically bring in only what it needs to satisfy references.
>
> With few exceptions, the source code would consist of source files
> that each contain a single function or a single constant or variable
> data structure.
>
> There would have to be two libraries--one for ARM classic and one for
> THUMB.
>
> Nearly all of the assembly-language modules would be different for the
> ARM vs. the THUMB libraries, but nearly all of the C functions would
> be the same for both libraries, with the development tool settings
> compiling for ARM or THUMB.
>

A library (.a) with a header file is a convenient format to use - and as 
you say, each source file should only contain a few functions so that 
only those needed are linked in.

However, this will lead to sub-optimal code because it does not allow 
cross-function and cross-file optimisations.  If you are happy giving 
out the source code, then people can use that to get the smallest and 
fastest code.

Where possible, it is best to write such a library in C, using inline 
assembly when it makes a big difference.  If you can make your functions 
as inlineable C code, then it will often result in smaller and faster 
object code, as the compiler can do things like re-arrange registers, 
re-use results, avoid function call overheads, etc.  When you make the 
routines in fixed assembly, the compiler is forced to move data into and 
out of registers to suit the assembly code - this overhead can quickly 
outweigh the benefits of the tuned assembly code.

Where you do need assembly, it is often worth writing it as inline 
assembly using advanced syntaxes supported by the compiler.  Then at 
least the compiler has the freedom to pick registers and include the 
code in its optimisations.  gcc syntax is supported by several 
compilers, including (obviously) all gcc-based tools and CodeWarrior.  I 
don't know if other tools like IAR and Keil support them, or if they 
have their own syntax.

>> Somebody there has<https://github.com/wbhart/bsdnt>  under a BSD license
>> which might be what we're both looking for.
>
> Thanks.  I will look at that.
>
>> Otherwise, it might be a plan to put up a BSD licensed project based on the
>> BSD licensed OpenSSL code.
>
> Thanks.  I'm not sure about the BSD license.  I'll look at that.
>
> I believe it was Steve Ballmer of Microsoft who once wrote that
> "open-source licenses attach themselves like a cancer to anything they
> touch".
>
> I disagree with that point of view (I fully support open-source
> development), but they just aren't practical for embedded systems.
>
> Someone who buys a washing machine doesn't want to see information
> about software licenses anywhere, including the manufacturer's web
> page.  It doesn't help them to use or understand the product.
>
> Open-source is great.  Open-source licenses applied to small embedded
> systems is not.
>

Don't take advice about open-source licenses from Steve Ballmer - the 
only thing he knows about them is that they might slightly reduce his 
gazillion dollar income.  Anything he says is pure FUD.

What you are thinking about here is pure GPL - if you make your library 
GPL, then the user (i.e., another programmer) has to give the end user 
the right to all the source code, and the person buying the washing 
machine gets confusing information about the software license.

With BSD-style licenses, no restrictions are imposed on your users 
(other developers), and the end user knows nothing about it.  The only 
requirement is that no one can remove the copyright notices you put on 
the files and claim they wrote them.  It's a perfectly good license for 
embedded libraries.  (And Microsoft likes it too - they took the 
BSD-licensed network stack from FreeBSD to form the first version of the 
Windows TCP/IP stack.  Apple likes it even more - they took the entire 
BSD-licensed FreeBSD OS, put a nice face on it, and called it "OS X".)

An alternative is to use a modified GPL which forces developers to 
publish enhancements and modifications to the library code, without 
affecting anything in their own code.  See FreeRTOS for an example.

On Wed, 18 Apr 2012 21:00:34 +0200, David Brown
<david.brown@removethis.hesbynett.no> wrote:

>Apple likes [BSD license] even more - they took the entire 
>BSD-licensed FreeBSD OS, put a nice face on it, and called it "OS X".)

That's an exaggeration.  It's true that OS X contains some FreeBSD
code, but Apple certainly did not "take FreeBSD and put a nice face on
it".

OS X is based on NeXTSTEP, which itself was based on CMU's Mach 2.0
operating system.  NeXTSTEP took Mach and replaced the existing Unix
compatibility layer with new code that included ports of both FreeBSD
and NetBSD modules.  Apple chose NeXTSTEP to be the basis for the new
Mac OS and purchased NeXT to get it.

[And yes, I know Steve Jobs founded NeXT - after he was ousted from
Apple.  Jobs came back to Apple after a 10 year absence as part of the
deal to purchase NeXT.  Jobs did not retake control of Apple until the
company narrowly avoided bankruptcy 2 years later.]

George

David T. Ashley wrote:

> Also, I'm not sure if my news client actually provides information
> to write me directly.
> 
> My e-mail address is:
> 
> gmail.com@dashley
> 
> and I'm sure you'll figure out the sophisticated encryption algorithm
> used to prevent harvesting robots from making use of my e-mail
> address.

Errr... You provide your true e-mail address in the message headers
(From: field). Do you think crawlers ignore the headers?

On Apr 19, 10:06=A0am, Noob <r...@127.0.0.1> wrote:
> David T. Ashley wrote:
> > Also, I'm not sure if my news client actually provides information
> > to write me directly.
>
> > My e-mail address is:
>
> > gmail.com@dashley
>
> > and I'm sure you'll figure out the sophisticated encryption algorithm
> > used to prevent harvesting robots from making use of my e-mail
> > address.
>
> Errr... You provide your true e-mail address in the message headers
> (From: field). Do you think crawlers ignore the headers?
However, gmail is pretty good at filtering spam. I use a gmail address
for most of my public activity and gmail successfully gets rid of
99.999 percent of spam