[net.micro] Any C compilers that produce assembly language?

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