🚀 go-pugleaf

In article <1991Apr9.141613.26291@jet.uucp> cm@jet.uucp (colin manning) writes:
...
> Does anyone have any experience of ... the Intel 386 C code builder ... ?
...

About 3 years ago I worked on a project using the iNtel 386 tools.
To summarize, they are awful.  It wasn't just bugs, but major architectural
flaws.  As for support, ....                  Want me to say it again?  :-)
The saleman showed up weekly however (we were literally across the street
from the division of iNtel which developed it).  No bug I knew of was fixed
throughout the 5 month period.  The ICE was just as bad.

To provide a semi-balanced opinion, the project did complete successfully.

I'd hope they've fixed the major shortcomings, but, as I said, there were
some architectural flaws:

- To produce an executable from object modules required at least two steps,
  a binder and a builder (I think that's what they were called); one of
  these was extremely slow, and used so much memory that the network could
  not be simultaneously loaded.  The steps to do a test iteration:

  1. modify source code
  2. compile it
  3. update libraries (on the net)
  4. copy updated libraries to local disk
  5. reboot machine without network loaded
  6. run the binder
  7. run the builder
  8. reboot with the network loaded
  9. copy the result to the net, where the ICE could download it
 10. run the simulator.

 As I recall, for ~400k of executable code, this was a 2-3 hour process.

- At the time, the object module format was "proprietary".  No third party
  binders & builders.  (Is this still true?)

- The documentation was below average.  Poorly organized, omitted details
  and useful examples at every turn.

- The ICE searched its symbol table for every piece of the command line.
  They had omitted any "modern" technique for speeding this search up.  I
  don't remember specifics now, but, for example, placing a breakpoint at
  procedure foo and running required something like this:
	go foo
  With our build, it would take something like 45 seconds for the command
  to be parsed and about 1/4 second to execute.  (That's what I call *real
  time*!)
-----
Wally Kramer	contracted from Step Technology, Portland, Oregon 503 244 1239
wallyk@orca.wv.tek.com        +1 503 685 2658