ok@edai.UUCP (Richard O'Keefe) (06/14/84)
G'day. I've just come across a C compiler for M6809s, and was rather shocked to find that its authors had decided to make char = 8 bits short = 8 bits int = 8 bits long = 16 bits I thought I could rely on "int i = 1000;". As I've said in an earlier message, my reading of K&R is that "int" has to be big enough to hold the difference between the addresses of the ends of the largest array the programmer is allowed to declare. Whether you agree or not, this selection would seem to make it pointlessly difficult to port C programs to/from other compilers. What do other opinionated people think about this? The compiler has a nice feature: there is a "readonly" storage class. readonly declarations must be initialised, and the data are placed in the text area. Is this part of some new standard? There should be a distinction between "readonly int x = 1;" and "static readonly int x = 1;" but that would seem to mess up the syntax (worth it). Speaking of storage classes, I know that in some compilers I *can* say extern <declaration>; .... .... <real declaration for same thing>; but there's a compiler for a 32-bit midi which generates bad loader code for this. Clearly a bug, but is the bug failure to spot my abuse of the language, or bad code generation for a correct program?
gwyn@BRL-VLD.ARPA (06/17/84)
From: Doug Gwyn (VLD/VMB) <gwyn@BRL-VLD.ARPA> That 6809 C implementation is clearly a "toy" since practically NO useful existing C program can survive having ints reduced to the range -128..127. The "readonly" attribute is a non-standard extension to the language. The ANSI C committee has come up with the similar but more general "const" type modifier. If extern thing; thing definition does not work then that is clearly an incorrect implementation. Out of curiosity, what 32-bit midicomputer C exhibits this problem?
henry@utzoo.UUCP (Henry Spencer) (06/20/84)
Richard O'Keefe observes that at least one 6809 compiler makes int
only 8 bits. Clearly there's a compromise here: the 6809 is not
a great 16-bit machine, and it does much better if things are 8 bits
whenever possible. C, alas, basically requires everything to turn
into ints whenever you do anything. I fear that this tradeoff will
exist for almost any 8-bit machine: do you want fast code, or portable
code? Clearly we're not going to get a consensus of all customers on
this, because needs differ.
The question of whether C int's are required to be big enough to hold
the difference between pointers to the two ends of an array is, uh,
unresolved. 68000 C compilers with 16-bit int and 32-bit addresses
have the same problem.
As far as the "readonly" storage class, the draft ANSI C standard does
have a construct along these lines, although it's not quite the same.
They haven't done it as a storage class, so you can make such things
static without any problems.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henrydgary@ecsvax.UUCP (06/23/84)
>From: Doug Gwyn (VLD/VMB) <gwyn@BRL-VLD.ARPA> > >That 6809 C implementation is clearly a "toy" since practically NO >useful existing C program can survive having ints reduced to the range >-128..127. Just an observation: For some (admitedly limited) purposes, such as writing a game, this C might be quite nice. As someone much wiser than I has observed, "One man's Mede is another man's Persian." D Gary Grady Duke University Computation Center, Durham, NC 27706 (919) 684-4146 USENET: {decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary