Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!caip!lll-crg!seismo!rochester!kodak!elmgate!jdg From: jdg@elmgate.UUCP (Jeff Gortatowsky) Newsgroups: net.micro.amiga Subject: Re: C Philosophy Message-ID: <478@elmgate.UUCP> Date: Tue, 24-Jun-86 09:30:15 EDT Article-I.D.: elmgate.478 Posted: Tue Jun 24 09:30:15 1986 Date-Received: Thu, 26-Jun-86 04:03:16 EDT References: <8606210754.AA01488@pavepaws> Organization: Eastman Kodak Co., Rochester, NY Lines: 70 Summary: Mat and I agree to disagree. (Oops I meant Matt , sorry guy!) In article <8606210754.AA01488@pavepaws>, dillon@PAVEPAWS.BERKELEY.EDU (Matt Dillon) writes: > Not Wrong, Sorry. My opinion. Refering to the same page on the manual, > I would like to point out that register addressing modes take no longer > using 32 bits than 16 bits. If you take into account that most speed-daemon > hacker-programmers use register declarations for variables in tight loops, > your only looking at an extra fetch every once in a while rather than every > other instruction. > Ok,ok, OPINION..whatever.. You (really the compiler) still have to get that data into the register. And thats still going to take extra time. Yes, if your code is spending most of it's time executing Amiga functions by all means use 32 bits (no choice really). But when I'm writing the glue that brings it all together I look for ANY place 16 bits can be used. I think you over estimate the 68000 a bit. It means smaller, faster, tighter code (not THE best, but at least better), even in REAL programs. Move instructions are still doing most of the work and that means extra bus cycles for a long (the sign extension of 16 bits in the MOVEM instruction is a REAL loser). > > tut tut, don't exaggerate. Using longs in the first place > requires you to extern your functions (16 bit compiler) in the first place > also, so you can still wind up with a lot of junk. I'm not saying declaring > Yup. That's is exactly what I do. Proper declarations and casts where ever they are needed. LOTS more typing for me, but more readable later on as well a (opinion) faster. Make the compiler do what *I* say, not what it *THINKS* I meant. Mind you I'm NOT casting 16 bit ints to longs. For that I use longs in the first place. But I talked about that before. This means lotsa '(struct xxxx *)' casts ecetra, but weeks or months from now I won't be wondering what that function call returns. So maybe that another benny of 16 bit ints. Makes me *THINK* hard about what that function returns, etc. > Agreed, to a point. You are suggesting that the 68000 has limitations when > using 32 bit int's... that is completely incorrect in my view. You should > consider the fact that all addresses must be handled as 32 bits and not > 16 (no crap about .W addressing modes, please.) First off, I've never use absolute short addressing so wouldn't presume to give you any cr*p about it. In *MY* view it's "your already paying the price loading addresses so avoid doing so in data when possible". If extra bus cycles for 32 bits isn't a limitation (no matter how big or small), I don't know what is. > Assembly is fine.... for the 68000. However, I personally find assembly > rather difficult to debug (almost as bad as basic), and drawn out. It's > definately the way to go on a small computer for immensley > important routines, but I try to stay away from it. Also, for you > speed daemons out there, I would like to point at that shaving 10 uS > from a tight loop with a library call in the middle is generally useless. > Huh? You can single step C code? Where'd you get your source level debugger? BTW I have written exactly two assembly routines for the Amiga, so it's not like I'm religous or anything. On the other point, again we agree to disagree. First off if you havn't shaved that 10us off and can, it's not a tight loop. Ten microseconds per iteration? Or just 10us period. Big difference. However we were discussing the merits of 32 bit ints not algorithms. Presumably neither one of us would put that call in, if it was to be tight. One last comment. I *DO* believe in getting it right first, then if needed, making it faster. It's just that many times I find the two go hand-in-hand by using the right data type for the job, no more, no less. Oh well.. On to the next subject, aye? -- Jeff Gortatowsky {allegra,seismo}!rochester!kodak!elmgate!jdg Eastman Kodak Company