Specific 32-bit to 64-bit conversion questions

I was looking at taking the next step to 64-bit. Handling changes to window and control handles is just slogging through, finding and redeclaring them. My questions go deeper.

1. I use the expression core4(loc(abcd)) where abcd is a logical*4 as a winio@() argument to pass along a logical for %rb's. Will this still work?

2. I use %ud to attach to a control or window the address of a variable, string, or user-defined TYPE. I think %ud is restricted to 32-bits; is that correct? I use clearwin_info@() to get the value of the user data, then use allocate with absolute_address= if I am passing an address of something.

3. Sometimes, when using a %ud, I modify directly using the syntax of

   abcd = clearwin_info@('USER_DATA') core4(abcd) = value

This question is linked to the one above.

4. I use SCC to compile code written in 'C' and C++ that is critical to my system. Would compiling with /64 create 64-bit object modules?

These are all the things I can find to ask about at this time.

Bill

Ignoring the Fortran standard issues, there is some safety in 'supplying' integer*8 or integer(7) variables in /64 as they will work for both 4-byte and 8-byte use. (Providing an 8-byte storage means there will be no corruption of other near variables) The main problem is reviewing the returned values when only a 4-byte value is returned. This can be overcome by initialising 8-byte values to zero, before their address is provided. Not sure about 'core4(loc(...))' as loc is 8-byte, although I have not used core4 in 64-bit.

John, thanks for the reply.

My biggest fear is exactly what you've mentioned here, that is; I assume a 32-bit address, but it is into the 64-bit realm, and not actually pointing to the desired data.

The rest of the conversion doesn't cause me any issues!

Thanks for joining in!

Is there a CORE7 ? This might cope with mixing 32-bit and 64-bit code development, assuming this is an actual problem.

John, there is no core7. There is a pcore7() for pointer assignments. It was designed to work the same way in 32- or 64-bit environments.

Yes, actually, it is a real problem. And there is probably a real answer. I'm not 'mixing'; I have developed in a 32-bit environment and knowing what to expect is part of a 64-bit transition. If/When I go 64-bit, it'll be full in. Just some questions that need resolution to know if it will be possible.

Bill

Bill

1. core4(loc(abcd)) should work. An alternative is to use an EQUIVALENCE or the TRANSFER intrinsic function.

2. %ud expects an INTEGER(7) value whilst clearwin_info@ returns an INTEGER(7) value. So they work together.

3. This should work provided that abcd is INTEGER(7) and value is INTEGER*4.

4. You can use /64 with SCC but it is not fully developed and not yet fully supported. You may get spurious warnings (which you can ignore). If it fails, we will aim to investigate but without obligation.

Paul, thanks foir the reply. It is nice to know what I suspected would be true regarding INTEGER(7) for the clearwin functions.

I am uneasy about your SCC comments. My PDF report interface and two sets of coordinate conversion code relies on SCC. I'll place my emphasis there before I tackle the Fortran side. If successful (or not), I'll let you know what I find.

I'm just happy I removed all code/edoc constructs a while back!