cast U64 Long Long

[lmd2]

sorry to have lapsed my input; my client shuts down the first week of July and I can not offer any direction on how the time tag is used,
there is also an older function in the DLL which returns a 32 bit time tag - that function works fine (32 bit being straight forward) but the values returned always appear random to me -
when I meet with the client on Monday I will try to determine the significance, and use of this value.
Thanks for your input and insights, I will elaborate on this come Monday.

[tbd]

smercurio_fc wrote:

---

tbd wrote:

---

smercurio_fc wrote:

The point of using the DBL datatype was to use an 8-byte datatype since 7.0 doesn't have a U64.

That's the part I didn't understand - why expose the 8 bytes as a double - which is useless in 7.0.

An array of U32s (instead) can be quickly converted to an EXT

---

You are basing this on an assumption of what the user is trying to do.

I based my reply (above) on the original post - which seems to be quite explicit:

"function returns a *pointer to a U64 (which is cast and in C referred to as Long Long). In LabVIEW 7.0 how would I type cast this?

"

This is a very simple task, despite doubts and assumptions to the contrary.

Message Edited by tbd on 07-05-2008 10:55 PM

[tst]

Not having read the thread thoroughly, I'm not sure if this will help, but it does show that the DBL method is recommended and it does give further examples of working with 64 bit DLLs in 7.x.

[smercurio_fc]

---

@tbd wrote:

I based my reply (above) on the original post - which seems to be quite explicit:

"function returns a *pointer to a U64 (which is cast and in C referred to as Long Long). In LabVIEW 7.0 how would I type cast this?

"

This is a very simple task, despite doubts and assumptions to the contrary.

---

Well, you can't can't pass an EXT to the Call Library Function Node function. For a numeric parameter the largest that you can use is an 8-byte DBL You would need to use coercion or do the data type conversion to go from an EXT to a DBL, and then from a DBL to an EXT. Your main argument is that in order to perform integer math the EXT is better:

---

Though the DBL is 8 bytes, its binary representation only has a 54-bit mantissa, so you'll loose about 10 bits of precision when doing integer math,  However, the EXT has a 64bit mantissa, so can accurately handle the U64.

---

As I already pointed out, I wasn't recommending to do any integer math on the DBL. I have no idea what the user is trying to do with this number. If it's just passing the value onto another function, it gains you nothing to use an EXT. If you want to do integer math, it's a different story. At that point, though, I would argue that you're better off upgrading rather than messing around with converting between EXT/DBL and clusters and/or arrays of U32s/U8s.

[tbd]

Hi tst,

      Your link is definately on topic, but I think there's good reason question the advice there - at least if we're talking about 64bit integers.

"You can represent a 64-bit number by a cluster of two 32-bit numbers. Mathematical operations between 64-bit numbers can be coded using well-known algorithms for arbitrary precision arithmetic. These algorithms are beyond the scope of this paper..."

They're saying to use, and do math on, 64bit numbers as clusters (in LV 7.x and earlier.)  To calculate the difference in time between two 64bit timestamps one would create special functions to handle cluster-operands and which employ "well-known algorithms for arbitrary precision arithmetic".

Sounds like a lot of work compared to simply subtracting one EXT from another.

[smercurio_fc]

Correction to my previous response: You can actually pass an EXT to a DLL. You just have to select "Adapt to Type" rather than explicitly selecting "Numeric" as the type.