Path: utzoo!yunexus!maccs!cs4g6ag From: cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) Newsgroups: comp.sys.ibm.pc Subject: Re: 32 bit C Comps and Long Message-ID: <254A9B7D.12081@maccs.dcss.mcmaster.ca> Date: 29 Oct 89 06:41:01 GMT Article-I.D.: maccs.254A9B7D.12081 References: <1224@utkcs2.cs.utk.edu> Reply-To: cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) Organization: McMaster University, Hamilton, Ontario Lines: 34 In article <1224@utkcs2.cs.utk.edu> wozniak@utkux1.utk.edu (Bryon Lape) writes: $ Excuse me for being a little sarcastic here, but is not the $following true? $ For a 32bit integer (as someone writes about) use $ long int x; $ the variable x will then be 4bytes = 4bytes * 8bits/byte =32bits Yes, and just saying long x; will have the same effect. But ... $Someone asked about a C compiler that supported 32bit ints of 386 $machine. They answer as I see it is yes, they all do. Yes, but I'm sure this person wants to harness at least some of the 32-bit power of the 386. If you take Turbo C 2.0, for example, and try to do math with long ints, it will generate code for the 16-bit 8088/8086/80188/80186/80286 machines, depending on how you set the processor type switch. Sure, it will get the job done, but if the target machine(s) has/have 386s in them, you'd want to use the full 32 bit capabilities of the 386 and have the compiler generate code to move these integers 32 bits at a time and perform math on them 32 bits at a time, rather than building it out of 16-bit operations. A good analogy is the use of an 8087/80187/80287/80387 to do your floating point math. Sure, you can do floating point math on a machine equipped with one of the above chips by telling the compiler to generate emulator code; however, since you have the hardware to do it properly, why not? -- Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca = "\nI'm only an undergraduate!!!\n"; ************************************************************************** ... but I'm too full to swallow my pride ...