Path: blue.weeg.uiowa.edu!news.uiowa.edu!hobbes.physics.uiowa.edu!newsfeed.ksu.ksu.edu!moe.ksu.ksu.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!swrinde!pipex!uknet!EU.net!uunet!newsflash.concordia.ca!altitude!altitude!not-for-mail
From: vandry@CAM.ORG (Phillip Vandry)
Newsgroups: comp.sys.apple2.programmer
Subject: Re: memory models in Orca/C
Date: 11 Jun 1994 02:18:44 -0400
Organization: Communications Accessibles Montreal
Lines: 76
Message-ID: <2tbl04$3s8@altitude.HIP.CAM.ORG>
References: <2t6bou$ir0@news.tamu.edu>
X-Newsreader: NN version 6.5.0 #3 (NOV)

j0p7771@tam2000.tamu.edu (Jason Perez) writes:

>  i'm confused about the memory models used by Orca/C.  the small
>memory model is for globals/arrays smaller than 64K, while the
>large memory model can have arrays/globals larger than 64K.  
>supposedly you're not supposed to use NewHandle or malloc to
>allocate more than 64K at a time using the small memory model.  before
>i read this fine print, i had been doing this same thing, in fact
>allocating memory chunks over 200K in size.  why aren't my programs
>crashing because of this?

In the small memory model, array indexes are 16 bits long. This allows
you to address 64K from the beginning of the array. In the large memory
model, these same indexes are 32 bits long, and this makes them
considerably slower.

But:

char *tmp;

tmp = malloc(200 * 1024);   /* malloc 200K */
read(fd, tmp, 200 * 1024);  /* read in 200K */

In this code, although you are reading 200K of information, you are never
addressing any element of the array past 64K (or any element at all for
that matter). So this code will work under either memory model, and
correctly read in the full 200K.

Also, using the wrong memory model probably wouldn't ususlly cause a crash.
I haven't tested it, but I would expect that

array[65546]     (64K + 10 bytes)

...in the small memory model would actually just turn into array[10]. So you
would most likely get incorrect results.

To recap: any size of array is allowable under any memory model, but elements
beyond the 64K mark can only be addressed in the large memory model, when
using the standard variable[subscript] defeferencing technique.

Final note: the following two lines are equivalent:

array[index]
*(array+index)

The first one is usually used, but the index cannot be larger than 65535 in
the small memory model. Again, I have not tried it, but I think the second
line allows this limitation to be bypassed without changing memory models.
Using it instead of the first line would be equivalent to temporarily turning
on the large memory model.

>  what is the deal with the libraries?  it says in the manual to
>replace Orcalib with Orcaglib.  ok, so do i just delete orcalib
>and copy orcaglib into my library folder?  do i need to reorder my
>library files (i use libc also)?  do i need to rename orcaglib to
>orcalib?  it'd be so much easier if you could have both libraries
>present and the compiler/linker would choose the correct one.

The linker has no idea what memory model was used for a compile of one of
the source files, that's why the choice cannot be made automatically.

To answer your other question - yes, you should replace it, and no, there
is no need to rename orcaglib.

What is the difference anyway? I guess it must be, for example, strlen()
handles strings > 64K only in orcaglib ??? And likewise for a bunch of
functions.

>  i added the #pragma memorymodel 1 to the program i'm currently 
>writing.  i replaced the orcalib library file (and tried lots of
>different combinations of order/library name).  now getopt
>doesn't work.  what's the deal?

Don't know about that.

-Phil