[comp.sys.amiga.programmer] "chip" qualifier for Aztec C

withers@nitmoi.enet.dec.com (George A. Withers) (04/09/91)

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

 ------------------------------------------------------------------------------
 George A. Withers, Jr.                  |  "There is no life I know to compare
 Digital Equipment Corp., 97 Piper Road  |   with pure imagination.  Living
 Acton, MA   01720   AT&T: 508.264.2339  |   there you'll be free .. if you 
 Addr: withers@nitmoi.enet.dec.com       |   truly wish to be."  - W. Wonka
 ------------------------------------------------------------------------------
      DISCLAIMER:  "Don't look at me!  I didn't do it!" (Krusty the Clown)

bj@cbmvax.commodore.com (Brian Jackson) (04/11/91)

In article <21925@shlump.nac.dec.com> withers@nitmoi.enet.dec.com (George A. Withers) writes:
>
>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?

I am unaware of this existing in the current Aztec compiler. According
to Aztec, however, the next major release of the Manx C compiler
will have the CHIP keyword.

bj

>Thanks, George

 -----------------------------------------------------------------------
 | Brian Jackson  Software Engineer, Commodore-Amiga Inc.  GEnie: B.J. |
 | bj@cbmvax.cbm.commodore.com    or  ...{uunet|rutgers}!cbmvax!bj     |
 | "We defy augury"                                                    |
 -----------------------------------------------------------------------

dillon@overload.Berkeley.CA.US (Matthew Dillon) (04/11/91)

In article <21925@shlump.nac.dec.com> withers@nitmoi.enet.dec.com (George A. Withers) writes:
>
>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

> ------------------------------------------------------------------------------
> George A. Withers, Jr.		  |  "There is no life I know to compare
> Digital Equipment Corp., 97 Piper Road  |   with pure imagination.  Living
> Acton, MA   01720   AT&T: 508.264.2339  |   there you'll be free .. if you
> Addr: withers@nitmoi.enet.dec.com	  |   truly wish to be."  - W. Wonka
> ------------------------------------------------------------------------------
>      DISCLAIMER:  "Don't look at me!  I didn't do it!" (Krusty the Clown)

--

    Matthew Dillon	    dillon@Overload.Berkeley.CA.US
    891 Regal Rd.	    uunet.uu.net!overload!dillon
    Berkeley, Ca. 94708
    USA

plav@cup.portal.com (Rick M Plavnicky) (04/14/91)

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
>
>> ---------------------------------------------------------------------------
>> George A. Withers, Jr.		  |  "There is no life I know to compa
>> Digital Equipment Corp., 97 Piper Road  |   with pure imagination.  Living
>> Acton, MA   01720   AT&T: 508.264.2339  |   there you'll be free .. if you
>> Addr: withers@nitmoi.enet.dec.com	  |   truly wish to be."  - W. Wonka
>> ---------------------------------------------------------------------------
>      DISCLAIMER:  "Don't look at me!  I didn't do it!" (Krusty the Clown)
>
>--
>
>    Matthew Dillon	    dillon@Overload.Berkeley.CA.US
>    891 Regal Rd.	    uunet.uu.net!overload!dillon
>    Berkeley, Ca. 94708
>    USA


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.


Disclaimer: I bought and use Manx's compiler, but it sure does have its
            shortcomings.

/* Rick Plavnicky ...!sun!cup.portal.com!plav  -or-  plav@cup.portal.com */

jupiter@olympus.mlb.fl.us (Kurt R. Hawkes) (04/14/91)

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                    / \

laughlin@fornax.UUCP (Bob Laughlin) (04/15/91)

In article <41242@cup.portal.com> plav@cup.portal.com (Rick M Plavnicky) writes:
> .........
>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)
> .........

One way to force screen data into CHIP ram is to use the +cd linker
option with Manx 5.0d. This puts all initialized data into CHIP memory.
If the initialized data in your program is largely image data then this
is a reasonable alternative and is preferable to AllocMem'ing CHIP mem
and copying it over.  Manx 5.0d does need the chip keyword though.
-- 
 Bob Laughlin  laughlin@cs.sfu.ca 

dillon@overload.Berkeley.CA.US (Matthew Dillon) (04/16/91)

In article <2492@fornax.UUCP> laughlin@fornax.UUCP (Bob Laughlin) writes:
>In article <41242@cup.portal.com> plav@cup.portal.com (Rick M Plavnicky) writes:
>> .........
>>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)
>> .........
>
>One way to force screen data into CHIP ram is to use the +cd linker
>option with Manx 5.0d. This puts all initialized data into CHIP memory.
>If the initialized data in your program is largely image data then this
>is a reasonable alternative and is preferable to AllocMem'ing CHIP mem
>and copying it over.  Manx 5.0d does need the chip keyword though.
>--
> Bob Laughlin	laughlin@cs.sfu.ca

    That's unreasonable, CHIP memory is at a premium these days.  Only
    the actual *bitmaps* need to be in CHIP.

					-Matt

--

    Matthew Dillon	    dillon@Overload.Berkeley.CA.US
    891 Regal Rd.	    uunet.uu.net!overload!dillon
    Berkeley, Ca. 94708
    USA

waggoner@omews1.intel.com (Mark Waggoner) (04/17/91)

In article <dillon.6541@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes:
>In article <2492@fornax.UUCP> laughlin@fornax.UUCP (Bob Laughlin) writes:
>>
>>One way to force screen data into CHIP ram is to use the +cd linker
>>option with Manx 5.0d. This puts all initialized data into CHIP memory.
>>If the initialized data in your program is largely image data then this
>>is a reasonable alternative and is preferable to AllocMem'ing CHIP mem
>>and copying it over.  Manx 5.0d does need the chip keyword though.
>>--
>> Bob Laughlin	laughlin@cs.sfu.ca

>    That's unreasonable, CHIP memory is at a premium these days.  Only
>    the actual *bitmaps* need to be in CHIP.

>					-Matt



You don't have to put ALL initialized data into CHIP memory.  If you put the
data you need in CHIP in a seperate file you can use the +cd option for that
module and then switch it back to normal allocation for other modules.
I don't remember the appropriate options for doing that.  It is admittedly
not as convenient as a _chip keyword, but you can do what you want to do.


  Mark


Mark Waggoner           waggoner@ichips.intel.com         (503) 696-4590
                       No, I don't speak for intel.

stephane@Chucla.CAM.ORG (Stephane Laroche) (04/20/91)

In article <dillon.6541@overload.Berkeley.CA.US> (Matthew Dillon) writes:
>In article <2492@fornax.UUCP> laughlin@fornax.UUCP (Bob Laughlin) writes:
>>
>>One way to force screen data into CHIP ram is to use the +cd linker
>>option with Manx 5.0d. This puts all initialized data into CHIP memory.
>>If the initialized data in your program is largely image data then this
>>is a reasonable alternative and is preferable to AllocMem'ing CHIP mem
>>and copying it over.	Manx 5.0d does need the chip keyword though.
>>--
>> Bob Laughlin  laughlin@cs.sfu.ca
>
>     That's unreasonable, CHIP memory is at a premium these days.  Only
>     the actual *bitmaps* need to be in CHIP.

It's unreasonable unless you put all your image data in the same file (or
in multiple files) and only use the +cd option on those files.	This is
equivalent to the _chip keyword as long as you don't mix non-chip data with
chip data.

>					  -Matt


 Stephane Laroche   | stephane@Chucla.CAM.ORG	 |  Montreal, Qc.  CANADA
 +1 514 277-8605    | laroche@ee470.ee.mcgill.ca |  McGill University

peter@sugar.hackercorp.com (Peter da Silva) (04/22/91)

In article <1991Apr17.161732.27842@omews63.intel.com> waggoner@ichips.intel.com (Mark Waggoner) writes:
> You don't have to put ALL initialized data into CHIP memory.  If you put the
> data you need in CHIP in a seperate file you can use the +cd option for that
> module and then switch it back to normal allocation for other modules.

I don't believe the linker allows this. I wrote browser with the expectation
that they would eventually do that, with the pointer imagery in a separate
file, but I'm still waiting.
-- 
Peter da Silva.   `-_-'
<peter@sugar.hackercorp.com>.

rzv30@cccvm.ccc.amdahl.com (Rene Vega) (04/24/91)

 
The manx linker will not split data segments into chip and fast memory. I 
developed a program that postprocesses the load module and selectively sets the 
chip memory attribute in sepcific hunks. The only requirement is that the files 
containing the data to be moved into chip memory be compiled with the -mdm 
option. If you're interested, I can post the source code.



Rene' A. Vega
Computer & Systems Architecture