From: bleck@mobot.ai.mit.edu (Olaf Bleck)
Newsgroups: comp.sys.m68k
Subject: SUMMARY:   PC based CPU32 compilers--need suggestions
Date: 21 Dec 92 22:14:11 GMT
Article-I.D.: life.1h5fjjINN4mn
Reply-To: bleck@ai.mit.edu
Distribution: world
Organization: MIT Artificial Intelligence Laboratory
NNTP-Posting-Host: mobot.ai.mit.edu

Thanks to everyone who replied!
-Olaf

Summary of responses:  PC based CPU32 compilers--need suggestions

***********

For less than the cost of the new compiler, you can buy a used sun-3, and
then you don't have to change anything. You can have 24-hour access too! :-)

PC's really are horrible to work with, avoid'em if you can!

---------------------
ovrskeek@matt.ksu.ksu.edu

***********

>I'm currently developing some things for a 68332, and I'm interested in
>porting my development stuff to the IBM PC world.

I have been using the compiler from MicroTec (located in Santa Clara, CA)
for about 2 years now.  I am very satisfied with their product.  It is a
bit expensive (about $4,000 for just the compiler) but hits just about all
of your requirements.


>1) My libraries make use of some of the non-standard features of GCC, such as
>the "inline" function declaration, and inlined assembler formats.  Ideally I
>would like to find a compiler that is GCC compatible, so that I don't have to
>rethink all the inlined stuff.

I know for sure that you can use in-line assembler formats, but I'm not too
sure about in-line function declaration.  I'll check the manuals to see if
it is supported if you want me to, but I believe it is.


>2) Cost shouldn't be more than around a few $1000's, less ideally.

This might be a bit of a problem.  I think they are charging about $4,000
for just the compiler/linker/assembler, but you will have to get a price
quote from them for that.

>3)  It should have downloader capabilites, either having it's own that talks
>to the motorola debugger, or be compatible with the motorola downloader.  It
>should also be able to generate a binary file that can be burned into an
>eprom.  (This could also be used instead of a downloader, since I could use
>NVRAMS and to them via a programming socket).

The compiler can make Motorola S-records for you and can produce IEEE-695
(or some standards number) output with "MicroTec enhancements".  This
second format is used with their XRAY debug tool.  For burning EPROMs, you
will just want to create S-records.  I have done this with their product on
at least 10 different projects of my own, and have no problem with it.  If
you spend the bucks and get one of their XRAY source level debugger
packages, you can use the IEEE-695 format.  This proves a very nice
environment for doing source-level debug.  It is similar to using
MicroSoft's CodeView debugger, but I happen to like using XRAY better.  You
can easily display & modify variables, set breakpoints, trace interrupt
routines, modify registers, etc.  You can intermix assembler and 'C' source
or just work at the 'C' source level.  Very nice.  They have XRAY available
in several flavors, including :

1) Simulator XRAY, which just runs on the PC host with no 68K product
   installed.  XRAY entirely simulates the 68000 cpu and executes all
   instructions in an artificial environment.  Kinda useful at times if
   you have the bucks, but not my first choice if you don't.

2) In-circuit monitor XRAY, which requires a 68000-family CPU and a
   dedicated serial port.  You burn a small (about 11 Kbyte) program into
   EPROM and use it to boot your processor.  The PC then connects via a
   serial line to the processor and you are then able to issue various
   commands to download code, debug code, etc.  The user interface is
   identical to the simulator XRAY, only now you have real hardware with
   real interrupts.  I find this option to be most useful, and would
   recommend this one if you have to pick one of the three XRAY versions.
   You must have enough RAM to download the code you want to debug.  This
   is in addition to RAM used for stack and global or static variables.

3) ICE XRAY, which uses one of several standard ICE products from various
   hardware vendors.  I have used this with the HP64700 series of emulators
   on a consulting project I am working on, and find it to be not as nice
   as the monitor XRAY (option 2).  It's response is slower and is _much_
   more buggy than either of the other two XRAY packages.  It does have the
   nice ability to set breakpoints in ROM and breakpoints for accessing
   locations rather than just breakpoints for locations that get executed
   (as option 2 has).  It makes pretty good use of the capabilities of the
   ICE hardware.

-- 
Dave McMahan                            mcmahan@netcom.com
					{apple,amdahl,claris}!netcom!mcmahan
**************

How about GCC ported for MS-DOS 386+ with 2MB+.  You can obtain such a beast
from:

		Hundred Acre Consulting
		ATTN: Bruce Robertson
		1280 Terminal Way, Suite 26
		Reno NV  89502-3243
		Tel: (702) 329-9333
		Fax: (702) 329-9566
		UUCP: info@pooh.com
		CIS: 76130,3034

Unsupported package with full source and postscript doc on disk is $100 US.
As above with printed docs (highly recommended) is $150 US.
As above with 1 year email, phone, fax support is $500 US.

I have the above unsupported package for the 68K series of targets.  Bruce is
very good to deal with.  Responses and help are quick.  The package includes
gcc 2.3, as, ld, bintools, gdb.  It sounds like it will match your requirements
completely.

When ordering from Bruce, tell him you heard abouth this from me (Alex Leyn, 
Leitch Video Int'l Inc.)

--
University of Waterloo, Electrical & Computer Engineering, Class of 1992
Internet: 4BClass@EandCE.UWaterloo.CA
c/o Alex Leyn

******************

Return-Path: <benjii!chris@uunet.uu.net>
Date: Sat, 19 Dec 92 13:54:41 PST
From: benjii!chris@uunet.uu.net (Chris Rosebrugh)
To: bleck@ai.mit.edu
Subject: Re: PC based CPU32 compilers--need suggestions

we've been using Intermetrics' Itools for the last 2 years.
we develop a 68331 pen-based computer and use their Itools
for development on both the sun and the PC. The code they
generate is very good. We switched to CrossCode from 
SDS (Software Development Systems) for a while early
this year because Intermetrics was dragging their feet
in putting the PC version out which uses protected mode
instead of real mode. But, they've got the right stuff
up and running now (and so do we). FYI, the SDS compiler
is slow and the generated code is generally about 15%
slower than Itools.



-- 
Tear Here:
-----------------------------------------------------------------
_________________________________________________________________
Olaf Bleck					bleck@ai.mit.edu
Newsgroups: comp.sys.m68k