🚀 go-pugleaf

In article <25f8a7cd.ca@polyslo.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes:
>I have been having trouble with a compiler project that I am doing in
>MS C 5.1.  It appears that malloc() is sometimes getting hung in a very
>tight loop.  It doesn't happen all the time.  If I run my program
>right after rebooting it always works, but if I run it right after a
>compile, sometimes malloc hangs.  If I run it in CodeView and this happens
>I can stop it with Ctrl-Break, and step through the machine language,
>and it is stuck in the library routine in a very tight (about 6 instructions)
>loop.
>I am using the compact memory model, on a 386/20, and MS-DOS 4.01.

It is possible that you are having a problem which is semi-common in 386's,
especially fast ones.  If you have a feature known as pipelining enabled, it
can sometimes cause the machine to hang, even when the program executes
perfectly on PC's and AT's.  Pipelining reads ahead in the list of
instructions for the processor to execute, a sort of cache which can help
increase execution speed.  Problems can be brought on if you use *gasp*
self-modifying code that modifies the code that has been already read into the
pipeline.  It is also possible, I would suppose, that it could cause programs
with really short loops to crash.  Two possible fixes to test this theory
would be to A) Put the machine in its slowest mode, 8 Mhz for most 386's,
which generally reduces the number of instructions the processor has time to
read ahead and may solve the problem, or B) Turn off the pipelining.  

 _                _                                         +-=-=-=-=-=-=-=-=-+
|_  ,_  .   _    |_}   _    _  ,_ _         _   _   _   ,_  | ear@wpi.wpi.edu |
|_  |   |  |_    | \  |_\  _>  | | |  |_|  _>  _>  |_'  | | | ear%wpi@wpi.edu |
--< A real engineer never reads the instructions first! >-- +-=-=-=-=-=-=-=-=-+