sambo@ukma.UUCP (Father of micro-ln) (09/20/85)
Does anyone know which MS-DOS C compilers are capable of outputting Micro- soft assembly language? I would like something that can manage several data segments and several code segments. Speed is not the first priority - reliability is more important. Recommendations as well as pointers to magazine articles are welcome. -- Samuel A. Figueroa, Dept. of CS, Univ. of KY, Lexington, KY 40506-0027 ARPA: ukma!sambo<@ANL-MCS>, or sambo%ukma.uucp@anl-mcs.arpa, or even anlams!ukma!sambo@ucbvax.arpa UUCP: {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!sambo, or cbosgd!ukma!sambo "Micro-ln is great, if only people would start using it."
DRF@SU-SCORE.ARPA (David Fuchs) (09/22/85)
"Does anyone know which MS-DOS C compilers are capable of outputting Micro- soft assembly language?" Don't be fooled into thinking that Microsoft C will do it! Even though there is an option that claims to fill the bill ("/Fa"), it is so buggy that it's totally useless. I tried it on one of my programs, and found I had to fix half a dozen systematic bugs in the output code before the Microsoft assembler would accept it (for instance: multiply-defined labels, missing new-lines in segment definitions, "DB (2)" instead of "DW" in many cases, etc.). Obviously, no one at Microsoft had ever bothered to test the thing. I called their support number, and all I could get was "Yes, it doesn't work." Nothing about IF it would be fixed, much less WHEN. -david p.s. I'm extra-angry because their first response was "Well, if you're using the IBM assembler (even the new one), you're out of luck because it's out of date; you have to use the Microsoft assembler." Cute trick: sell a buggy program, and then tell users that if they buy a second product, everything will be OK. Pretty sleazy, especially since it isn't even true! -------
sambo@ukma.UUCP (Father of micro-ln) (09/23/85)
In article <2223@ukma.UUCP> I (Father of micro-ln) write: >Does anyone know which MS-DOS C compilers are capable of outputting Micro- >soft assembly language? Someone told me something I think everyone should know (though I suspect everyone already knows this anyway). Microsoft C has the switch /Fa, or something like that, that is supposed to make it output assembly language. It takes quite a bit of doing to make the output acceptable to Microsoft's MASM assembler. There is no word on whether Microsoft plans to fix this. -- Samuel A. Figueroa, Dept. of CS, Univ. of KY, Lexington, KY 40506-0027 ARPA: ukma!sambo<@ANL-MCS>, or sambo%ukma.uucp@anl-mcs.arpa, or even anlams!ukma!sambo@ucbvax.arpa UUCP: {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!sambo, or cbosgd!ukma!sambo "Micro-ln is great, if only people would start using it."
rlk@chinet.UUCP (Richard L. Klappal) (09/23/85)
I know the Manx AZTEC C II compiler (cpm version) can produce standard 8080 assembler. The recent ads that I can find don't say one way or the other for the MSDOS version. Their toll free order/info number is 1-800-221-0440. Their code seems to be pretty clean, and a fairly complete implementation. I haven't found any major ommissions except bit fields and setjmp/longjmp, but I understand that those have been added since I got my version ( > 1yr ago). -- Richard Klappal UUCP: ..!ihnp4!chinet!uklpl!rlk | "Money is truthful. If a man MCIMail: rklappal | speaks of his honor, make him Compuserve: 74106,1021 | pay cash." USPS: 1 S 299 Danby Street | Villa Park IL 60181 | Lazarus Long TEL: (312) 620-4988 | (aka R. Heinlein) -------------------------------------------------------------------------
pwv@fluke.UUCP (Pat Vilbrandt) (09/24/85)
> In article <2223@ukma.UUCP> I (Father of micro-ln) write: > >Does anyone know which MS-DOS C compilers are capable of outputting Micro- > >soft assembly language? > ... Microsoft C has the switch /Fa, or > something like that, that is supposed to make it output assembly language. > It takes quite a bit of doing to make the output acceptable to Microsoft's > MASM assembler. ... > -- > Samuel A. Figueroa, Dept. of CS, Univ. of KY, Lexington, KY 40506-0027 I beg to differ. I am currently using version 3.00 of the Microsoft C Compiler and the /Fa switch does indeed produce assembly code that is compatible with MASM version 3.00. I do recommend this version of the C compiler. I have found no irregularities with it, although I hear previous versions had their share. -- Pat Vilbrandt John Fluke Mfg. Co., Inc. Everett, Washington USA UUCP: { decvax!uw-beaver, ucbvax!lbl-csam, allegra, ssc-vax, decwrl!sun }!fluke!pwv ARPA: fluke!pwv@uw-beaver.ARPA
km@cadre.ARPA (Ken Mitchum) (09/25/85)
C86 from Computer Innovations does this, and supports the large model also. It is not particularly fast, but it works, and library sources are included. -ken mitchum (km@cadre.arpa)
kim@mips.UUCP (Kim DeVaughn) (09/25/85)
[ ... go ahead, eat my bits ... ] I recently installed the Eco-C88 compiler (rev 2.81) on my MS-DOS machine. I've only written a few simple, straightforward programs with this compiler, but all of those produce assembly language (using the -a option) that is acceptable input to MASM. I've run the assembler output into MASM (MicroSoft label rev 1.12) and MASM (IBM label rev 2.01), with no problems, so I'd *guess* that most any rev of the assembler would do. Their address is: Ecosoft, Inc. 6413 N. College Av. Indianapolis, IN 46220 ph: 317-255-6476 Note: I'm not associated with Ecosoft in any way, except as a satisfied customer. /kim "You live and learn. Or you don't live long." -- Lazarus Long [generic disclaimer] -- UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!kim DDD: 415-960-1200 USPS: MIPS Computer Systems Inc, 1330 Charleston Rd, Mt View, CA 94043
kbb@faron.UUCP (Kenneth B. Bass) (09/26/85)
In article <193@chinet.UUCP> rlk@chinet.UUCP (Richard L. Klappal) writes: >I know the Manx AZTEC C II compiler (cpm version) can produce standard >8080 assembler. The recent ads that I can find don't say one way or >the other for the MSDOS version. Their toll free order/info number >is 1-800-221-0440. > >Richard Klappal > >UUCP: ..!ihnp4!chinet!uklpl!rlk | "Money is truthful. If a man >------------------------------------------------------------------------- I have been using Manx's AZTEC's C compiler for the PC for awhile now. It doesn't produce Microsoft compatible assembly code. But, the AZTEC package comes with a utility to convert AZTEC object files to Microsoft Linker compatible files. This would allow you to link C routines and Microsoft assembler routines (using Microsoft's Linker). Note of caution, though. I have tried this, and well, all I can say is that sometimes it works, and sometimes it doesn't. They seem to have a problem with large programs (irregardless of what kind of memory model you are using). It seems as though that any linked program that uses more then 64K (code+data) crashes out the heap. Manx wasn't very helpful in finding out why. I eventually stopped trying to use Microsoft's object files with Manx's. I also should add my 2 cents worth about Manx and their compiler. First, their latest compiler (version 3.2d) is one of the best I have seen. Mainly because the code that it generates is very logically optimized, and also VERY easy to debug (at object code level). Their librarys contain most relevant UN*X functions, and that makes porting programs much easier. The compiler package also comes with utilities like 'grep', 'diff', 'make', as well as a 'vi'-like editor. On the other hand, the sales and technical support we got from Manx was appalling. It took us about 3 months (and many frustrating phone calls) to get our upgrade from ver. 1.06 to 3.2. And once we did get this latest version, their technical support was not very helpful. At least they were polite.... "It ain't necessarily so" ken bass linus!faron!kbb
pwv@fluke.UUCP (Pat Vilbrandt) (09/26/85)
"Does anyone know which MS-DOS C compilers are capable of outputting Micro- soft assembly language?" From: DRF@SU-SCORE.ARPA (David Fuchs) "Don't be fooled into thinking that Microsoft C will do it! ..." Please, PLEASE, could you provide the version number of the compiler in your flame!! I have found no problems with version 3.00 of MSC using the /Fa option with version 3.00 of MASM. Be aware that previous versions of MSC are totally different (based on the Lattice C compiler, I believe). Yes, I had to get the most recent version of the assembler, but not because of incompatiblity with the compiler. It (IBM version 1.00) was producing BAD CODE. -- Pat Vilbrandt John Fluke Mfg. Co., Inc. Everett, Washington USA UUCP: { decvax!uw-beaver, ucbvax!lbl-csam, allegra, ssc-vax, decwrl!sun }!fluke!pwv ARPA: fluke!pwv@uw-beaver.ARPA
DRF@SU-SCORE.ARPA (David Fuchs) (09/27/85)
Sorry, Pat, but I put 20,000 lines of code through Microsoft C version 3 using the /Fa switch, and it produces a total disaster area that MASM 3 complained about in THOUSANDS of error messages. On inspection, it was clear that there were at least a half dozen systematic errors in the assembly code. Good grief, the SEGMENT statements didn't even match the ENDS statements! Multiple labels galore, too. Interestingly, the direct-to-OBJ-file code was all just fine; only the ASM stuff had ridiculous boo-boos in it. -david -------
rsellens@watdcsu.UUCP (Rick Sellens - Mech. Eng.) (09/27/85)
In article <1645@brl-tgr.ARPA> DRF@SU-SCORE.ARPA (David Fuchs) writes: > >"Does anyone know which MS-DOS C compilers are capable of outputting Micro- > soft assembly language?" > >Don't be fooled into thinking that Microsoft C will do it! Even though >there is an option that claims to fill the bill ("/Fa"), it is so buggy >that it's totally useless. I tried it on one of my programs, and found I resisted posting the first time this went by, but I'll throw in my two cents now. DeSmet C will produce assembler output. Presumably there are no major bugs since the compiler normally sends its output through the assembler. Two faults - Only two segments supported -- one code, one data. - The assembler output is for DeSmet's assembler, not the Microsoft assembler. Rick Sellens UUCP: watmath!watdcsu!rsellens CSNET: rsellens%watdcsu@waterloo.csnet ARPA: rsellens%watdcsu%waterloo.csnet@csnet-relay.arpa