Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!UTCVM.BITNET!MQUINN From: MQUINN@UTCVM.BITNET Newsgroups: comp.sys.apple2 Subject: Re: Re- HLLs vs. Assembly Message-ID: <9104282110.AA07682@apple.com> Date: 28 Apr 91 20:49:14 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 70 On Fri, 26 Apr 91 23:15:06 GMT said: >>with this). Whenever she declares an integer variable, she ALWAYS declares >>it as a FOUR BYTE variable... even when she KNOWS that it's value will always >>contain a number between 0 and 199 (a variable for the Y location on a >320x200 >>res. screen). She does that because she doesn't know that a 2 byte variable > >You are incorrect. You do not KNOW that the variable will always be less than >256, YOU are ABSOLUTELY, POSTIVITELY, WRONG!!! First of all, I -=>DO<=- know that it will always be less than 201 (not 256 as you stated). This program will not (YES, I KNOW THIS) be ported to anyting higher than CGA in the near future (or not to distant future). It's intended to be run on a 4.77Mhz XT with CGA graphics. Speed in this animation program is of utmost importance, concidering the language AND computers are both extremely slow. This program will almost definitely NOT be upgraded ever. It's a tutorial and will be useful as is for decades to come. >two bytes might be possible 64k scan lines is unlikely in the near future. Again, you're wrong. Knowing how this compiler uses bytes for variables, I know that it always assumes a sign bit. In other words, one byte can contain the range (-127..+127). Therefore, we need TWO bytes to represent 200. I looked in the documentation for this but couldn't find anything to suggest that there's a way to use unsigned bytes for variables. >However, what if the output device is not a screen? but it IS. What else would you use for animation? >What if this were >outputing to a laser printer? Or what if the output were being sent to chained >monitors with some hardware connection such that scan lines greater than 65535 >were possible? If this were a possibility, then I'd change the code, but it most certainly is not and will not be. >Her programming structure makes fewer assumptions about the environment than >yours does and is planned for the future. HA! She doesn't know anything about planning code for the future. We KNOW the environment will be XTs. The program is designed to work on virtually any IBM compatible system, so, the lowest demoninator that suits the purpose is a 4.77Mhz XT with CGA graphics. Knowing that, MY code is better. >You have programmed for today and >screw the maintenance programmer that has to fix it in coming years. Memory is As I've said before. This is a 'dead end' project designed to work on the lowest denominator. >cheap. Speed is cheap. The only exceptions are the Apple II in both cases and >the GS in the second case. It is worth the extra to make allowance for ports >to a Mega-Pixel display which might just be NeXT year's standard. A mega-pixel display will certainly be a standard in the future, but most students at home, who are not 'computer people' will, more than likely, not have that. Our 'assumptions' about the lowest denominator will almost certainly work on old AND new alike. >Eric McGillicuddy > >UUCP: bkj386!pnet91!ericmcg >INET: ericmcg@pnet91.cts.com ---------------------------------------- BITNET-- mquinn@utcvm <------------send files here pro-line-- mquinn@pro-gsplus.cts.com