[TCLCORE] RE: [TCLCORE] Re: 64 bit numbers

[Don B. <do...@pi...>]

I guess I misunderstood what the intent of the roadmap
was, but I'm not sure I agree with you here. Let me 
explain my reasoning.

I am running tcl on a 64-bit platform that uses 32-bit
addressing (64-bit addresses are quite large after
all). This isn't that uncommon, there's lots of Unix
systems running with 32-bit addressing that have 64-bit
integer instructions available. The Pentium on which
Windows is based has some 64-bit integer abilities.

I need to have 64-bit integer arithmetic available
in expr & format for interoperability with external
tools that use 64-bit results. In my case its part
of a network testing environment where 64-bit counters
are used, and I need to do rate calculations. I can
do this using mpexpr, but its quite slow, and I can't
get the performance I need. I think there are a few
packages that could use this, scotty & tclblend are 2 
that spring to mind.

Also, it would be nice if a script could be portable
between systems with 64-bit and 32-bit capabilities
without having to worry about the precision of
an integer.

What I would like to do is take on the work to
formalise the use of integer types in Tcl to a new
typedef, so that the size of the integer does not
change based on the host platform it is compiled for.
This means that I have to fix the places that 'int'
is used, 'long' is used, unsafe casts are made, implement
a 64-bit safe strtoul, strtol, format, etc.
The two obvious approachs are binary-compatible (keep
int & long as the current platform size, add a new
set of 64-bit functions), or binary-incompatible
(force the 'int' to 32-bit, the 'long' to 64-bit or
somesuch). The pro & cons for each are fairly
obvious: binary-incompatible -> need to recompile extension,
but all extensions can get 64-bit without code change,
binary-compatible -> more work, extensions need
code changes to use, but don't have to be recompiled.

So far the votes seem to indicate the binary 
compatible approach is prefered.

Checking Tcl user-group history, the 64-bit integer
capability is asked about fairly often.

Being 64-bit addressing safe is also a valuable thing 
to have, unfortunately its not an area I have the equipment
to contribute in.

-----Original Message-----
From: Eric Melski [mailto:er...@aj...]
Sent: July 23, 2000 2:47 PM
To: Don Bowman
Cc: tc...@po...
Subject: [TCLCORE] Re: 64 bit numbers on IA32



I don't think it's necessary or advisable to make Tcl support 64-bit
integers on a 32-bit platform.  It seems like the amount of effort and the
degree to which backwards compatibility would be affected does not justify
the benefits.  If you need 64-bit integers, you should move (or are
probably already running on) a 64-bit platform.  Our focus for extending
64-bit support in Tcl should be on making sure that Tcl works properly on
64-bit platforms.  This means that code that uses integers as pointers,
for example, has to be corrected to use real pointers (since pointers on a
64-bit platform are 64-bit, while integers are likely 32-bit).  Similarly,
code that uses integers for file offsets should use size_t instead, for
the same reasons.  This is really what the intention of the "improve
64-bit support" line-item on the 8.4 roadmap was referring to, I believe.

   Eric Melski                            The Other Tcl Guy
   ericm at ajubasolutions.com            Ajuba Solutions




--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.