I believe it is relevant, as you stated, to obtain the correct time when
calculated on the fly.

However, if you do not intent to utilize this functionality (ever) then you
can trace down all associated components and either remove them or "jump"
around them.  BUT, what I would do (as I did this along time ago and fully
do not recall all of the details), I would trace out the calculations and
why the test is there in the first place and then I would recode it for the
SPARC chip.  Noting the issue of Big Endian verses Little Endian.  One needs
to be aware that the byte order as well as the size of int versus long are
significant.  I believe the SPARC chip is big endian, similar to the new
Intel Itanium2 chips.

So, to define (btw, I am not trying to insult anyone in anyway, but some
times this is a forgotten issue):

The adjectives big-endian and little-endian refer to which bytes are most
significant in multi-byte data types and describe the order in which a
sequence of bytes is stored in a computer's memory.
In a big-endian system, the most significant value in the sequence is stored
at the lowest storage address (i.e., first). In a little-endian system, the
least significant value in the sequence is stored first. For example,
consider the number 1025 (2 to the tenth power plus one) stored in a 4-byte
integer:

00000000 00000000 00000100 00000001 Address Big-Endian representation of
1025  Little-Endian representation of 1025
      00
      01
      02
      03 00000000
      00000000
      00000100
      00000001  00000001
      00000100
      00000000
      00000000


Many mainframe computers, particularly IBM mainframes, use a big-endian
architecture. Most modern computers, including PCs, use the little-endian
system. The PowerPC is bi-endian because it can understand both systems.

Converting data between the two systems is sometimes referred to as the NUXI
problem. Imagine the word UNIX stored in two 2-byte words. In a Big-Endian
systems, it would be stored as UNIX. In a little-endian system, it would be
stored as NUXI.

Note that the example above shows only big- and little-endian byte orders.
The bit ordering within each byte can also be big- or little-endian, and
some architectures actually use big-endian ordering for bits and
little-endian ordering for bytes, or vice versa.

So, the best solution is to understand what the test does, understand the
details of the chip architecture, and then to recode it for the SPARC chip,
not to jump around it.

Good Luck and Best Wishes coding,

Robert

P.S.  Obviously, if the bits and bytes are reordered, the time calculation
will surely suffer some inaccuracy :).

----- Original Message -----
From: "Dossy Shiobara" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, January 31, 2005 6:18 PM
Subject: Re: [AOLSERVER] Is AOLserver/Tcl 64-bit capable?


> On 2005.01.31, Robert Garron <[EMAIL PROTECTED]> wrote:
> >
> > I know, as I was one of the Alpha Developers that ran it on 64 Bit
> > Alpha very early on.... and it is still working better than fantastic.
> > I believe I ported it around 1995.
>
> Maybe you can help answer this question then:
>
> Is the test in nsd/tclobj.c:NsTclInitTimeType() for "sizeof(int) <
> sizeof(long)" still relevant?
>
> At least on 64-bit SPARC, sizeof(int) = 4 and sizeof(long) = 8, so this
> test fails, causing AOLserver to not start up.  Commenting out this test
> gives a server that starts and has the initial appearance of fully
> functioning, but I'm not sure what may/could break because of this.
>
> I'm guessing that this is only interesting in the case on a 64-bit
> system where the microseconds portion of the Ns_Time structure (long
> usec) is divided by a int and not a long, causing some kind of
> miscalculation?
>
> What problem do we risk facing on a platform where sizeof(int) !=
> sizeof(long) with regard to Ns_Time?
>
> -- Dossy
>
> --
> Dossy Shiobara                       mail: [EMAIL PROTECTED]
> Panoptic Computer Network             web: http://www.panoptic.com/
>   "He realized the fastest way to change is to laugh at your own
>     folly -- then you can let go and quickly move on." (p. 70)
>
>
> --
> AOLserver - http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to
<[EMAIL PROTECTED]> with the
> body of "SIGNOFF AOLSERVER" in the email message. You can leave the
Subject: field of your email blank.
>


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> 
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.

Reply via email to