🚀 go-pugleaf

> From: thads@csn.net (Thad Smith)
> 
>  > First, the utility is the same -- large or small.  If you need to
>  > perform arithmetic operations with X-bit integers, they should
>  > look the same.  The size doesn't change their utility.
> 
> OK, I'll agree with that.  What I should have said is that the work
> to handle, without direct hardware support, a structure as a large
> int becomes significantly greater with the size of the int without
> corresponding increase in the utility.

Yes, this is true.  In fact Martin Kealey pointed out that the number
of operations you need for some hardware (adds and carries) is
proportional to about (N+1)*N/2 instructions, where N is the number of
segments.  Making 128-bit arithmetic out of 32-bit segments is too
bad, but making 1024-bit arithmetic out of 8-bit segments would be
a pain (assuming no hardware support for extended arithmetic).  I'll
raise this as an open issue in the SBEIR paper.

> ... What is the point of supplying multiple-precision support
> if most of the large ints are simply used as structures?

True -- using large integers as structures doesn't really make sense.

Bit fields are a special case and the compiler knows how to optimize
the value so large integer operations are not performed.

> I agree that if it makes sense to build in multiple-precision
> support, the compiler + library can do a first-class job.  Since I do
> a lot of work with 8-bit embedded processors, I understand this
> concept well. Does it make sense to require a Standard C compiler for
> these small processors (with the target often limited to a few kb of
> RAM and no disk storage) to support 128-bit ints?  If it's not hard
> to implement I suppose it doesn't hurt to throw it in.  But even if I
> don't use very long ints, doesn't *printf have to link in the code
> just in case?

There are tricks that the compiler can do to make this work.  For example,
many compilers need to add floating point libaries, but *only* if floating
point operations are used.  Typically, the compiler recognizes if the
feature is used (e.g., floating point or extended integers), writes
code to access a dummy symbol that the linker will pull in (i.e., the
library gets loaded then).  I think this would solve your problems -- it's
tried and true technology for decades.

> ...
> The only point I'm questioning is the minimum required maximum that
> must be supported.  Because some applications need 64 bits, should
> all conforming implementations be required to furnish it?  128 bits?
> more?

This is a good point.  I'm sure there will be much lively discussion
on this.  My guess is that you are suggesting a rationale for 64-bits.
Could you summarize your rationale and include the specific minimum
maxima you believe should be in SBEIR and send me E-mail at
"frank@farance.com"?  I will be including this feedback in the
paper and/or presentations.  I'd like to include your (and others')
opinions on this.

-FF
-------------------------------------------------------------------
(``I only use AOL for reading netnews.'')
Frank Farance, Farance Inc.
E-mail: frank@farance.com, Telephone: +1 212 486 4700
ISO JTC1/SC22/WG14 & ANSI X3J11 (C Programming Language) Project Editor