🚀 go-pugleaf

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.