32/64 bit cc differences

Discussion in 'C Programming' started by JohnF, Jan 10, 2014.

  1. JohnF

    JohnF Guest

    Actually, I tried both, and neither was recognized by that
    particular gcc. But what I particularly wanted was to compare
    the behavior of 32-bit vs 64-bit float, regardless of other
    architecture differences, and my reading was that -m32-bit
    was the more relevant switch. But you're right that if both
    worked, I'd have tried compiling all four possible ways,
    seen what differences/samenesses in the output occurred,
    and proceeded from there.
    Sure, I looked on my own box, and elsewheres, too.
    But that only showed both -m32's should have been recognized.
    I'd hoped the man page on the box where they didn't work
    would reveal why not.
     
    JohnF, Jan 15, 2014
    1. Advertisements

  2. JohnF

    Kaz Kylheku Guest

    The obvious solution (to that and any "host" of other problems, no pun
    intended) is to use a Unix-like system for a webserver with CGI programs.

    Which anyone who isn't out of their freaking mind generally does.
     
    Kaz Kylheku, Jan 15, 2014
    1. Advertisements

  3. I don't think you're encountering 32-bit vs. 64-bit float. Types
    `float` and `double` are typically 32 and 64 bits, respectively,
    on both 32-bit and 64-bit systems. There are differences in the
    representation of `long double`, and in how intermediate results
    are stored.

    (I've worked on systems where `float` and `double` are both 64 bits,
    but they were Cray vector machines.)
     
    Keith Thompson, Jan 15, 2014
  4. Apologies for being curt, but:

    I really don't care what your C code says. It compiles differently
    under 32bit and 64bit, using different floating point units in the x86
    architecture. It will not generate the same stream of random numbers.
    Your 32bit and 64bit binaries will not be capable of decrypting each
    others outputs.

    Looking at the thread so far, it is very likely that you have made your
    "1 byte in 1000" problem substantially rarer, but you really have not
    removed it entirely. You cannot use floating point numbers of any kind
    and have any expectation of determinism.

    ~Andrew
     
    Andrew Cooper, Jan 16, 2014
  5. JohnF

    James Kuyper Guest

    Not caring about what his C code says seems rather odd, since that code
    determines whether or not your assertions about the results of compiling
    it are correct. He's asserted that the current version of his code
    performs a "completely integer calculation". If that description is
    correct (I haven't bothered to check), then why would it use the
    floating point units at all, much less using different ones on the two
    different machines?

    If he's wrong, and it's not yet a "completely integer calculation", then
    that's a different and very legitimate issue - but what his C code says
    is very relevant to that issue.
     
    James Kuyper, Jan 16, 2014
  6. (snip, someone wrote)
    Hmmm. The extra precision used in the x87 is part of the IEEE
    standard. In addition, IEEE 754 supports different rounding
    modes, so you would also have to be sure that the same rounding
    was done in all cases.

    Also, while many systems support the IEEE floating point formats,
    they may not necessarily claim everything else about the standard.
    I would have to read it more carefully to be sure, but I don't
    believe that the intent of the standard was to generate bit exact
    results, as this case requires.

    -- glen
     
    glen herrmannsfeldt, Jan 17, 2014
  7. JohnF

    JohnF Guest

    Okay, you don't care what the code says, but you seem to have
    ignored what I said, too, which leaves you little to go on:)
    I >>agreed with you<< the fp results won't be the same.
    But I went on to say >>I'm not using the fp results<< any more,
    thanks to all the comments and suggestions in this thread.
    For example, as Ben pointed out, the Park&Miller algorithm used
    by the ran1() function is a >>completely integer<< calculation,
    generating a random integer intran=1...maxintran.
    At the end, just before return;, it merely does an fp divide,
    fpran = ((float)intran)/((float)(maxintran+1)). That's the only
    fp calculation, period. I now ignore it, totally. And I just
    use that intran.
     
    JohnF, Jan 17, 2014
  8. (snip, I wrote)
    Well, one problem with extra precision is double rounding.
    If you round from extra to double, then to single, the result
    can be different (wrong) from the correctly rounded extended
    to single.

    But consistent use of extended, unlike with the x87 with 8
    registers, should give more accurate results.
    Well, in most cases what people want is the correct (closest)
    printed decimal value. As the exponent shifts for binary are
    different from decimal, you have to provide enough extra bits.

    Or use the IEEE 754 decimal floating point.

    Extra precision is most useful for sums, where cancelation and lost
    precision can easily occur. There are some other cases where
    the extra precision for intermediate values helps.

    -- glen
     
    glen herrmannsfeldt, Jan 17, 2014
  9. JohnF

    J. Clarke Guest

    Intel hardware supports integer calcuations in the general purpose
    registers, the 80x87 stack, and the SSE registers. So there is no
    guarantee that an integer operation will be performed using the general-
    purpose registers--this would be something that was determined by the
    design of the compiler, the optimizations in force, and the specific
    instruction sequence.
     
    J. Clarke, Jan 17, 2014
  10. JohnF

    James Kuyper Guest

    That can't be problematic if we're talking about conforming
    implementations of C. If there's any possibility that a purely integer
    operation with defined behavior, will produce different results if it's
    performed using the 80x87 stack or the SSE registers, then a conforming
    implementation of C that chooses to use those things is pretty much
    required to correct for that difference. There's no statement in the C
    standard covering integer operations that gives implementations anything
    like the same amount of freedom that 5.2.4.2.2p6 gives them for floating
    point operations. Even implementations that pre-#define __STDC_IEC_559__
    have less freedom in the evaluation of integer operations than floating
    point ones.
     
    James Kuyper, Jan 17, 2014
  11. JohnF

    Rosario193 Guest

    why not use windows OS sys api?
     
    Rosario193, Jan 19, 2014
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.