Tim:
> Ah, excellent. I appreciate that rule of thumb. Just to confirm, you're
> saying you don't expect it to matter if those "long" variables end up being
> 32-bits even in a 64-bit compile of Judy? The definition of Word_t is the
> only one I should need to fix?
Yes, I confirm. Even 16 bits (short) is probably enough, but would be slower
in some processors/compiled code.
The definition of Word_t must pass this: assert(sizeof(Word_t) == sizeof
(void *); or Judy will not work.
Also, if this does not pass, Judy will not work: assert(sizeof(jp_t) == (2 *
sizeof(void *)));
> Are you saying it will be better for clarity if the Win64 Word_t definition
> says "uint64_t" instead of "long long"? In other words:
a Word_t is a uint64_t in a 64 bit compile and a uint32_t in a 32 bit compile.
A long long is a typo in my mind. Your
#ifndef _WORD_T will probably work in windows, but I prefer using uint64_t if
possible.
I suspect that even a #define for 64 bits is still not standard, so kluges
continue. In the new Judy all compiles
fail without a #define JU_64BIT or/(but not and) a #define JU_32BIT. That was
a big mistake I
made on JudySL. The lack of a #define JU_64BIT or -DJU_64BIT will compile
64bit, but fail on execution.
Looking forward to your windows changes.
Thanks for your interest,
doug
P.S. It has been suggested that the 4 JudyxTables.c files be delivered,
rather than constructed.
I give them the names: JudyLTables32.c, JudyLTables64.c, Judy1Tables32.c and
Judy1Tables64.c
in the new Judy. But I still use the JudyTables.c tool to construct them.
Doug Baskins <[email protected]>
>________________________________
> From: Tim Margheim <[email protected]>
>To: [email protected]
>Sent: Monday, October 22, 2012 2:04 PM
>Subject: Re: JudySL with 64-bit pointers as values
>_WORD_T
>
>On 10/22/2012 12:34 PM, Doug Baskins wrote:
>
>Tim:
>>
>>
>>As a rule or thumb, I never use native C types (char, int, long, long long)
>>
>>except when it simply does not matter, such as the case you sited or when
>>there is no choice.
>>
Ah, excellent. I appreciate that rule of thumb. Just to confirm, you're
saying you don't expect it to matter if those "long" variables end up being
32-bits even in a 64-bit compile of Judy? The definition of Word_t is the only
one I should need to fix?
>
>When Microsoft decided to require a uint64_t to be "unsigned long long",
>>I figured they would fix that mistake eventually. At that
time an uint32_t and
>>uint64_t had not been defined in a consistant place. I
hope it is now in <stdint.h>.
>>
I found a discussion on StackOverflow. Visual Studio 2003-2008 lacked a
<stdint.h>, but it is now included in VS2010.
>http://stackoverflow.com/questions/126279/c99-stdint-h-header-and-ms-visual-studio#2628014
>
>Are you saying it will be better for clarity if the Win64 Word_t
definition says "uint64_t" instead of "long long"? In other words:
>
>#ifndef _WORD_T
>#define _WORD_T
>#ifndef _WIN64
>typedef unsigned long Word_t, * PWord_t; // expect 32-bit or
64-bit words.
>#else
>typedef uint64_t Word_t, * PWord_t; // In 64-bit Windows, we need
to explicitly specify a 64-bit word, since "long" doesn't scale in
_WIN64.
>#endif
>#endif
>
>That looks like it should work, and I like the self-documentation of
an explicit "uint64_t".
>
>
>While I am reminiscing, I will mention some things about 1.0.5 Judy. [...]
>>
Thanks for those details.
>
>
>
>>The next version of Judy does not use "byte" accesses and [...]
>>
The faster version you're working on for future release? Can't wait.
>
>
>I would be willing to make a version 1.0.6 of Judy, if someone would submit
>>(for Microsoft) the fixes and test it. I do not have a Microsoft Windows
>>
>>development path. Last time I checked, I could not afford it.
>>
I'm more than happy to do that. With the help of some of John Skaller's
suggestions, I'm working out a configuration that leaves the source untouched
(except for the Win64 tweak to the Word_t definition in Judy.h), and allows for
easy use with Visual Studio. Ideally, any the Windows-specific or VS-specific
files will be in a separate sub-folder in the repository.
>
>I think I can make a "vsbuild.bat" as an alternative to "build.bat",
using Visual Studio's command-line compiler. Along these lines:
>http://stackoverflow.com/questions/84404/using-visual-studios-cl-from-a-normal-command-line
>
>I haven't worked with VS's command-line compiler before, so I'm
still figuring out the cleanest way to handle the *.lib and *.dll
files. I may be able to use your build.bat mostly as-is, or I may
need to make a *.sln solution/project file.
>
>
>I am a one-person developer inretirement. Judy is still my passion and I
>>
>>am actively working on a much fasterversion.
>>
And I greatly appreciate it. I hope this'll work out to make Judy more
easily-available to Windows developers.
>
>I do have access to a couple test computers with Visual Studio 2003
and 2008 Express installed, so I'll be able to test it with them,
too.
>
>
>PS. If I remember correctly, Windows does not pack structures by default.
>Make
>>sure that the struct jp_t is 8 or 16 bytes in size with 32 and 64 bit
>>compiles respectively.
>>
>>I.E. assert(sizeof(jp_t) == 16);assert(sizeof(Word_t) == 8); in the 64bit
>>compile.
>>
Will do.
>
>
>---
>Tim Margheim
>Neuric Technologies, LLC
>
>
>------------------------------------------------------------------------------
>Everyone hates slow websites. So do we.
>Make your web apps faster with AppDynamics
>Download AppDynamics Lite for free today:
>http://p.sf.net/sfu/appdyn_sfd2d_oct
>_______________________________________________
>Judy-devel mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/judy-devel
>
>
>------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Judy-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/judy-devel
