🚀 go-pugleaf

In article <41cu35$p2v@newsbf02.news.aol.com>,
ffarance@aol.com (FFarance) wrote:
>> From: thads@csn.net (Thad Smith)

 >>> While anything can be decomposed, there is utility in having a
 >>> complete integer.

 >> While fields can be crammed into a single unit and called an
 >> integer, the utility decreases as the size increases.  In the rare
 >> cases where there are significant advantages, such as
 >> cryptography, we can use explicit multiple-precision routines,
 >> rather than bloat the required language translator and library.

 > 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.

For example,  in tables with large numbers of entries, several bits
and small fields are often packed into a single word.  Sometimes they
are described in C by a struct declaration with bitfields, sometimes
with masks and shift constants to extract and set the fields.  This,
of course, can be expanded so that a 128 bit (or larger) area with
many fields is considered to be a large int, with lots of fields
packed in, extractable with masks and shifts and settable with shifts
+ add or OR.  At some point, the operations becomes more inefficient
than if the structure is declared explicitly and fields directly
accessed.  What is the point of supplying multiple-precision support
if most of the large ints are simply used as structures?

 > Second, it doesn't ``bloat'' the translator and library.  If you
 > call the multi-precision routines explicitly or implicitly, the
 > size of the library is the same.  If fact it is probably less in
 > some cases because the translator can generator better code than
 > the library.  The use of the translator might permit better
 > optimizations that had the programmer called library functions.
 > Also, the changes to the translator are small (see previous
 > posting on the thread ``long longs in c'').

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?

 > Third, the programmer doesn't get this right when he/she codes an
 > arithmetic expression as a bunch of function calls.  The use of an
 > inuitive syntax (i.e., arithmetic expressions) helps the
 > programmer avoid mistakes.

Granted, built in is easier to use than library calls.  I questioning
how often we need 128-bit int arithmetic.

 > You might ask why can't this be done as a class library in C++?
 > The answer is that the overloading feature is messed up.  You have
 > to extend the promotion rules by *itemizing* all the combinations.
 > This requires 1000's of function prototypes just to do arithmetic.
 > If you don't believe me, try implementing the *existing* C
 > arithmetic types (e.g., call them "c_int", "c_char", "c_float",
 > etc.) as a *quality* class library, i.e., something you'd actually
 > use rather than a toy program.  You'll find that the C++
 > overloading mechanism is not good for arithmetic types.

I believe you.  I once considered writing a parameterized fixed-point
class in C++ that could accept the number of bits and scaling factor
with the declaration, then have the compiler generate optimum
instructions for each fixed-point binary operator.  I soon decided
that C++ simply couldn't used the constant size and scale from the
declaration to generate optimum run-time code: I had to either offer
a small number of fixed size/scale combinations, each with a separate
class and with functions for all the combinations, or store the
size/scale in the data area, implementing, in effect, interpreted
floating point!

 > A good number of applications need more than 32-bits (heck, Bill
 > Gates needs more than 32-bits to store his net worth :-).
 > Applications *do* need 64-bits precision for time (e.g., POSIX
 > systems with incremental timers).

I can see that there is current use for 64-bit numbers.  I'm doubtful
of the need for required standard support for larger sizes now.

 > Crypto stuff needs more than this.

RSA needs 1000+ bits to be considered highly secure, but I don't
think this should force all implementations to support direct int
usage that large.

 > You keep saying that these applications don't exist, yet I keep
 > pointing out applications that do exist.  In each application, you
 > point to a work around which is just that: it may work, but it is
 > inconvenient.  The problem is that is inconvenient for many
 > people.  I think you need to make a stronger argument why you
 > believe that all the people persuing this should be no longer
 > interested in this feature.

There are several issues involved here.  First, an implementation
should directly support ints of the size provided directly by
hardware.  Currently this would map to type long and maybe int.  I
also see that it is useful to be able to select the various sizes
directly supported by hardware.  I understand from another post that
some machines support 8, 16, 32, and 64-bit arithmetic.  I think it
would be useful to have a way of requesting specific sizes.

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?

Thad