rick@pcrat.uucp (Rick Richardson) (02/01/90)
In article <25C74384.19872@paris.ics.uci.edu> sklein@ics.uci.edu (Steve Klein) writes: >Does anyone have any experience using MS-DOS C compilers (specifically >Microsoft or Watcom) to generate 80x86 code for a standalone ROM I've used the Oasys port of MS C to the VAX and the Phar Lap linker to produce Intel OMF for the 808x ICE. This was about 2 years ago, and Phar Lap didn't have full symbol capability. I sent them samples of OMF with full symbol information (procs, vars, types, files and line numbers) that had been produced by a COFF to OMF translator I wrote, so they may have much better symbol stuff these days. The company itself seemed very responsive. Sorry, any software referenced above doesn't belong to me anymore. -Rick -- Rick Richardson | Looking for FAX software for UNIX/386 ??? Ask About: |Mention PC Research,Inc.| FaxiX - UNIX Facsimile System (tm) |FAX# for uunet!pcrat!rick| FaxJet - HP LJ PCL to FAX (Send WP,Word,Pagemaker...)|Samples (201) 389-8963 | JetRoff - troff postprocessor for HP LaserJet and FAX|
wbeebe@rtmvax.UUCP (Bill Beebe) (02/02/90)
In article <25C74384.19872@paris.ics.uci.edu> sklein@ics.uci.edu (Steve Klein) writes: >Does anyone have any experience using MS-DOS C compilers (specifically >Microsoft or Watcom) to generate 80x86 code for a standalone ROM >machine. [material deleted] >... produce an Intel absolute locate file (such as produced by Intel's >LOC86), with full symbols ... My only recomendation is this; if you want to use the Intel ICE, then use the Intel software tools. They were designed to work together. If you want to use MSC or Watcom or Turbo or whatever, then look for other ICEs that can support one or more of the above. Many of the DOS-based C compilers can produce debugging information that can be mangled into formats understandable by some of the third party ICEs (or so I've been told). Mixing Intel debugging hardware with someone elses software tools is like mixing oil and water.
rick@pcrat.uucp (Rick Richardson) (02/03/90)
In article <3082@rtmvax.UUCP> wbeebe@rtmvax.UUCP (Bill Beebe) writes: > >My only recomendation is this; if you want to use the Intel ICE, then use >the Intel software tools. They were designed to work together. If you want > >Mixing Intel debugging hardware with someone elses software tools is like >mixing oil and water. While it *can* be tricky, especially with the ICE-86, to feed non-intel produced OMF into the ICE, it can be done. For two years we did this: Basic-16(on VAX) -> coff2omf -> ICE-86(PC host) -> 8088 target The biggest problem was that the ICE-86 made some assumptions (read shortcuts) in processing OMF, expecting that only Intel's tools would be used to produce the OMF. As I recall, the 188 ICE was not as picky. When Basic-16 ran out of steam, we switched to the iAPXx86 C compiler. When that compiler ran out of steam, we switched to MSC: MSC5.0(on VAX) -> PharLap Link(on VAX) -> ICE-86(PC host) -> 8088 target (There was a brief time, when the VAX based tools weren't ported, that a 386/PC was used as a compile server for the VAX running UNIX). The options we had were quite limiting. We found that the target hardware had *critical* timing requirements. Of the development systems we looked at, only the INTEL ICE-86 and iPAT would reliably operate the hardware. Intel's own C compiler at that time was MWC, and it was worse than Basic-16 at code efficiency and size. Its probably now the case, that the third party emulators have caught up; I don't know for sure. -Rick -- Rick Richardson | Looking for FAX software for UNIX/386 ??? Ask About: |Mention PC Research,Inc.| FaxiX - UNIX Facsimile System (tm) |FAX# for uunet!pcrat!rick| FaxJet - HP LJ PCL to FAX (Send WP,Word,Pagemaker...)|Samples (201) 389-8963 | JetRoff - troff postprocessor for HP LaserJet and FAX|
wbeebe@rtmvax.UUCP (Bill Beebe) (02/07/90)
In article <1990Feb2.170404.21768@pcrat.uucp> rick@pcrat.UUCP (Rick Richardson) writes: > >The options we had were quite limiting. We found that the >target hardware had *critical* timing requirements. Of the >development systems we looked at, only the INTEL ICE-86 and iPAT >would reliably operate the hardware. Intel's own C compiler >at that time was MWC, and it was worse than Basic-16 at code >efficiency and size. Its probably now the case, that the >third party emulators have caught up; I don't know for sure. > I agree about the ICE-86 and iPAT. I also agree with you about Mark Williams. I don't know what Intel was trying to acomplish, but the MWC compilers that Intel offered (or still offer) are some of the worse around. Thanks for the tips given earlier, b.t.w. As for the current iC86, I have version 4.1, and it seems to be both fast and fairly efficient. I have been told that Intel re-wrote the iC86 from scratch. It has support for the 8086/88 and 80(C)186/88 family, including numerics for the 8087 and the 80C187. They have direct support for ROMable code and other features that make imbedded support fairly easy. While I'm on the subject of Intel C compilers, let me also state that the Intel C compiler for the 8096 family is one of the worse I have had to use. And the C compiler for the 80960, while appearing to generate fairly optimized code, is a pure memory hog under DOS. It's been a long time indeed that I have run a DOS application that died due to lack of memory when I had 570K free out of 640K. And that was with 2.5 megs of expanded memory with Intels own AboveBoard and an LIM 4.0 driver installed under MS-DOS 4.1. The 80960 C compiler is version 1.2 for any *interested* parties. I finally got it to run by stripping out nearly everything from CONFIG.SYS. Sorry to run on like this but Intel C compilers can and should match the level of engineering quality of Intel's silicon.