Hi Bill,
Thanks for your work on making a more rugged Fortran-to-C interface for
the nhash function. I'm sure it will make a good addition to our code
base.
Here and elsewhere, as I'm sure you have long recognized, my approach
has often used quick-and-dirty approaches to test a new idea, make it
work, maybe tune it some for performance... and then, eventually, clean
up the code. Your efforts will be a big help, once again, in seeing
this sequence of steps through to the end.
Simple answer to your question about why this hash algorithm is used:
it's handy, fast, has been used in WSPR mode for > 5 years, and is
already present in the WSJT-X code base.
-- 73, Joe, K1JT
On 8/30/2015 4:48 PM, Bill Somerville wrote:
> Hi Joe,
>
> I note the changes around the nhash C function and despite it not being
> the root cause of the initially reported JTMSK crashes it seems
> appropriate to suggest that we make use of the Fortran/C
> interoperability features of modern Fortran to ensure that
> interoperation is more robust and potentially a little more efficient.
>
> As an example I have prepared a module the defines the interface to the
> nhash C function for calling from Fortran which looks like:
>
> module hashing
> interface
> integer(c_int32_t) function nhash (key, length, initval) bind(C,
> name="nhash")
> use iso_c_binding, only: c_ptr, c_size_t, c_int32_t
> type(c_ptr), intent(in), value :: key
> integer(c_size_t), intent(in), value :: length
> integer(c_int32_t), intent(in), value :: initval
> end function nhash
> end interface
> end module hashing
>
> This can be called without any extra wrapping code, argument
> manipulation or, function renaming and allows any contiguous block of
> memory that is represented by a Fortran scalar or contiguous vector to
> be hashed. For example in the source lib/hash.f90:
>
> subroutine hash(string,len,ihash)
> use iso_c_binding, only: c_loc
> use hashing
> parameter (MASK15=32767)
> character*(*), target :: string
> i=nhash(c_loc(string),len,146)
> ihash=iand(i,MASK15)
>
> ! print*,'C',ihash,len,string
> return
> end subroutine hash
>
> rather than the current copy to an integer array.
>
> A more complete patch is attached that uses the module to define the
> interface in all places nhash is called from Fortran.
>
> I have tested this patch in ^/branches/wsjtx_exp in a trivial back to
> back JTMSK QSO more as a test of building that a thorough regression test.
>
> I also wonder why the nhash algorithm has been used for a CRC on JTMSK
> messages since there are probably simpler well tried and tested CRC
> algorithms in common usage.
>
> Comments?
>
> 73
> Bill
> G4WJS.
>
> On 30/08/2015 15:47, Joe Taylor wrote:
>> Hi Steve,
>>
>> I was about to write to you along the same lines. The copies of nhash.h
>> and nhash.c in .../wsjtx_exp/lib have been used only for building the
>> executable testmsk, not for wsprx. I was clearly on the wrong track
>> yesterday.
>>
>> It turns out, I believe, that the problem is entirely elsewhere. Under
>> certain conditions an undefined value for TRperiod could be passed to
>> function getfile(), which is used to read *.wav files from disk. As a
>> consequence a big memory segment could be zeroed when this statement
>> (line 56 of getfile.cpp) was executed:
>>
>> memset(jt9com_.d2,0,2*npts);
>>
>> I have now protected against this occurrence. Please try building and
>> testing revision 5831.
>>
>> -- Joe, K1JT
>>
>> On 8/30/2015 10:15 AM, Steven Franke wrote:
>>> Joe -
>>>
>>> In perusing the wsjtx_exp code this morning, I noticed two things:
>>>
>>> 1. All references to nhash.c in CMakeLists.txt are to the version in
>>> /lib/wsprd - so it seems that changes in /lib/nhash.c are not going
>>> to make any difference. If this is working for you, then perhaps we
>>> can just delete the nhash.c/nhash.h in /lib?
>>>
>>> 2. in /lib/nhash.h, length is declared size_t in nhash and uint32_t
>>> in nhash_, whereas in /lib/nhash.c is it uint32_t in nhash.c and
>>> uint32_t in nhash_
>>>
>>> I’m guessing that item 2 is not the problem due to item 1?
>>>
>>> I think that we need to resolve the differences between the two
>>> nhash.c’s and get rid of one of them.
>>>
>>> Steve
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> wsjt-devel mailing list
>>> wsjt-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
