Path: utzoo!censor!geac!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!ncar!gatech!rutgers!cbmvax!bj
From: bj@cbmvax.commodore.com (Brian Jackson)
Newsgroups: comp.sys.amiga
Subject: Re: "chip" in SAS C
Message-ID: <17235@cbmvax.commodore.com>
Date: 8 Jan 91 18:19:33 GMT
References: <1991Jan6.092515.6970@cs.uoregon.edu> <12545@hacgate.UUCP> <17211@cbmvax.commodore.com> <1991Jan8.081022.21160@ux1.cso.uiuc.edu>
Reply-To: bj@cbmvax.commodore.com (Brian Jackson)
Organization: Commodore, West Chester, PA
Lines: 87

In article <1991Jan8.081022.21160@ux1.cso.uiuc.edu> lrg7030@uxa.cso.uiuc.edu (Loren  Rittle) writes:
>Brian Jackson writes:
>> ANSI C allows the initialization of aggregate auto variables as long
>> as the initializers are constants (which these are.)  See pages 85-86
>> and page 219 of the second edition K&R.  Of course, the 'chip' keyword
>> in SAS C makes this a bit unlikely, but the ANSI C compilers should
>> accept it. The following compiles and runs just fine with Aztec 5.0d:
>> 
>> main()
>> {
>>     int foo[] = { 0,1,2,3 } ;
>>     int x ;
>> 
>>     for( x = 0 ; x < 4 ; x++ )
>>         printf("x = %d\n", foo[x] ) ;
>> }
>Well, I'm not sure if you are implying that SAS/C is less than ANSI C
>or not, but it sure sounds like it to me, so I feel I must defend it,
>without slamming the other guy as you decided you had to.
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
So, being "not sure", you took your thoroughly erroneous assumption and ran
with it, slamming me instead? Try harder to (1) not be defensive about your
favorite compiler, and (2) not put words in other people's mouths.  I
posted that example in Manx because that's what I had handy at the moment.
I use (and like) both compilers and I wasn't "slamming" anything. The
number of people on here with poor ego formation is always surprising to
me. "My computer is better than your computer." "My compiler is better than
your compiler."  "My cola is better than your cola." Give the world a
break.

My statement:

 "The following compiles and runs just fine with Aztec 5.0d:"

This constitutes "slamming" SAS ?? Sheesh++

>First off, the above code compiles and runs just fine under SAS/C also.
>With the strict ANSI switch (-ca) turned on, SAS will disallow the
>chip (and other Amiga extension) keywords, but will still allow the
>__chip, __far, etc. versions of these keywords as allowed under ANSI.
>Of course, the reason
>void main(void)
>{
>  short __chip ImageData[] = {0xffff, 0x0000, 0xffff, 0x0000};
>  <insert your code here!>
>}
>is flagged as an error is that you have no idea during compile time
>whether the stack will be located in CHIP RAM or not (Let's hope not!).
>To futher explain, we know auto variables *must* go on the stack and we
>know that things specified as __chip items *must* go in CHIP RAM.  The
>compiler sees at compile time that these two conditions can most likely
>not be satisfied at run time and *must* flag it as an error.

No kidding.  That's what I said:
	
  "Of course, the 'chip' keyword in SAS C makes this a bit unlikely,..."
	 
Translation:

  The use of the chip keyword in an auto variable creates certain fairly
  obvious problems.  That better?

>OK, I will take one quick poke at Manx, do you guys using Manx really
>have to suffer without a __chip keyword?  ATOM and putting chip data
>in separate source files (and using special compiler switches) went out
>of vogue years ago :-).  OK, how many of you really even know what
>ATOM is? (I guess all the Aztec guys... :-) Send mail and I will
>summarize.

"Us guys using Manx" are probably smarter that you think. But it's nice to
know that we have a mature and informed person we can turn to when we get
lost in this great, big scary world. I have managed for years to get along
without the 'chip' keyword.  I certainly haven't "suffered". It's nice but
certainly not required.  Yes, I know what ATOM is and I manage to get along
just fine without it.

bj

>Loren J. Rittle

 -----------------------------------------------------------------------
 | Brian Jackson  Software Engineer, Commodore-Amiga Inc.  GEmie: B.J. |
 | bj@cbmvax.cbm.commodore.com    or  ...{uunet|rutgers}!cbmvax!bj     |
 |---------------------------------------------------------------------|
 | It requires a very unusual mind to undertake the analysis of        |
 | the obvious."                                                       |
 -----------------------------------------------------------------------