Re: Possible poplong bug in 4GL 7.32.FC2 on True64 V5.1 2650 alpha

"Jonathan Leffler" <jleffler@earthlink.net> wrote in message news:40972A8A.3050305@earthlink.net... > > How long an essay did you want? > > Tue64, aka DEC, aka Compaq, aka HP, has a longer history than most > bits of 64-bit Informix, and that is actually its downfall. Sorry; I > helped with the screw-up back in, oh, 1994 or so, and backwards > compatibility does the rest of the damage. > Does this apply to the Pyramid OS (whatever was on a Pyramid machine) back then? The one with two universes (it looks like BSD OR AT&T UNIX depending upon which universe you run in! I remember needing to change popint to poplong to get 4gl integers off the stack! > I4GL (and IDS, come to that) defines INTEGER type as a 32-bit integer. > I4GL originated in the days when 16-bit CPUs were the snazzy new kids > on the block, so when it wants to ensure that it is using a 32-bit > value, it uses 'long' as the data type. So, the I4GL code generator > uses pushlong() to push a 32-bit value, and poplong() to pop a 32-bit > value, and retlong() to return a 32-bit value. > > C compilers on Tru64, not unreasonably, define 'long' as a 64-bit > integer. C code written to work correctly on a 32-bit version of > I4GL, or a 16-bit version of I4GL, uses long to store INTEGER data, > because that's what the c-code version of I4GL does. Said code > therefore uses 64-bit variables to store 32-bit values when > transferred to a 64-bit compiler. The names like poplong() strongly > suggest that the data type should be a long - pity about the reality > that it should be int and not long on 64-bit platforms (other than Win64). > > So, because it seemed likely to give C code the best chance of > migrating without needing major rewrites, the DEC Alpha version of > I4GL (now called HP Tru64 or thereabouts) still uses long where it > should use something else... > > Other 64-bit platforms got done later, once a semi-opaque type had > been defined for 4-byte integers. That's int4 from ifxtypes.h. I > believe that on most platforms, the modern interface to, poplong, for > example, is: > > extern void poplong(int4 *p); > > Except the function actually has a different name and poplong() is a > macro defined in fglsys.h. I'm not sure of the details for I4GL 7.3x > on Tru64. > > I think that contains the gist of the issue: > * I4GL c-code on DEC Alpha precedes most other 64-bit software. > * Minimal source changes seemed to indicate that poplong() et al > should accept 64-bit long integers still. > * In retrospect, this was probably a mistake. > > > -- > Jonathan Leffler #include <disclaimer.h> > Email: jleffler@earthlink.net, jleffler@us.ibm.com > Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/ >

David Williams wrote: > "Jonathan Leffler" <jleffler@earthlink.net> wrote: >>How long an essay did you want? >> >>Tue64, aka DEC, aka Compaq, aka HP, has a longer history than most >>bits of 64-bit Informix, and that is actually its downfall. Sorry; I >>helped with the screw-up back in, oh, 1994 or so, and backwards >>compatibility does the rest of the damage. > > Does this apply to the Pyramid OS (whatever was on a Pyramid machine) > back then? The one with two universes (it looks like BSD OR AT&T > UNIX depending upon which universe you run in! > > I remember needing to change popint to poplong to get 4gl integers > off the stack! Succinctly, I don't know. I remember working on such dual-universe machines, but not in 64-bit days. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/