This is the mail archive of the cygwin-talk mailing list for the cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problems with GMP in latest Cygwin


William Hart wrote:
Firstly I was using Cygwin on a **64** bit Athlon,
running on **32** bit Windows XP.

I'm not sure about what choices of bit length are made
for long's under such circumstances, but one has to be
very careful of the following:

Microsoft, in their "infinite wisdom", made long's 32-bit, even for 64-bit targets (which is different from how the ENTIRE REST OF THE WORLD works - don't get me started, or at least TITTTL any continuation)... but, basically, if you are running a 32-bit OS on 64-bit hardware this should be no different than running the same 32-bit OS on 32-bit hardware. Of course I expect/hope that gcc, when it is ported to 64-bit Windows (soon, I think, since I hear binutils is ported) to make more reasonable decisions.

1) printf("%ld",longvar) expects a long
2) Using gmp_scanf and gmp_printf after instances of
ordinary printf and scanf when the incorrect
assumptions have been made about the length of a long
may cause problems (note the compiler may not give an
error or warning).
3) Replacing long's with u_int32_t's may further
compound the problems: GMP expects a ui (in functions
like mpz_mul_ui) to be 32 bits on a 32 bit machine and
64 bits on a 64 bit machine. But what does it expect
on a 64 bit machine running in 32 bit mode? One must
use a long, but this may cause issues elsewhere.

This I don't get; if GMP is doing anything that takes into account the hardware bits, independent of the OS bits, then IMO it is doing something wrong. At any rate, all SANE systems ought to be using the LPxx model; i.e. 'sizeof(long) == sizeof(void*)'. This has nothing to do with the hardware, since a 32-bit OS (or even a 32-bit program on a 64-bit OS) still has 32-bit pointers and should therefore have 32-bit longs.

Some combination of the above led me to write a
program which compiled without warnings and which ran
correctly on my 32 bit laptop, but which compiled
correctly did not run correctly on my 64 bit Athlon
running 32 bit Windows XP (under Cygwin).

This I find VERY surprising. What was the program? The only possible explanation I can think of is that this program somehow was run in 64-bit mode even though it is a 32-bit program (possibly because it intentionally alters itself depending on the hardware it is run on). I can think of no reason that identical assembly should not behave identically on different CPU's.

What you are suggesting has very serious ramifications.

C is portable only if you are porting it to the same
kind of machine, using the same operating system with
the same kind of OS emulator!!

I thought you said you were doing this? 32-bit OS in both cases; emulation should be the same. If your 64-bit hardware can't run 32-bit code correctly then there is something very wrong with it. That, or there is something wrong with your code that 'fortuitously' works correctly on 32-bit hardware (some issue with sign extension, maybe).

"Try to bring it back in one piece this time." -- Q (MI6)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]