len@array.UUCP (Leonard Vanek) (06/22/87)
I have the source for a program that requires 32-bit integers and
double precision floating point with more than 32 bits precision.
I do not yet own a C compiler for my PC but wish to buy one that
can handle this program.
My preference is to buy Turbo C, but I would buy Microsoft or any
other if Turbo C does not meet the above requirements and the
other one does. Hence my questions.
1. Can Turbo C handle my needs?
2. Can Microsoft?
3. Are there any other good compilers that can do it?
Please mail your replies and I will summarize to comp.sys.ibm.pc.
Leonard Vanek
Array Systems Computing Inc.
5000 Dufferin St. Suite 200
Downsview, Ont. M3H 5T5
Canada
UUCP: ... {utzoo mnetor}!dciem!array!len
Phone: (416) 736-0900davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (06/25/87)
In article <502@array.UUCP> len@array.UUCP (Leonard Vanek) writes: > >I have the source for a program that requires 32-bit integers and >double precision floating point with more than 32 bits precision. >I do not yet own a C compiler for my PC but wish to buy one that >can handle this program. As far as I have seen, there are no compilers on the market which allow 32 bit ints. I would gladly buy one if there were. There are a number of compilers which allow 32 bit *longs*, which is what you should use for portability. The lack of 32 bit ints is only a problem if you have, say, 7 MB of source code for a VAX which assumes that int <same as> pointer. > >My preference is to buy Turbo C, but I would buy Microsoft or any >other if Turbo C does not meet the above requirements and the >other one does. Hence my questions. I would wait and look at QuickC. It should be shipping very soon, and will be about the same price and performance as TurboC. The edge is the debugger. CodeView is a very good debugger, and will speed program development. You will also like getting all of your error messages, rather than having to recompile after each error. > >1. Can Turbo C handle my needs? Probably. > >2. Can Microsoft? Subject to what I said about ints, yes. You'll like the v5.0 performance for both compile speed and code speed/size. The whole issue of speed is mainly an issue for personal use. Given a good 10MHz clone with 2MB RAMdisk, you will see compile and link around 12 sec for a 200 line program. Using a 386 machine will get you under 8 sec. > >3. Are there any other good compilers that can do it? I believe that the professional version of Aztec (Manx) C will also do the job. > >Please mail your replies and I will summarize to comp.sys.ibm.pc. > >Leonard Vanek > >UUCP: ... {utzoo mnetor}!dciem!array!len >Phone: (416) 736-0900 -- bill davidsen (wedu@ge-crd.arpa) {chinet | philabs | sesimo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
smvorkoetter@watmum.UUCP (06/26/87)
In article <6459@steinmetz.steinmetz.UUCP> davidsen@kbsvax.steinmetz.UUCP (William E. Davidsen Jr) writes: >In article <502@array.UUCP> len@array.UUCP (Leonard Vanek) writes: >> >>I have the source for a program that requires 32-bit integers and >>double precision floating point with more than 32 bits precision. >>I do not yet own a C compiler for my PC but wish to buy one that >>can handle this program. > >As far as I have seen, there are no compilers on the market which allow >32 bit ints. I would gladly buy one if there were. There are a number of >compilers which allow 32 bit *longs*, which is what you should use for >portability. The lack of 32 bit ints is only a problem if you have, say, >7 MB of source code for a VAX which assumes that int <same as> pointer. My problem exactly. I am currently attempting to port a large software package from a VAX to an IBM PC AT. The program makes extensive use of 32 bit ints (which could easily be changed to longs) but more importantly, uses them interchangeably with pointers. Even using longs won't help because the PC's address space is NOT linear. If I were to assign the values 0x00010000 and 0x00000010 to longs and compare them, they would obviously be unequal. As pointers however, they both point to the same memory location. MY SOLUTION: Given the Small C Compiler (public domain) and a lot of work, I have written a C Compiler (almost done) that completely hides the environment from the programs compiled with it. Ints are 32 bits, pointers are 32 bits, and completely interchangeable with ints. The linear-to-segmented addressing conversion and vice-versa is done at run-time. This makes things a bit slow, but it should be workable. The current version does NOT generate machine code; it generates parse trees, which are interpreted. Generating code is feasible, but will generate some very LARGE code. I will probably eventually have it generate some sort of threaded code. NOTE: Some features of full C are not supported, most notably structs and unions. Up to five levels of indirection are allowed, but arrays cannot be declared with more than one dimension. The compiler implements only those parts of C needed for the software package. Stefan Vorkoetter (smvorkoetter@watmum) Symbolic Computation Group University of Waterloo Waterloo, Ontario, CANADA The opinions herein are those of my self, not those of my employer, nor those of the people sharing my office, nor anyone else for that matter. Unauthorized use of these opinions is prohibited.