Home > Archive > Tcl > May 2004 > Any plan for win64 support in Tcl??
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Any plan for win64 support in Tcl??
|
|
| lihong pei 2004-05-13, 7:32 pm |
| Hi,
I don't know whether this is the correct mailing list to ask. If not,
could someone point me to the correct list?
I tested the Tcl 8.4.6 and Tcl 8.5a1, neither has been ported to win64
platform yet. The test driver is command 'expr int(0xffffffff)'. On
64bit platform, it should return a large number in stead of -1.
Anyone knows whether there is a plan for porting to win64 platform? If
yes, which release?
Thanks,
Lihong
| |
| Robert 2004-05-13, 8:31 pm |
| lihong pei wrote:
> Hi,
> I don't know whether this is the correct mailing list to ask. If not,
> could someone point me to the correct list?
> I tested the Tcl 8.4.6 and Tcl 8.5a1, neither has been ported to win64
> platform yet. The test driver is command 'expr int(0xffffffff)'. On
> 64bit platform, it should return a large number in stead of -1.
>
> Anyone knows whether there is a plan for porting to win64 platform? If
> yes, which release?
>
> Thanks,
>
> Lihong
>
This is from the ActiveState site:
# 64-bit file system support (where the OS supports it)
# 64-bit expr support at the Tcl level (even on 32-bit OSes)
Not sure why you get any different as I know nothing of Tcl on 64-bit
platforms.
| |
| David Gravereaux 2004-05-13, 9:31 pm |
| lihong pei <lihong.pei@xilinx.com> wrote:
>expr int(0xffffffff)
int() is compiler specific, I think. so if tcl was compiled for 32..
Try wide() instead.
--
David Gravereaux <davygrvy@pobox.com>
[species: human; planet: earth,milkyway(western spiral arm),alpha sector]
| |
| Jeff Hobbs 2004-05-14, 12:31 am |
| lihong pei wrote:
> I don't know whether this is the correct mailing list to ask. If not,
> could someone point me to the correct list?
> I tested the Tcl 8.4.6 and Tcl 8.5a1, neither has been ported to win64
> platform yet. The test driver is command 'expr int(0xffffffff)'. On
> 64bit platform, it should return a large number in stead of -1.
Tcl works just fine on Win64. ActiveState supports it through
enterprise support, but we've commited all the necessary core
changes to have it work there. FWIW, I did the original port to
Win64 as well.
The above is likely wrong (or rather correct, but not what you
wanted) because you are using a 32-bit build of Tcl on Win64,
which works just fine as well. If you want a true 64-bit build,
then you have to compile specially for it.
--
Jeff Hobbs, The Tcl Guy
http://www.ActiveState.com/, a division of Sophos
| |
| Donal K. Fellows 2004-05-14, 6:32 am |
| lihong pei wrote:
> I don't know whether this is the correct mailing list to ask. If not,
> could someone point me to the correct list?
No, this is a fine place to ask for now. I warn you that although I'm
the person mostly to blame for Tcl's 64-bit support, I do not have
access to any Win64 system so I can't verify many things directly.
> I tested the Tcl 8.4.6 and Tcl 8.5a1, neither has been ported to win64
> platform yet. The test driver is command 'expr int(0xffffffff)'. On
> 64bit platform, it should return a large number in stead of -1.
>
> Anyone knows whether there is a plan for porting to win64 platform? If
> yes, which release?
Well, it'd certainly help *me* if you could define "ported to win64"
and clarify why you think the current Tcl core is not ported to it.
On the specific point you raise, IIRC Win64 compilers define 'long' as
a 32-bit type (and the int() conversion function in Tcl uses a cast to
'long' internally) which is behaviour that is quite distinct from
other 64-bit platform build environments (e.g. Solaris and IRIX.)
Could you try the following instead:
expr wide(0xffffffff)
That should not produce a negative number; if it does, it's a bug. :^)
Donal.
| |
| Donald Arseneau 2004-05-14, 7:31 am |
| donal.k.fellows@man.ac.uk (Donal K. Fellows) writes:
> On the specific point you raise, IIRC Win64 compilers define 'long' as
> a 32-bit type
Gag!
Donald Arseneau asnd@triumf.ca
| |
| Donal K. Fellows 2004-05-14, 7:31 am |
| Donald Arseneau wrote:
> donal.k.fellows@man.ac.uk (Donal K. Fellows) writes:
> Gag!
Or at least I think that's the case. One of these "it makes life easier
for people porting code to the new platform" cases coupled with the Win
API not being very type-clean. :^/
Donal.
| |
| lihong pei 2004-05-14, 9:31 pm |
| Donal, Jeff and All,
"Donal K. Fellows" wrote:
> lihong pei wrote:
>
> No, this is a fine place to ask for now. I warn you that although I'm
> the person mostly to blame for Tcl's 64-bit support, I do not have
> access to any Win64 system so I can't verify many things directly.
>
>
> Well, it'd certainly help *me* if you could define "ported to win64"
> and clarify why you think the current Tcl core is not ported to it.
>
> On the specific point you raise, IIRC Win64 compilers define 'long' as
> a 32-bit type (and the int() conversion function in Tcl uses a cast to
> 'long' internally) which is behaviour that is quite distinct from
> other 64-bit platform build environments (e.g. Solaris and IRIX.)
> Could you try the following instead:
> expr wide(0xffffffff)
> That should not produce a negative number; if it does, it's a bug. :^)
We compiled Tcl8.4.6 source on 64bit opteron machine with 64bit compiler
from microsoft. The above result is from a 64bit build. Looking into Tcl
source code, there are functions and types using 'long'. As Donal mentioned,
Win64 compiler defines 'long' as 32-bit type and a real 'long' type in
Win64 is actually 'long long', which is 64-bit. This is not the case for
Solaris and linux as the 'long' is actually 64bit there.
I tried expr int(0xffffffff) on 64bit solaris and 64bit linux, both return a
big number. It's only on win64, -1 is returned.
expr wide(0xffffffff) will return a big number on all the platforms,
including both 32bit and 64bit platforms.
I think the result for expr wide(0xffffffff) is correct, since it matches
the online documentation.
We actually did an global replacement of 'long' with 'long long' and
recompiled Tcl source on 64bit windows. The result of expr wide(0xffffffff)
is then a large number, instead of -1. This shows that the current version
of Tcl source is not fully ported to win64 yet.
>
>
> Donal.
Thanks,
Lihong
| |
| Jeff Hobbs 2004-05-14, 11:32 pm |
| Donal K. Fellows wrote:
> Donald Arseneau wrote:
>
>
>
> Or at least I think that's the case. One of these "it makes life easier
> for people porting code to the new platform" cases coupled with the Win
> API not being very type-clean. :^/
That's correct, Win64 is one of the rare 64-bit OSes that is P64
or IL32P64 (int long 32-bit, pointer 64). Most unix OSes are LP64
(long and pointer 64), and a few are ILP64.
--
Jeff Hobbs, The Tcl Guy
http://www.ActiveState.com/, a division of Sophos
| |
| Jeff Hobbs 2004-05-14, 11:32 pm |
| lihong pei wrote:
[color=darkred]
> We compiled Tcl8.4.6 source on 64bit opteron machine with 64bit compiler
> from microsoft. The above result is from a 64bit build. Looking into
> Tcl source code, there are functions and types using 'long'. As Donal
> mentioned, Win64 compiler defines 'long' as 32-bit type and a *real*
> 'long' type in Win64 is actually 'long long', which is 64-bit. This is
It's actually int64 on Windows, 32 or 64-bit. And my guess would
be that you didn't actually compile it with the right settings. I
was not aware that Microsoft had finally released any 64-bit OS for
Opteron. This is their latest official stance:
http://support.microsoft.com/defaul...kb;en-us;826447
So you either have a prerelease, which is possible and should be
clearly stated, or you are thoroughly  . Furthermore, the
compiler setup for compiling 64-bit apps is a cross-compile style
setup by default. If you can be *very* *exact* in what you did to
configure and build the core, that will get us somewhere.
As I did the port myself, I know full well that it is 100% ported
and correct - but only if you build it right.
--
Jeff Hobbs, The Tcl Guy
http://www.ActiveState.com/, a division of Sophos
| |
| Chang LI 2004-05-16, 12:31 pm |
| lihong pei <lihong.pei@xilinx.com> wrote in message news:<40A56815.D8CD7C5B@xilinx.com>...
Right. Win64 long is 32-bit and Linux/Unix64 long is 64-bit.
The long type can be replace by wide type in Tcl for both win64/lin64 compatible.
> We compiled Tcl8.4.6 source on 64bit opteron machine with 64bit compiler
> from microsoft. The above result is from a 64bit build. Looking into Tcl
> source code, there are functions and types using 'long'. As Donal mentioned,
> Win64 compiler defines 'long' as 32-bit type and a real 'long' type in
> Win64 is actually 'long long', which is 64-bit. This is not the case for
> Solaris and linux as the 'long' is actually 64bit there.
> I tried expr int(0xffffffff) on 64bit solaris and 64bit linux, both return a
> big number. It's only on win64, -1 is returned.
> expr wide(0xffffffff) will return a big number on all the platforms,
> including both 32bit and 64bit platforms.
> I think the result for expr wide(0xffffffff) is correct, since it matches
> the online documentation.
> We actually did an global replacement of 'long' with 'long long' and
> recompiled Tcl source on 64bit windows. The result of expr wide(0xffffffff)
> is then a large number, instead of -1. This shows that the current version
> of Tcl source is not fully ported to win64 yet.
>
>
>
> Thanks,
>
> Lihong
>
>
> --
| |
| lihong pei 2004-05-18, 9:32 pm |
| Hi, Jeff,
Jeff Hobbs wrote:
> lihong pei wrote:
>
>
> It's actually int64 on Windows, 32 or 64-bit. And my guess would
> be that you didn't actually compile it with the right settings.
The compiler flag I use are '-DBUILD_tcl -DTCL_PIPE_DLL=\"tclpip84.dll\" ' plus
the standard C flags like ' -nologo -MD -Ox' as well as our own 64bit windows
flag. Basically, the flags we use are similar to that of 32bit compiling on
windows.
Investigating the problem of 'expr int(0xffffffff)', the problem is inside
ExprIntFunc() implementation, where the result from the calculation is correct,
however, it is the following Tcl_NewLongObj(iResult)) call, a long (32bit)
value is stored inside internalRep.longValue.
I think long type in the Tcl source did cause problem since when I replace them
with long long things work correctly.
> I was not aware that Microsoft had finally released any 64-bit OS for
> Opteron. This is their latest official stance:
>
> http://support.microsoft.com/defaul...kb;en-us;826447
>
> So you either have a prerelease, which is possible and should be
> clearly stated, or you are thoroughly . Furthermore, the
> compiler setup for compiling 64-bit apps is a cross-compile style
> setup by default. If you can be *very* *exact* in what you did to
> configure and build the core, that will get us somewhere.
We actually use the beta-version of 64bit microsoft compiler on a beta-version
64bit opteron machine. We did compile and run other open source like Apache's
Xercesc.
>
>
> As I did the port myself, I know full well that it is 100% ported
> and correct - but only if you build it right.
>
> --
> Jeff Hobbs, The Tcl Guy
> http://www.ActiveState.com/, a division of Sophos
Thanks,
Lihong
| |
| Jeff Hobbs 2004-05-19, 2:31 am |
| lihong pei wrote:
> Jeff Hobbs wrote:
[color=darkred]
> Investigating the problem of 'expr int(0xffffffff)', the problem is inside
> ExprIntFunc() implementation, where the result from the calculation is correct,
> however, it is the following Tcl_NewLongObj(iResult)) call, a long (32bit)
> value is stored inside internalRep.longValue.
> I think long type in the Tcl source did cause problem since when I replace them
> with long long things work correctly.
The only problem here is in assuming that you should get LP64 behavior
out of a P64 OS. Win64 is P64 - that means only pointers are 64-bits.
ints and longs are the same size, so you should see the same
characteristics with them as on 32-bit Windows.
--
Jeff Hobbs, The Tcl Guy
http://www.ActiveState.com/, a division of Sophos
|
|
|
|
|