kminor@ms.uky.edu (Kevin R. Minor) (10/25/89)
Hello. I have a couple of questions about Turbo C and how it handles memory. 1. What would be the best function to use to see how much available RAM I have? Looks like coreleft () is the best choice. 2. How does Turbo C use memory, in terms of variables and such? I guess I should explain what I want to do. I am wanting to create an array which depends on the RAM of the specific computer. (if the computer only has 256k, don't allocate as much.) I know that malloc () will give me the memory I need, but what I'm not sure about is the overhead of other routines. I have set aside 10,000 bytes for my stack. Does other memory get used besides the stack, or would I be safe to allocate the unused RAM for my array? Thanks in advance. Kevin (kminor@ms.uky.edu) -- Not much going on around here.
baalke@mars.jpl.nasa.gov (Ron Baalke) (10/26/89)
In article <13042@s.ms.uky.edu> kminor@ms.uky.edu (Kevin R. Minor) writes: > >2. How does Turbo C use memory, in terms of variables and such? > >I guess I should explain what I want to do. I am wanting to create >an array which depends on the RAM of the specific computer. (if the >computer only has 256k, don't allocate as much.) I know that >malloc () will give me the memory I need, but what I'm not sure about >is the overhead of other routines. I have set aside 10,000 bytes >for my stack. Does other memory get used besides the stack, or would >I be safe to allocate the unused RAM for my array? There are 3 areas of memory that Turbo C utilizes. They are the stack, global memory and the heap. The stack size is defaulted to 4K and is mainly used for popping variables into in function calls and is usually sufficient unless you are writing an extremely large program. The stack size can be increased but it is a bit tricky. Global memory is set at 64K and cannot be increased. This is the area where all of your variables are declared outside of a function, normally at the top of the file after the #include statements. This size is set at 64K because that is the size of a segment in the 8088/80286/80386 chips. The heap is all of the memory left over that the stack and global memory doesn't use. (Remember MS-DOS + any TSR's will also be using some of the heap memory). Normally you would use the heap for large memory uses. The only way to access to heap is with the malloc/calloc/realloc/free routines. In your case of setting aside 10,000 bytes you can either declare a global variable, or declare a pointer to the heap by using the malloc and free functions. Ron Baalke | (818) 541-2341 x260 Jet Propulsion Lab M/S 301-355 | baalke@mars.jpl.nasa.gov 4800 Oak Grove Dr. | Pasadena, CA 91109 |
chris@mimsy.umd.edu (Chris Torek) (10/26/89)
In many articles many people ask about Turbo C, Microsoft C, and other IBM PC / MS-DOS compilers. Unfortunately, they all ask on comp.lang.c (or whatever its name might be on the remote side of various gateways) instead of in a newsgroup about IBM PCs. Can we keep questions about specific implementations in implementation specific newsgroups, please? (Obviously the answer is `no' :-) ) For instance, no one should be asking about the openlog() routine on comp.lang.c, because that is a 4.[23]BSD C library routine. The important part is `4BSD', not `C library'. The same goes for `IBM PC C compiler': the important part is first `IBM PC', and only *then* `C compiler'. -- `They were supposed to be green.' In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
Bob.Stout@p6.f506.n106.z1.fidonet.org (Bob Stout) (10/26/89)
Your best bet would be to allocate your arrays off the far heap. This is automatic when using large, huge, or compact models, and can be forced in the other models by specifying your arrays with far pointers and using farmalloc().
unkydave@shumv1.uucp (David Bank) (10/26/89)
In article <20401@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes: >In many articles many people ask about Turbo C, Microsoft C, and other >IBM PC / MS-DOS compilers. Unfortunately, they all ask on comp.lang.c >(or whatever its name might be on the remote side of various gateways) >instead of in a newsgroup about IBM PCs. > >Can we keep questions about specific implementations in implementation >specific newsgroups, please? (Obviously the answer is `no' :-) ) For >instance, no one should be asking about the openlog() routine on >comp.lang.c, because that is a 4.[23]BSD C library routine. The >important part is `4BSD', not `C library'. The same goes for `IBM PC C >compiler': the important part is first `IBM PC', and only *then* `C >compiler'. >-- >`They were supposed to be green.' >In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) >Domain: chris@cs.umd.edu Path: uunet!mimsy!chris I'm afraid, Mr. Torek, I must disagree. And not just because I have a question pending on the net. :-) C is C is C. Whether it is implemented on a Sun, VAXen, Itsy Bities, or whatever. I was always under the impression that one of the great strengths of "C" was its portability (that and the ability of syntactically incorrect code to compile anyway! <GRIN> ) If this is true, then the machine of implementation attached to given question becomes distinctly less relevant. The question deals with the "C" language, it would seem to me to belong in "comp.lang.c" regardless of the compiler involved. Further, what are the owners of "less than common" machines to do?? Say I have a "C" compiler for my powerful Timex PC. There is no "comp.sys.timex.pc" I have seen on the net. Must such people be relegated to "dev.null" simply because they got suckered by a slick ad??? Respectfully....... Unky Dave unkydave@shumv1.ncsu.edu
lwh@harpsichord.cis.ohio-state.edu (Loyde W Hales) (10/26/89)
In article <20401@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes: >In many articles many people ask about Turbo C, Microsoft C, and other >IBM PC / MS-DOS compilers. Unfortunately, they all ask on comp.lang.c >(or whatever its name might be on the remote side of various gateways) >instead of in a newsgroup about IBM PCs. > >Can we keep questions about specific implementations in implementation >specific newsgroups, please? (Obviously the answer is `no' :-) ) For >instance, no one should be asking about the openlog() routine on >comp.lang.c, because that is a 4.[23]BSD C library routine. The >important part is `4BSD', not `C library'. The same goes for `IBM PC C >compiler': the important part is first `IBM PC', and only *then* `C >compiler'. I completely DISagree with you, Chris. C-related questions under certain implementations are C questions. I admit that the newsgroup has seen several of these for implementations ranging from Sun workstations to ATARI STs, but I feel this is in course with the newsgroup. From your perspective, posting to comp.atari, for example, can promote the argument ``why are you cluttering our newsgroup with C-specific questions?'' I really don't mean to insult, this is just another opinion. I find the system-related questions, no matter how system-dependent, to be enlightening. I also find I can usually predict the answer from a general background in C. -=- Department of Computer and Information Science Loyde W. Hales, II The Ohio State University lwh@cis.ohio-state.edu 2036 Neil Avenue Mall, Columbus, Ohio 43201
tneff@bfmny0.UU.NET (Tom Neff) (10/27/89)
Host-related questions don't belong in comp.lang.c REGARDLESS of host. Arguing about mkdir() is just as bad as gossiping about VGA graphics libraries. Both should be consigned to the appropriate OS or hardware group. PC platform people are the newcomers here so they get dumped on a little harder. Turbo C and MSC are "real C" but this doesn't mean that all possible questions or statements one can form containing the words "Turbo C" or "MSC" belong in this newsgroup. -- 1955-1975: 36 Elvis movies. | Tom Neff 1975-1989: nothing. | tneff@bfmny0.UU.NET
chris@mimsy.umd.edu (Chris Torek) (10/27/89)
>In article <20401@mimsy.umd.edu> I wrote: >>In many articles many people ask about Turbo C, Microsoft C, .... >>Can we keep questions about specific implementations in implementation >>specific newsgroups, please? On rereading what I wrote (see parent articles for details), I realised that this was ambiguous. The followup below agrees: In article <4316@ncsuvx.ncsu.edu> unkydave@shumv1.uucp (David Bank) writes: >... C is C is C. Whether it is implemented on a Sun, VAXen, Itsy Bities, >or whatever. However, `C' is (as a current best definition) the language and library routines as given in the proposed ANSI C standard. This includes things like printf() and fopen(), but it does not include things like findfirst() and findnext() (or whatever they are called). It does not include scandir(). It does not include openlog() (my earlier example). It does not even include `near' and `far' pointers, discussion about these (such as `should C provide more flavours of pointers since there are lots of segmented machines') being much closer to being about C in general than about C-on-machine-X-with-compiler-Y. Discussions about particulars of C-on-machine-X-with-compiler-Y are the ones to which I was referring in `>>' above. >Further, what are the owners of "less than common" machines to do?? In general, we suffer. (Anyone want a used TRS-80 model 1 level 2 with 48 kB of RAM? One of the 4116s in the EI is bad. The screen is also a bit melted from having been left in the car in the sunshine.) The Officially Approved procedure for dealing with such things is to post a message saying `I want to form a mailing list about this machine'. Such a message would normally belong in comp.sys.misc, unless it were something like `I want to form a mailing list about implementing language L on this machine', in which case it is borderline. Here, for instance, is an example of a question which should NOT have been posted to comp.lang.c (name removed to protect the guilty): >Newsgroups: comp.lang.c,comp.databases,comp.sources.wanted >Subject: ndbm manual info >I am looking for any manual information on the ndbm C language database >routines. ... These routines do happen to be written in C, but are specific to 4.3BSD Unix and systems that have copied them from 4.3BSD Unix. A better choice of newsgroups would have been `comp.unix.questions,comp.databases, comp.sources.wanted' (and comp.databases is rather weak, given what ndbm is :-) ). -- `They were supposed to be green.' In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
mcdonald@uxe.cso.uiuc.edu (10/27/89)
>Further, what are the owners of "less than common" machines to do??
They have, mostly, their own groups too - there is a comp.unix.*,
for unix machines, which are less than common, and comp.os.vms
for VMS VAX's, which are less than common. Face it folks: there
are ONLY two common machines today: IBM-PC's and clones, and
Macintoshes.
You can clutter comp.lang.c with machine specific questions, or you
can
clutter comp.sys.fubar with language specific questions. Clutter
is in the eyes of the beholder.
The real no-no seems to me to be duplication of requests in both
places.
Doug McDonaldbright@Data-IO.COM (Walter Bright) (10/28/89)
In article <20401@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes:
<In many articles many people ask about Turbo C, Microsoft C, and other
<IBM PC / MS-DOS compilers. Unfortunately, they all ask on comp.lang.c
<instead of in a newsgroup about IBM PCs.
As long as there is no comp.lang.c.ibmpc group, this *is* the right group.
Discussions about specifics of various c compilers is quite appropriate
here. It's certainly more interesting than the endless debate over whether
NULL == 0.unkydave@shumv1.uucp (David Bank) (10/29/89)
I respect your point, Mr. Torek. However, I still feel just because
a question contains some application/compiler-specific elements, such
should not be excluded out-of-hand.
One of the alternatives you suggested was "comp.sources.wanted"
Now THAT is a weak newsgroup. Since Posting my MS C/QuickC question
on "comp.lang.c" instead of the former group, I have received quite
a lot of response. I got nothing back on "comp.sources.wanted"
Let me take a moment to publically thank those who've responded
to my question. My mail handler doesn't thank you, but *I* do! :-)
Anyway, one person (in E-Mail) made the comment that the "legit"
stuff in the net is not nearly as interesting as some of the problems
or questions posed by people giving specific architechtures or
compilers. I agree (my opinion).
Respectfully....
Unky Dave
unkydace@shumv1.ncsu.edubobmon@iuvax.cs.indiana.edu (RAMontante) (10/29/89)
Chris Torek proposes that machine-specific questions should be posted to a machine-specific newsgroup, and that if no appropriate group exists a mailing-list should be organized.... This seems excessive. Chris, are you really going to take the time and effort to create a new mailing-list, possibly generating lots of net discussion (bandwidth) in the process, just as a preliminary to asking if anyone has a replacement screen for your TRS-80? I suggest that a more reasonable approach would tolerate the question in a marginally related group, with the proviso that answers should be mailed rather than broadcast. Surely this would consume less bandwidth than the attempt to create a mailing-list for the sole purpose of answering one question. Meanwhile, reluctantly compounding the whole furshlugginer mess... baalke@mars.UUCP (Ron Baalke) <2004@jato.Jpl.Nasa.Gov> : -unless you are writing an extremely large program. The stack size can be -increased but it is a bit tricky. It is easy. Assign the desired value to the implementation-defined variable _stacklen. Calculating the desired value is a bit tricky. All this is documented for TC v2.0 and is in READ.ME doc. for v1.0. Followups about TC should go to comp.sys.ibm.pc. Followups about appropriateness of the question should also go out of comp.lang.c, but I don't know how to redirect followups to two different newsgroups. Don't post flames, mail them to me and I'll increase their entropy.
wew@naucse.UUCP (Bill Wilson) (10/30/89)
From article <73211@tut.cis.ohio-state.edu>, by lwh@harpsichord.cis.ohio-state.edu (Loyde W Hales): > In article <20401@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes: >>In many articles many people ask about Turbo C, Microsoft C, and other >>IBM PC / MS-DOS compilers. Unfortunately, they all ask on comp.lang.c >>(or whatever its name might be on the remote side of various gateways) >>instead of in a newsgroup about IBM PCs. >> > > I completely DISagree with you, Chris. C-related questions under certain > implementations are C questions. I agree with Lloyd's ssentiments. C is C no matter what machine it is being run on. Yes, there are OS specific functions etc. but I find the general discussion of these enlightening. In my position, I must convert code to and from many different systems. I do not necessarily want to subscribe to a gazillion different news groups that do not interest me just to see a few questions on C. Instead of complaining why not try to help? -- Let sleeping dragons lie........ | The Bit Chaser ---------------------------------------------------------------- Bill Wilson (Bitnet: ucc2wew@nauvm | wilson@nauvax) Northern AZ Univ Flagstaff, AZ 86011