I know there must be a few "Hitchhikers Guide to DOORS 32-bit to 64-bit DXL function Conversion" posts out there. I saw Mathias had a few. Did IBM publish a transition guide? I think I get it it but want to keep "re-inventing the wheel" to a minimum. Does this code FROM/TO cover the basic idea? I have needs to bounce back and forth between the address (reference) and value domains from time to time. // _Addr64Test /* _Addr64Test */ void debugLog(string msg) { print(msg "\n"); } //------------------------------------------------------------------------------ // Old way for 32-bit -- Get 32 bit address of anything //------------------------------------------------------------------------------ int* intStarAddressOf(_m &v) { int *val = &(addr_ (int (addr_ (v)))); return (val); } int addressOfVar(_m& anyVar) { int temp = (int addr_ intStarAddressOf(anyVar)); return temp; } //------------------------------------------------------------------------------ // Replacement way for 64-bit (DOORS 9.6.1.8) -- Get 64 bit address of anything //------------------------------------------------------------------------------ Addr64_* int64StarAddressOf(_m &v) { Addr64_* val = &(addr_ (Addr64_ (addr_ (v)))); return (val); } Addr64_ addressOfVar(_m& anyVar) { Addr64_ temp = (Addr64_ addr_ int64StarAddressOf(anyVar)); return temp; } void main() { real r = 3.14; int a = 123; int b = 456; char c = 'c'; char d = 'd'; debugLog("r = " r ""); debugLog("a = " a ""); debugLog("b = " b ""); debugLog("c = " c ""); debugLog("d = " d ""); debugLog("We see even char addresses are spaced 8 bytes apart"); debugLog("r* = " addressOfVar(r) ""); debugLog("a* = " addressOfVar(a) ""); debugLog("b* = " addressOfVar(b) ""); debugLog("c* = " addressOfVar(c) ""); debugLog("d* = " addressOfVar(d) ""); } pragma runLim, 100000000 main(); Output is: r = 3.140000 a = 123 b = 456 c = c d = d We see even char addresses are spaced 8 bytes apart r* = 497749256 a* = 497749264 b* = 497749272 c* = 497749280 d* = 497749288 This seems to work fine. Similar functions worked fine for 32-bit. If this captures the basic change philosophy or if anything is more complicated than necessary, please advise before I change lots of code.
Thanks for reading. Fu Lin Yiu - Wed Aug 02 04:46:48 EDT 2017 |
Re: Guidelines for 32-bit to 64-bit Conversion Why woould you need a pointer to an Addr64 ? Shouldnt this do it just fine? Addr64_ int64StarAddressOf(_m &v) { Addr64_ val = addr_ v return (val); } Regards, Mathias |
Re: Guidelines for 32-bit to 64-bit Conversion Mathias Mamsch - Wed Aug 02 09:01:23 EDT 2017 Why woould you need a pointer to an Addr64 ? Shouldnt this do it just fine? Addr64_ int64StarAddressOf(_m &v) { Addr64_ val = addr_ v return (val); } Regards, Mathias Mathias, I concur that in this context Addr64_ is fine. COMMENT: Sometimes I use different "pointer to some type" to narrow variables down to target different overloaded functions (e.g., int*, char*, real*). This was not necessary here. What I am still interested in is "Are there any (IBM-published or user-published) tips on reworking DXL code from 32-bit to 64-bit?" I'd rather read the tips first than fail and seek out the conversion tips and "gotcha's" later. Sometimes there are weird caveats in DXL that you would not see if doing 32-to-64 bit code conversion for C or C++ for example.
|
Re: Guidelines for 32-bit to 64-bit Conversion Fu Lin Yiu - Wed Aug 02 14:00:07 EDT 2017 Mathias, I concur that in this context Addr64_ is fine. COMMENT: Sometimes I use different "pointer to some type" to narrow variables down to target different overloaded functions (e.g., int*, char*, real*). This was not necessary here. What I am still interested in is "Are there any (IBM-published or user-published) tips on reworking DXL code from 32-bit to 64-bit?" I'd rather read the tips first than fail and seek out the conversion tips and "gotcha's" later. Sometimes there are weird caveats in DXL that you would not see if doing 32-to-64 bit code conversion for C or C++ for example.
A few of the community that I know of have successfully migrated their systems to 64bit ... despite the known bugs in DOORS 9.6.1.6 and the changed integer handling the scripts all run fine, except all the memory/addr_ magic. Unfortunately the memory magic is not something that is supported by IBM so you will likely not get any official migration path. The migration path that proved working for myself was: - factor out a library 32bit.inc and put the safe_literal function for 32 bit I posted on that other post inside. - replace all calls where you do something like this (embed address in string): string code = "Module m = " ((addr_ m) int) "\n ..." by the literal function: string code = "Module m = " (safe_literal m) " ..." Afterwards you create a library for 64bit (64bit.inc) with the safe_literal function I posted somewhere. Now you should be able to run your scripts by either including one or the other. Then you need to find the places where you do pointer arithmetics and take into account that everything that was formerly 4 byte wide is now 8 byte wide. You should assume that the memory layout of everything changed, i.e. if you have code that assumes a memory layout on skip lists, etc. wont work anymore and needs to be retested/changed. Development Tools like memory leak finder or string table debugger do not work out of the box. I think that should be it ... Did I forget something? Regards, Mathias |
Re: Guidelines for 32-bit to 64-bit Conversion Mathias Mamsch - Thu Aug 03 04:56:03 EDT 2017 A few of the community that I know of have successfully migrated their systems to 64bit ... despite the known bugs in DOORS 9.6.1.6 and the changed integer handling the scripts all run fine, except all the memory/addr_ magic. Unfortunately the memory magic is not something that is supported by IBM so you will likely not get any official migration path. The migration path that proved working for myself was: - factor out a library 32bit.inc and put the safe_literal function for 32 bit I posted on that other post inside. - replace all calls where you do something like this (embed address in string): string code = "Module m = " ((addr_ m) int) "\n ..." by the literal function: string code = "Module m = " (safe_literal m) " ..." Afterwards you create a library for 64bit (64bit.inc) with the safe_literal function I posted somewhere. Now you should be able to run your scripts by either including one or the other. Then you need to find the places where you do pointer arithmetics and take into account that everything that was formerly 4 byte wide is now 8 byte wide. You should assume that the memory layout of everything changed, i.e. if you have code that assumes a memory layout on skip lists, etc. wont work anymore and needs to be retested/changed. Development Tools like memory leak finder or string table debugger do not work out of the box. I think that should be it ... Did I forget something? Regards, Mathias Accepted, but lots of work ahead I was not counting on. |