Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!caip!ut-sally!seismo!rochester!kodak!elmgate!jdg From: jdg@elmgate.UUCP (Jeff Gortatowsky) Newsgroups: net.micro.amiga Subject: Re: C Philosophy Message-ID: <476@elmgate.UUCP> Date: Fri, 20-Jun-86 08:45:38 EDT Article-I.D.: elmgate.476 Posted: Fri Jun 20 08:45:38 1986 Date-Received: Sun, 22-Jun-86 03:35:36 EDT References: <8606161842.AA20107@pavepaws> Organization: Eastman Kodak Co., Rochester, NY Lines: 94 Summary: Arguments for and against 32 bit data on the 68000,010,012 In article <8606161842.AA20107@pavepaws>, dillon@PAVEPAWS.BERKELEY.EDU (Matt Dillon) writes: > > >George Robbins: > > > > The Berkeley in you is showing. If you have a machine that has > >a 16 bit processor, runs faster with 16 bit operands and generates > >smaller code, it is just plain lazy to say 'looks like 32 bits to me'. > > > > As you pointed out, assuming that pointers and integers are > >the same length cause no end of portability problems. The people who > >decided that an int on a VAX should be 32 bits did the micro-world a > >big disfavor, and the doubled it with a 'nothing smaller than a VAX > >is worth worrying about...' attitude. > > > > Call a pointer a pointer, and an integer an integer (oops, > >I mean a short)... > > No, the practicality in me is showing. I don't have a machine that > has a 16 bit processor (IBM's don't count; all of INTEL's processors are > screwed up anyway). I consider the VAX and 68000 to be 32 bit machines, even > though they have 16-bit external data paths. The registers are 32 bit. > With a good compiler, you don't really need to worry about the longer > access time for long words over words.. it's trivial compared to > other possible improvments in code generation. Additionaly, when 32 bit > things are in 32 bit registers, the generated code is not any slower. The > only real loose with 32 bit integers is with multiplication. Wrong. Sorry but this is not the case. The 68000 inside your Amiga is a 16 bit processor that just happens to have 32 bit registers and a 32 bit register-to-register data path. I call your attention to Tables starting on page 187 of the MC68000 Programmer's Reference Manual, 4th edition (C) 1984 Motorola Inc. These tables clearly show that almost all instuctions pay a penalty for using a long. Since I've seen the code generated by the Lattice compiler (32bit ints), you ARE paying the price. And it's is NOT insignificant! Not in the context of a compiler that produces mediocre code in the first place. You need to help it along all you can. Are you using Greenhills on a SUN? Manx? Lattice? Of course if your using assembler for many functions..... > > Some people are paranoid about all of this, and NEVER use 'ints'... > They use either shorts or longs (which have definate minimum bit lengths). I'm not paranoid about ints at all. I just beleive in using the right data type for the job. No more, no less. Further, using explict shorts and longs tell OTHER programmers EXACTY what I intend the range of values that variable might take on. In most cases Shorts and Longs get the point across clearly (MegaMax being an unfortunate exception). > > There are many cases where I have two int's and want to multiply them > together. With a 16 bit compiler, I must force these int's to long's before > multiplying or my result will be truncated to 16 bits.... makes for messy > code. One can say that I'm lazy in the fact that I do not want to deal with > or worry about having to cast my integers to longs (or vise versa). This > whole deal about pointers is actually quite trivial compared to other reasons. > For instance, the 16 bit compiler people have to cast some passed values to > long for function calls such as Seek(), or extern more than a reasonable > number of functions which return 'longs'. 32767 is simply not a large > enough number for me to use as a default. Then use longs in the first place and be done with it! Again choose the right data type for the job at hand. You saved a couple of micro seconds by not having to cast these 16 bit ints to longs and loss SECONDS (or much much more) thoughout the rest of the program by forcing the poor CPU to deal with an extra bus cycles on every data fetch. Penny wise, pound foolish. > The reason I don't care to make my software (immediately) transportable > to these other processors is simply that my software wouldn't apply to these > other processors. In fact, anything anybody writes for the latter would be > completely custom and non-portable anyway, would it not? > > -Matt Very true. Unless you stick to tried and true K&R/UNIX(tm) stdio functions your not going to easily port your code. Even these functions give bazaar results from compiler to compiler. Of course there IS no better way to speed code along than to use the right algorithm in the first place. That's where the REAL time will be gained or lost. But to ignore the target machines CPU limitations will still cost you in the final result. It depends on your feelings of 'when is fast, fast enough?' . Me, I'm never satisfied. Not till I know that given my own 'brain' limitations, and the compiler's code generating limitations (after all, I don't want to code it all in assembler), I've done the best I can. And that to *ME* means using 16 bit shorts were 16 bit shorts are all that's needed. At least until someone comes up with a reasonably priced 68020 board/machine with 32 bit memory. -- Jeff Gortatowsky {allegra,seismo}!rochester!kodak!elmgate!jdg Eastman Kodak Company