Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!aplcen!haven!vrdxhq!bms-at!stuart From: stuart@bms-at.UUCP (Stuart Gathman) Newsgroups: comp.sys.ibm.pc Subject: Re: Looking for a decent C compiler Summary: not quite Message-ID: <166@bms-at.UUCP> Date: 29 Jun 89 23:25:12 GMT References: <3741@udccvax1.acs.udel.EDU> <1440@bucket.UUCP> <7272@cg-atla.UUCP> Organization: Business Management Systems, Inc., Fairfax, VA Lines: 24 In article <7272@cg-atla.UUCP>, fredex@cg-atla.UUCP (Fred Smith) writes: > In article <1989Jun17.081153.19335@ziebmef.uucp> mdfreed@ziebmef.UUCP (Mark Freedman) writes: > >(if you're running MS-DOS, you *can't* get around the 64k structure limit) > > I thought that one could dynamically allocate objects larger than 64K in the > >HUGE memory model, or by using HUGE pointers. According to the reference for This is almost true. You can allocate arrays > 64K with huge model/keyword. HOWEVER, each array element must still be < 64K. In fact, each element must be of a size evenly divisible into 65536! (Some compilers may pad for this automatically. MSC 3.0 does not.) The reason is that references to a fund- amental type cannot cross a segment boundary. Yes, the compiler could insert extra padding in a structure just at the segment boundary, but getting all the structures in an arbitrary array to start at a segment boundary is the real problem. PS. No flames about stupid segments. The 286 is a 16 bit processor. The fact that it can run 32-bit programs with a few kludges in no way detracts from it's 16-bit performance. (Which is faster than a 386 at the same clock, BTW. Yes, 25Mhz 286s are available.) -- Stuart D. Gathman <..!{vrdxhq|daitc}!bms-at!stuart>