Hi, In order to be able to implement a parent and child context mechanism (https://www.ibm.com/developerworks/community/forums/html/threadTopic?id=0a1dc1ee-cd96-411e-9e19-f53899e7ffd7&ps=25) I have to consider a memory hack to make that available in a DOORS 64bit environment.
Actually my development environment is on a 32bit DOORS environment... I would like to keep this environment... It is why I'm wondering if it exists a possible way to make the same DXL code available on both platforms. I have an idea, but since I don't have a 64bit environment to test it I would like to have the community opinion :
In the top level context (startup) I create a global Skip list: Skip A_VAR_LIST = create() In a DXL context (the primary one), I create a DxlObject (an example of a variable to be read by a child context) and I put it in global Skip list:
int aLogicalID = 1234
DxlObject aVariableToTransfer = new
put(A_VAR_LIST, aLogicalID, aVariableToTransfer)
// bla bla to define the structure of the aVariableToTransfer DxlObject variable
string code = "
DxlObject transferedVariable = null
find(A_VAR_LIST, "aLogicalID", transferedVariable)
"
eval_ code
Does transferedVariable corresponds to aVariableToTransfer if executed into a 64bit DOORS ?
In that case I don't use the int to string conversion function (::.. (int, string) ), and may be it works in 64 bit... But honestly I'm not very sharp in DXL language behavior to be sure. Thank for your help regards. Joseph jaracic - Thu Sep 22 08:27:23 EDT 2016 |
Re: potential tips to avoid 64bit Memory hack to work around the int to string conversion function (::.. (int, string) ) AFAIK with 1234 you won't have a problem. The problem comes with integers outside the range -0x7FFFFFFF ... 0x7FFFFFFF or -2147483647 to +2147483647. |
Re: potential tips to avoid 64bit Memory hack to work around the int to string conversion function (::.. (int, string) ) Mike.Scharnow - Thu Sep 22 08:36:40 EDT 2016 AFAIK with 1234 you won't have a problem. The problem comes with integers outside the range -0x7FFFFFFF ... 0x7FFFFFFF or -2147483647 to +2147483647. Does it means that until my index of variable is inside the right range (obsolutely no problem to deal with this constraint ;-) ) the address of the variable (Skip data) is correctly "managed" by the child context ? If yes, it means I found a workaround to "transfer" a variable address in a child context into 64 bits DOORS |
Re: potential tips to avoid 64bit Memory hack to work around the int to string conversion function (::.. (int, string) ) jaracic - Thu Sep 22 10:56:52 EDT 2016 Does it means that until my index of variable is inside the right range (obsolutely no problem to deal with this constraint ;-) ) the address of the variable (Skip data) is correctly "managed" by the child context ? If yes, it means I found a workaround to "transfer" a variable address in a child context into 64 bits DOORS Well, at least that's how I read https://www.ibm.com/developerworks/community/forums/html/topic?id=c672482d-1470-4ed3-9f66-4160f0ed75e6. In our code, we have been passing parameters directly, using the addr_ syntax as described in this post, the code is the same for 32bit and 64bit, and we had no problems beside some pointers being larger than the 32 bit max value. For security reasons (the eval'ed code is provided by the end user and we do not want them to mess with our internal variables) we have not used global variables, so I cannot present any experience on this, but the method to pass integers using the int to string method definitely works for 32bit integers
|
Re: potential tips to avoid 64bit Memory hack to work around the int to string conversion function (::.. (int, string) ) Mike.Scharnow - Thu Sep 22 11:28:54 EDT 2016 Well, at least that's how I read https://www.ibm.com/developerworks/community/forums/html/topic?id=c672482d-1470-4ed3-9f66-4160f0ed75e6. In our code, we have been passing parameters directly, using the addr_ syntax as described in this post, the code is the same for 32bit and 64bit, and we had no problems beside some pointers being larger than the 32 bit max value. For security reasons (the eval'ed code is provided by the end user and we do not want them to mess with our internal variables) we have not used global variables, so I cannot present any experience on this, but the method to pass integers using the int to string method definitely works for 32bit integers
Yes. The easiest way to check for a 32 bit platform is to calculate something like 0xFFFFFFFF + 1 which is 0 on a 32 bit framework (overflow) but not on a 64 bit machine. But I think the code from that post should almost work for 32 and 64 bit ... For 32 Bit you need to adapt the getHighInt function to prevent a division by zero error. *** NOTE: THIS IS NOT APPLICABLE FOR DOORS 9.6.1.7 ***
int SHIFT4 = 256*256*256*256; /// 0 on 32 bit!!
int LOWMASK = 0xFFFFFF*256 + 255;
int PROBLEMVAL = 0x7FFFFFFF + 1;
int makeInt64 (int low, int high) {
// not needed for 32 bit, but works, since SHIFT4 is 0!
// therefore this will reduce to the low dword!
return (low & LOWMASK) + (high & LOWMASK) * SHIFT4;
}
int getLowInt (int &ref) { return ref & LOWMASK; }
// Here is the problem: / SHIFT4 will yield a division by zero error
// Here you might need to check and return 0
int getHighInt (int &ref) { return (ref / SHIFT4) & LOWMASK; }
Buffer bufLit = create();
string save32BitLiteral (int val) {
// This function should also work on 32 bit
setempty(bufLit);
int l = getLowInt val;
int h = getHighInt val;
if (l == PROBLEMVAL) bufLit += "((-0x7FFFFFFF - 1)" else bufLit += "((" l "&(0xFFFFFF*256+255))";
if (h == PROBLEMVAL) bufLit += "+(-0x7FFFFFFF - 1))" else bufLit += " + (" h "*(0xFFFFFF*256+256)))";
return stringOf bufLit;
}
So I would recomment always using the addr_ approach instead of a global variable and use save32BitLiteral function, adapted to check for 32 bit and avoid the high dword. Regards. Mathias |