Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!rex!uflorida!mlb.semi.harris.com!olympus!jupiter
From: jupiter@olympus.mlb.fl.us (Kurt R. Hawkes)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: "chip" qualifier for Aztec C (V5.0d)?
Message-ID: <18fb3789.ARN16eb@olympus.mlb.fl.us>
Date: 14 Apr 91 02:22:17 GMT
References: <21925@shlump.nac.dec.com> <dillon.6321@overload.Berkeley.CA.US>
 <41242@cup.portal.com>
Reply-To: jupiter@olympus.mlb.fl.us
Organization: Olympus, Melbourne, FL
Lines: 73

In article <41242@cup.portal.com>, Rick M Plavnicky writes:

> dillon@overload.Berkeley.CA.US (Matthew Dillon) recently wrote:
>
> >In article <21925@shlump.nac.dec.com> withers@nitmoi.enet.dec.com (George A. W
> >
> >>In some previous article gone by the wayside in the great
> >>Assembly/C Battle, Matt Dillon mentioned that Dice had
> >>Amiga-isms such as the "chip" type qualifier to force a
> >>single variable into chip RAM like SAS/C AND Aztec C.	I
> >>only recently upgraded to v5.0d and I didn't see mention
> >>of this in the manual so does such a qualfier exist and, if
> >>so, what is it?
> >>
> >>Thanks,
> >>George
> >
> >    Well, I *assumed* that Aztec had added it, I don't have 5.0d myself.
> >    If they haven't, well, there are no excuses left for them.
> >
> >				    -Matt
> >
>
> This comes up every so often.  Manx currently does NOT offer the ``chip''
> keyword in their product.  (Current product is referred to as 5.0e, but
> signs on as 5.0d dated Sep 30 1990)
>
> However, there WAS some mention made on their support BBS recently:
>
> <begin included material>
>
>    MESSAGE: 5492				DATE/TIME: 04-04-91  6:44pm
>    FROM   : JEFF DAVIS (SYSOP)                RECEIVED : NO
>    TO     : PAT HEUVEL			PRIVATE  : NO
>    SUBJECT: Compiler Suggestion		THREAD	 : YES
>    FOLDER : D, "Amiga Folder"
>
>    We are going to add the chip keyword, probably for the release after
>    the 5.2 release.
>    - Jeff Davis
>
> <end included material>
>
>
> Anyway, Matt's right: there's no excuse.

Well, I've come across this same problem.  I discovered that the
linker has two options which allows one to specify sections of the
code to be loaded into chip or fast ram.  Look on page 5-15 of the
Aztec C Reference Manual.  Here is a quick summary.

+c   -	 load into chip memory	      c - executable code
+f   -	 load into fast memory	      d - initialized data
				      b - uninitialized data (bss)

So for example:  ln +cdb +fc ...  would cause the executable
		 code to be loaded into fast memory while data resides
		 in chip memory.

Generally, I use ln +cd ... which specifies that the initialized data
to be loaded into chip while uninitialized data and code be loaded
normally (fast ram in my cast beacuse of FastMemFirst).

I hope this helps...


--
  Kurt Hawkes		   Amiga 2000  (Hey, it works! Works well!)
		     // 	       (Just cover up the C word!)
  Warning:	    //	Choose:
    Dangerous	   //	   (a) jupiter@olympus.mlb.fl.us                 \
    Thinker    \\ //	   (b) jupiter@cis.ufl.edu                        \
    On Board!	\X/	or (c) khawkes@gnu.ai.mit.edu                    / \