🚀 go-pugleaf

Summary: i have a problem i beleive to be with 64k segment boundries and 
the huge model under borland turbo c++ v1.01, and want to know what points 
to watch out for...

I'm using Borland Turbo C++ version 1.01, but as a straight C compiler, 
not C++.  So first question, is this the latest version?

The program I'm writing requires the use of large arrays of structs (the 
structs themselves range from 25-45 bytes).  I want the arrays has big as 
possible (ie. bigger than 64k), so i'm compiling under the 'huge' memory 
model, and using 'huge' pointers to point to the structs.  Processing is 
all through linked-lists and recursive descent thereof.  (Ie. I'm viewing 
the arrays as pools of free nodes for the lists).

The structs contain real numbers, changing between float and double has 
no obvious effect.

The code can be compiled both on a PC using the above compiler, and on a 
CBM amiga using Manx Aztec C 5.2a.  On the amiga, it works perfectly, on 
the PC it doesn't.  I'm assuming that the problem has something to do with 
the 64k segment boundry (which the amiga doesn't have).  The two places it 
falls down are in a three dimensional display routine, where the floating 
point variables positioning the display seem to drift off, then it 
crashes.  And in a list-processing/math routine which just crashes as it 
recurses down the list.

Crash == locks up until Ctrl-Alt-Del

There is some cumulative effect, in that if i use the display routine, but 
exit before the 3 or 4 zoom/pan/rotate operations it will survive before 
crashing, then try the list routine, the list routine crashes sooner than 
if i went straight to it without first using the display routine.

once, when debugging with small arrays (to allow enough mem for the 
debugger) i found it would crash at varying positions in this block of 
code, and yet if the first two lines are ok the rest should be too.

typedef double REAL;

    xVoxOrg-=xVoxRng/(REAL)xVoxels;
    xVoxRng+=2.0*xVoxRng/(REAL)xVoxels;
    yVoxOrg-=yVoxRng/(REAL)yVoxels;
    yVoxRng+=2.0*yVoxRng/(REAL)yVoxels;
    zVoxOrg-=zVoxRng/(REAL)zVoxels;
    zVoxRng+=2.0*zVoxRng/(REAL)zVoxels;

i have spent ages fiddling with the compiler options, i even wrote a 
program to create makefiles with every possible combination of compiler 
settings that i thought could be even vaugely relevant (stack 
tests/alignment/processors...).  The code is split 
into about 7 modules, and neither the code nor the static data bits exceed 
64k (but together they do).  I'm using the 'huge' memory model, and huge 
pointers to the structs.  The arrays are allocated with calls to 
farcalloc.  There are some local pointers to pointers to 
structs that i haven't specifically declared as huge, but i understand 
that's the default under the huge model.

I have tried it numerous machines (currently a 386/387 machine).  There is 
a 0 byte memory change before and after on the amiga, so I think the codes 
fairly right.  Fianlly, I have one executable for the pc were the display 
code works, but it is out of date.  The display code wasn't working on 
earlier or later versions, so i don't know if that's just a fluke 
alignment or what.  the problem didn't exist with the very earliest 
(smallest) versions of the program.

Basically any suggestions about traps and tricks with huge memory models, 
or any other possible explanations would be greatly appreciated, this is 
beginning to be a major snag.  I'm quite happy to be told it's my fault, 
not the compiler's, but it doesn't crash in the same place much (see 
above), and works perfectly on the other platform.


Thanks, Terry Brown (brownt1@lincoln.ac.nz)