jensen@sun.soe.clarkson.edu (Jim Jensen) (03/20/89)
I am looking for some ideas on why I can't get the simulation programs
from volume III of the PDP books (version 1.1 in main.c) to compile
and work under TurboC version 2.0. I am most interested in the bp.c
simulations, although it seems that the problem will occur in any of
the simulations. Specifically, after compiling, which works after
commenting out the int_handler() function in general.c, and
running the program as:
> bp xor.tem xor.str
I get an out of memory error (I believe it came from the function char
*emalloc(); in general.c, called from init_command()). Has anyone
tried to do this and figured out a solution? Or does anyone have any
suggestions? It seems that turboc is malloc'ing differently, or
returning a different type of pointer than Microsoft C does. I have
successfully compiled and run the bp program under Microsoft C, with
the medium memory model, and am trying to use the huge memory model in
turboc.
Thanks for any help....
Jim
--
jensen@sun.soe.clarkson.edu (internet)
jensenje@clutx (bitnet)
(315) 268-6591wlp@calmasd.Prime.COM (Walter L. Peterson, Jr.) (03/24/89)
In article <JENSEN.89Mar19170153@sun.soe.clarkson.edu>, jensen@sun.soe.clarkson.edu (Jim Jensen) writes: > I am looking for some ideas on why I can't get the simulation programs > from volume III of the PDP books (version 1.1 in main.c) to compile > and work under TurboC version 2.0. I am most interested in the bp.c > simulations, although it seems that the problem will occur in any of > the simulations. Specifically, after compiling, which works after > commenting out the int_handler() function in general.c, and > running the program as: > > > bp xor.tem xor.str > > I get an out of memory error (I believe it came from the function char > *emalloc(); in general.c, called from init_command()). Has anyone > tried to do this and figured out a solution? Or does anyone have any > suggestions? It seems that turboc is malloc'ing differently, or > returning a different type of pointer than Microsoft C does. I have > successfully compiled and run the bp program under Microsoft C, with > the medium memory model, and am trying to use the huge memory model in > turboc. > I ported the BP code from the PDP(*) source to Turbo-C so I could modify it for use in part of a project I did for my MSCS. It will work, but there are a couple of "gotcha" s that have to be taken care of. Note that what follows is from memory; I dont have the source code here at work; finding the exact location of these changes is left as an exercise for the reader. Not all of the changes are in the file BP.C; some are in DISPLAY.C and, as I recall, some are in GENERAL.C, they are all easily findable with grep. First: The malloc problem is very real. The PDP code encapsulates the calls to malloc, calloc, realloc, etc. in its own routines, which as I recall are called "emalloc", "ecalloc", "erealloc", etc. ( look for "calloc" using grep ). These routines do some error checking of the return from the memory allocation routines ( thats where the "no memory" error comes from ), BUT they allow attempts to allocate zero bytes of memory. In SOME implementations of C this is OK ( SUN, Microsoft V4.0 (?) ); however, in the MS-DOS Turbo-C implementation it is NOT OK. Attempting to allocate zero bytes will cause malloc or calloc to return NULL, which the PDP allocation routines take to 'out of memory'. Since allocating zero bytes of memory dosnt make much sense, I just put another test in the PDP routine to check for that and if the request is for zero bytes, return. (GRANTED - it would have been /will be better to find were the zero byte request is being made and fix it there, so that the overhead of the worthless calloc call is avoided, but I was under a time constraint and this was faster). Second: Now that you have the memory problem fixed, you still have some double to float, float to double problems. Fixing the memory allocation will let you get the copyright statement and will display your initial screen, but as soon as you try to ptrain or strain, you'll get a floating point error. This was REAL fun to track down ! The Turbo-C environment apparently provides the same level of protection ( that is automatic promotion of floats to double) that is provided in the system used to compile the executables distributed with the PDP book. Thus you CAN NOT use the debugger to find where the problem is !! ( thanks to Walter Bright and Eric Raymond for their help ). The problem is in the routines that make calls to the pow and exp functions ( again, finding these is left as an exercise for the reader ). In those functions some test are done on the input data first and if it is OK, the actual computation of the return result is done IN THE RETURN STATEMENT. CHANGE THAT. create a temporary variable, 'foo', typed as double, do the computation of pow or exp, BEING CAREFUL TO CASE THE FLOAT INPUT PARAMETER(S) TO DOUBLE and assign the result to 'foo' and THEN RETURN foo. The floating point problem will go away. Third: Now, just to be real safe, there is a PDP function that should be commented out. The PDP source has its own 'sleep' function. But Turbo-C also has a 'sleep' funcition. When you link you'll get a warning about the duplicate function; comment out the PDP version and just use the Turbo-C library version. These changes work and from here you can go on to modify the code further. I have used several different error functions, different termination criteria, etc. I have also ported the BP program to SUN, Pyramid and VAX/VMS and "real soon now" I'll be posting a detailed description of all of the mods that have to be made to the code for each of those ports ( I'll also be sending that info to the Texts Manager AT MIT Press as requested in the book). ============================================================================ (*) McClelland, J, and D. Rumelhart "Explorations in Parallel Distributed Processing: A Handbook of Exercises, Programs and Models", MIT Press, Cambridge, MA, 1987 ============================================================================-- Walt Peterson. Prime - Calma San Diego R&D (Object and Data Management Group) "The opinions expressed here are my own and do not necessarily reflect those Prime, Calma nor anyone else. ...{ucbvax|decvax}!sdcsvax!calmasd!wlp