home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / m68k / 1494 < prev    next >
Encoding:
Internet Message Format  |  1992-12-26  |  6.8 KB
  1. Path: sparky!uunet!paladin.american.edu!gatech!emory!ogicse!mintaka.lcs.mit.edu!ai-lab!mobot!bleck
  2. From: bleck@mobot.ai.mit.edu (Olaf Bleck)
  3. Newsgroups: comp.sys.m68k
  4. Subject: SUMMARY:   PC based CPU32 compilers--need suggestions
  5. Message-ID: <1h5fjjINN4mn@life.ai.mit.edu>
  6. Date: 21 Dec 92 22:14:11 GMT
  7. Article-I.D.: life.1h5fjjINN4mn
  8. Sender: bleck@mobot (Olaf Bleck)
  9. Reply-To: bleck@ai.mit.edu
  10. Distribution: world
  11. Organization: MIT Artificial Intelligence Laboratory
  12. Lines: 149
  13. NNTP-Posting-Host: mobot.ai.mit.edu
  14.  
  15. Thanks to everyone who replied!
  16. -Olaf
  17.  
  18. Summary of responses:  PC based CPU32 compilers--need suggestions
  19.  
  20. ***********
  21.  
  22. For less than the cost of the new compiler, you can buy a used sun-3, and
  23. then you don't have to change anything. You can have 24-hour access too! :-)
  24.  
  25. PC's really are horrible to work with, avoid'em if you can!
  26.  
  27. ---------------------
  28. ovrskeek@matt.ksu.ksu.edu
  29.  
  30. ***********
  31.  
  32. >I'm currently developing some things for a 68332, and I'm interested in
  33. >porting my development stuff to the IBM PC world.
  34.  
  35. I have been using the compiler from MicroTec (located in Santa Clara, CA)
  36. for about 2 years now.  I am very satisfied with their product.  It is a
  37. bit expensive (about $4,000 for just the compiler) but hits just about all
  38. of your requirements.
  39.  
  40.  
  41. >1) My libraries make use of some of the non-standard features of GCC, such as
  42. >the "inline" function declaration, and inlined assembler formats.  Ideally I
  43. >would like to find a compiler that is GCC compatible, so that I don't have to
  44. >rethink all the inlined stuff.
  45.  
  46. I know for sure that you can use in-line assembler formats, but I'm not too
  47. sure about in-line function declaration.  I'll check the manuals to see if
  48. it is supported if you want me to, but I believe it is.
  49.  
  50.  
  51. >2) Cost shouldn't be more than around a few $1000's, less ideally.
  52.  
  53. This might be a bit of a problem.  I think they are charging about $4,000
  54. for just the compiler/linker/assembler, but you will have to get a price
  55. quote from them for that.
  56.  
  57. >3)  It should have downloader capabilites, either having it's own that talks
  58. >to the motorola debugger, or be compatible with the motorola downloader.  It
  59. >should also be able to generate a binary file that can be burned into an
  60. >eprom.  (This could also be used instead of a downloader, since I could use
  61. >NVRAMS and to them via a programming socket).
  62.  
  63. The compiler can make Motorola S-records for you and can produce IEEE-695
  64. (or some standards number) output with "MicroTec enhancements".  This
  65. second format is used with their XRAY debug tool.  For burning EPROMs, you
  66. will just want to create S-records.  I have done this with their product on
  67. at least 10 different projects of my own, and have no problem with it.  If
  68. you spend the bucks and get one of their XRAY source level debugger
  69. packages, you can use the IEEE-695 format.  This proves a very nice
  70. environment for doing source-level debug.  It is similar to using
  71. MicroSoft's CodeView debugger, but I happen to like using XRAY better.  You
  72. can easily display & modify variables, set breakpoints, trace interrupt
  73. routines, modify registers, etc.  You can intermix assembler and 'C' source
  74. or just work at the 'C' source level.  Very nice.  They have XRAY available
  75. in several flavors, including :
  76.  
  77. 1) Simulator XRAY, which just runs on the PC host with no 68K product
  78.    installed.  XRAY entirely simulates the 68000 cpu and executes all
  79.    instructions in an artificial environment.  Kinda useful at times if
  80.    you have the bucks, but not my first choice if you don't.
  81.  
  82. 2) In-circuit monitor XRAY, which requires a 68000-family CPU and a
  83.    dedicated serial port.  You burn a small (about 11 Kbyte) program into
  84.    EPROM and use it to boot your processor.  The PC then connects via a
  85.    serial line to the processor and you are then able to issue various
  86.    commands to download code, debug code, etc.  The user interface is
  87.    identical to the simulator XRAY, only now you have real hardware with
  88.    real interrupts.  I find this option to be most useful, and would
  89.    recommend this one if you have to pick one of the three XRAY versions.
  90.    You must have enough RAM to download the code you want to debug.  This
  91.    is in addition to RAM used for stack and global or static variables.
  92.  
  93. 3) ICE XRAY, which uses one of several standard ICE products from various
  94.    hardware vendors.  I have used this with the HP64700 series of emulators
  95.    on a consulting project I am working on, and find it to be not as nice
  96.    as the monitor XRAY (option 2).  It's response is slower and is _much_
  97.    more buggy than either of the other two XRAY packages.  It does have the
  98.    nice ability to set breakpoints in ROM and breakpoints for accessing
  99.    locations rather than just breakpoints for locations that get executed
  100.    (as option 2 has).  It makes pretty good use of the capabilities of the
  101.    ICE hardware.
  102.  
  103. -- 
  104. Dave McMahan                            mcmahan@netcom.com
  105.                     {apple,amdahl,claris}!netcom!mcmahan
  106. **************
  107.  
  108. How about GCC ported for MS-DOS 386+ with 2MB+.  You can obtain such a beast
  109. from:
  110.  
  111.         Hundred Acre Consulting
  112.         ATTN: Bruce Robertson
  113.         1280 Terminal Way, Suite 26
  114.         Reno NV  89502-3243
  115.         Tel: (702) 329-9333
  116.         Fax: (702) 329-9566
  117.         UUCP: info@pooh.com
  118.         CIS: 76130,3034
  119.  
  120. Unsupported package with full source and postscript doc on disk is $100 US.
  121. As above with printed docs (highly recommended) is $150 US.
  122. As above with 1 year email, phone, fax support is $500 US.
  123.  
  124. I have the above unsupported package for the 68K series of targets.  Bruce is
  125. very good to deal with.  Responses and help are quick.  The package includes
  126. gcc 2.3, as, ld, bintools, gdb.  It sounds like it will match your requirements
  127. completely.
  128.  
  129. When ordering from Bruce, tell him you heard abouth this from me (Alex Leyn, 
  130. Leitch Video Int'l Inc.)
  131.  
  132. --
  133. University of Waterloo, Electrical & Computer Engineering, Class of 1992
  134. Internet: 4BClass@EandCE.UWaterloo.CA
  135. c/o Alex Leyn
  136.  
  137. ******************
  138.  
  139. Return-Path: <benjii!chris@uunet.uu.net>
  140. Date: Sat, 19 Dec 92 13:54:41 PST
  141. From: benjii!chris@uunet.uu.net (Chris Rosebrugh)
  142. To: bleck@ai.mit.edu
  143. Subject: Re: PC based CPU32 compilers--need suggestions
  144.  
  145. we've been using Intermetrics' Itools for the last 2 years.
  146. we develop a 68331 pen-based computer and use their Itools
  147. for development on both the sun and the PC. The code they
  148. generate is very good. We switched to CrossCode from 
  149. SDS (Software Development Systems) for a while early
  150. this year because Intermetrics was dragging their feet
  151. in putting the PC version out which uses protected mode
  152. instead of real mode. But, they've got the right stuff
  153. up and running now (and so do we). FYI, the SDS compiler
  154. is slow and the generated code is generally about 15%
  155. slower than Itools.
  156.  
  157.  
  158.  
  159. -- 
  160. Tear Here:
  161. -----------------------------------------------------------------
  162. _________________________________________________________________
  163. Olaf Bleck                    bleck@ai.mit.edu
  164.