[comp.lang.c] C compilers that can access more memory

malc@tahoe.UUCP (Malcolm L. Carlock) (06/04/87)

--- Line eater food ---

I'm looking for a C compiler to run on '286 AT's or AT clones that can
access more than 64K of program and 64K of data memory.  Microsoft C and
MIX C both seem to be unable to access more than 64K of either.  (This
seems to be based on some difficulty implementing pointers using these
machines' segmented memory setup).

This puts a bit of a damper on any kind of large-scale development work on
these machines using C.

Anyone out there have any ideas?

Thanks.

-----------------------------------------------------------------------------
malc@tahoe.UUCP

johnl@ima.UUCP (John R. Levine) (06/06/87)

In article <496@tahoe.UUCP> malc@tahoe.UUCP (Malcolm L. Carlock) writes:
>I'm looking for a C compiler to run on '286 AT's or AT clones that can
>access more than 64K of program and 64K of data memory.  Microsoft C and
>MIX C both seem to be unable to access more than 64K of either.  ...

Most C compilers on the market now are entirely able to fill your computer's
entire memory with code or data.  You have to tell them to compile code in
the medium or large addressing model, so it generates code and data addresses
that are not all in the same 64K segment.  I've personally used MS C, Lattice,
and Turbo (nee Wizard) to compile programs that ended up with about 600K of
code and 150K of data.  (In case you were wondering, we overlay the code.)
The manuals that come with the compilers usually explain the addressing in
gruesome detail, consult them for more info.
-- 
John R. Levine, Javelin Software Corp., Cambridge MA +1 617 494 1400
{ ihnp4 | decvax | cbosgd | harvard | yale }!ima!johnl, Levine@YALE.something
U.S. out of New Mexico!

darrylo@hpsrlc.HP.COM (Darryl Okahata) (06/08/87)

In comp.lang.c, malc@tahoe.UUCP (Malcolm L. Carlock) writes:

>--- Line eater food ---
>
>I'm looking for a C compiler to run on '286 AT's or AT clones that can
>access more than 64K of program and 64K of data memory.  Microsoft C and
							  ^^^^^^^^^^^
I don't know about MIX C, but both Microsoft and Turbo C CAN access more
than 64K each of program and data memory.  Both compilers have a "medium"
(>64K code, <=64K data), "compact" (<=64K code, >64K data?), "large" (>64K
code, >64K data), and "huge" (>64K code, >64K data with arrays and
structures > 64K) memory models.  Consult the manuals for more info.

>MIX C both seem to be unable to access more than 64K of either.  (This
>seems to be based on some difficulty implementing pointers using these
>machines' segmented memory setup).
>
>This puts a bit of a damper on any kind of large-scale development work on
>these machines using C.
>
>Anyone out there have any ideas?
>
>Thanks.
>
>-----------------------------------------------------------------------------
>malc@tahoe.UUCP
>----------

     -- Darryl Okahata
        ucbvax!ucbcad!ames!hplabs!hpcea!hpsrla!darrylo		<== best path
	hplabs!hpcea!hpsrla!darrylo				<== alternative
	CompuServe: 75206,3074

Disclaimer: the above is the author's personal opinion and is not the
opinion or policy of his employer or of the little green men that
have been following him all day.

mat@mtx5a.UUCP (06/08/87)

> I'm looking for a C compiler to run on '286 AT's or AT clones that can
> access more than 64K of program and 64K of data memory.  Microsoft C and
> MIX C both seem to be unable to access more than 64K of either. ...

uSoft C certainly does support large memory models!  You can mix-and-match to
your choice, but in uSoft C 4.0, the standard options are

Small:	1 segment code, 1 segment data.
Medium:	Many segments code, 1 segment data.
Large:	Many segments code, many segments data, no datum (struct or array)
				may exceed 1 segment.
Huge:	Many segments code, many segments data, no limitation on size of a
		datum (apart from the machine's inherent limits).

Compact: 1 segment code, many segments data.

Playing mix-and-match requires some skill in getting the right things out
of the right libraries.
-- 

	from Mole End			Mark Terribile
		(scrape .. dig )	mtx5b!mat
					(Please mail to mtx5b!mat, NOT mtx5a!
						mat, or to mtx5a!mtx5b!mat)
					(mtx5b!mole-end!mat will also reach me)
    ,..      .,,       ,,,   ..,***_*.

johnt@mmintl.UUCP (John Tangney) (06/09/87)

In article <496@tahoe.UUCP> malc@tahoe.UUCP (Malcolm L. Carlock) writes:
>Microsoft C and
>MIX C both seem to be unable to access more than 64K of either.  (This
>seems to be based on some difficulty implementing pointers using these
>machines' segmented memory setup).

Sorry, Microsoft C 4.00 certainly *does* allow access beyond 64K.  It does
this via different memory "models", whereby code, data or neither is limited
to 64K.  Allowing the limitations provides for the speed/space advantages if
it is known that (eg) code will not go beyond 64K.  Also supported is a
"mixed model", which allows you to specify explicitly which structs or
functions you want to be near or far.

I have been using MS-C 4.00 since it became available.

I don't know anything about MIX C.

johnt

heather@blia.BLI.COM (Heather Mackinnon) (06/10/87)

In article <2163@mmintl.UUCP>, johnt@mmintl.UUCP (John Tangney) writes:
> In article <496@tahoe.UUCP> malc@tahoe.UUCP (Malcolm L. Carlock) writes:
> >Microsoft C and
> >MIX C both seem to be unable to access more than 64K of either.  (This
> >seems to be based on some difficulty implementing pointers using these
> >machines' segmented memory setup).
> 
> Sorry, Microsoft C 4.00 certainly *does* allow access beyond 64K.  It does
> this via different memory "models", whereby code, data or neither is limited
> to 64K.

Microsoft C 4.00 does allow access beyond 64K so long as you don't
attempt to use their memory allocation/free functions in more than one
data segment and the stack segment is in the same segment as the data
segment.  This makes it awkward to use more than one data segment.  At
the OS/2 developers' conference last week, I brought this up and
Microsoft promised that this would be fixed "soon".

You can currently use more than one data segment if you are very
careful and willing to do quite a bit of finagling to make it work.  If
you have a few very large arrays, it will work fine to move them to a
new data segment.  If you have lots of dynamically allocated memory,
then you'll have to do some careful work with memory allocation to get
it to fly.


Heather Mackinnon
Britton-Lee, Inc.

usenet@edm.UUCP (06/11/87)

In article <496@tahoe.UUCP>, malc@tahoe.UUCP (Malcolm L. Carlock) writes:
> I'm looking for a C compiler to run on '286 AT's or AT clones that can
> access more than 64K of program and 64K of data memory.  Microsoft C....

 I believe that Microsoft (at least) has flags for use of the -l(arge) and
-m(edium) memory models. These should allow the use of >64k total, but
you are still limited to 64k in any given array/object.
> 
> This [64k limit] puts a bit of a damper on any kind of large-scale development
> work on these machines using C.

Or just about any other language.
> Anyone out there have any ideas?
Get yourself a REAL machine :-?

dave@sds.UUCP (dave schmidt x194) (06/12/87)

In article <161@edm.UUCP>, usenet@edm.UUCP (usenet control) writes:
> In article <496@tahoe.UUCP>, malc@tahoe.UUCP (Malcolm L. Carlock) writes:
> > I'm looking for a C compiler to run on '286 AT's or AT clones that can
> > access more than 64K of program and 64K of data memory.  Microsoft C....
> 
>  I believe that Microsoft (at least) has flags for use of the -l(arge) and
> -m(edium) memory models. These should allow the use of >64k total, ...

Yes, medium model allows you multiple code segments and large model allows
for multiple data and code segments, allowing your programs to access
>64K of data and code.  There is also a compact model (in 4.00 anyway)
that has one code segment and multiple data segments.

> ... but you are still limited to 64k in any given array/object.
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This limitation can be circumvented by using the "huge" model that MSC
provides (this model may not exist prior to v. 4.00, I don't know).
As I recall, in the huge model arrays may be of any size that will
fit in memory as long as each array element is smaller than 64K.

Also, you can use huge data elements in any model that you want --
declare your pointers as "huge" (e.g., char huge *hugeptr;) and point
them at memory obtained from halloc().  You should be aware that halloc()
is a trifling restrictive in that if the size of the requested array
is >128K, then the size of an array element must be a power of 2.
Memory obtained from halloc() may be freed via hfree().  See the manual
for more info.

platt@emory.UUCP (Dan Platt) (06/16/87)

In article <496@tahoe.UUCP> malc@tahoe.UUCP (Malcolm L. Carlock) writes:
>I'm looking for a C compiler to run on '286 AT's or AT clones that can
>access more than 64K of program and 64K of data memory.  Microsoft C and
>MIX C both seem to be unable to access more than 64K of either. 
>these machines using C.
>...
>Anyone out there have any ideas?

MS C ver 4.0 can access over 64k in code, and data structures larger than
64k.  By judicious use of pointers and malloc(), many structures in excess of
64k may be written in ver3.0.  The code segments may not exceed 64k; this 
meaning that the compiled code for any one compiled segment may not exceed
64k, but lots of these may be linked together to produce code in excess of
64k.  (This is also true of their Pascal, which has extended memory allocation
routines like malloc()).  So, at least for Microsoft C, there should be no
real problem as far as running into code or memory problems (your memory
is the limit).

Dan