Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!ucsd!ucbvax!UTCVM.BITNET!MQUINN From: MQUINN@UTCVM.BITNET Newsgroups: comp.sys.apple2 Subject: Re: Re- HLLs vs. Assembly Message-ID: <9104110129.AA11471@apple.com> Date: 11 Apr 91 00:38:18 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 90 On Wed, 10 Apr 91 05:04:41 GMT Doug Gwyn said: >In article <1991Apr9.150402.563@latcs2.lat.oz.au> stephens@latcs2.lat.oz.au > (Philip J Stephens) writes: >>You can't program effectively in a HLL if you don't know the hardware >>you're working on, it's limitations and it's features. > >Wrong -- any decent HLL should be exploited in terms of the abstract >model of computation that it supports, most definitely not in terms >of any specific machine architecture. If data structures and such were the only things related to computer programing, then HLLs would be perfect. There's more to programming than STacks, Queues, binary trees, etc. If you don't know the maximum amount of RAM, Minimum amount of RAM, Graphics resolutions, colors, bits per pixel, CPU speed, sound capabilities, port I/O addresses, hardware buffer sizes, hardware stacks, maximum I/O rate of ports, timing delays needed, reserved RAM space, ROM addresses, ROM entry point routines, the concept of hardware address (needed for pointer variables in HLLs), then you are missing out on ALOT and therefore, not taking advantage of that knowledge and applying it to your HLL code to make it more compatible with the the hardware works (and I don't mean any specific hardware). For a real example, if you know the paging size of a particular system, you can set up arrays to take advantage of this size. Let's assume a page size is, say... 1k just as an example. You'd know that if you needed an array, somewhere around that size, then it would be better to have it just that size or a little smaller, because ONE byte larger, and another page has to be allocated, wasting 1023 bytes of RAM and forcing one less page to be accessed by other users (or yourself). I don't know much about paging, so let me give a better example. One that might be more valid: If you use dynamically allocated memory for an array instead of declaring a definite 200k array that may not even be used to 50%. Understanding how variables use RAM, you'd know that you might be able to save 100k. There are just so many things like this (and better examples than this) that will make you a more effective programmer by knowing Assembly, even if you never plan on writing a single application in assembly, just knowing it will improve your programing in ALL languages. Knowing Assembly also gives you an appreciation for what High level languages do and WHY they are the way they are and also gives you ideas on exactly how the languages could be improved. The list of advantages just goes on and on and on. It's sort of like experiencing another culture in another, less advanced country than your own: It gives you an appreciation for your own county and helps you understand how we are and why we are the way we are. Learning a HLL without learning assembly is very similar to the way they used to teach math in my old high school: Athletic *COACHES*, who didn't have the foggiest idea of math, were teaching the classes. When someone asked a question on why a certain formula worked, the coach would just say, don't worry about how it works, just memorize the formula. Well, Just memorizing the formula will just get you so far. UNDERSTANDING the formula is a whole different story. It helps you REMEMBER the formula, and if you ever happen to forget the formula, if you understand how it works, you could always re-think out the formula. Many of the computer science professors around now are much like the coaches I had for math in High schooll. They don't completely understand it themselves and they're churning out more and more people like themselves and the real 'thinkers' are slowly vanishing. This is part of the overall education problem in the U.S. today. To many teachers just want you to memorize the facts and forget about trying to understand them. So, I guess the moral of my story is, "You're much better off knowing what's under the hood and how it works, in case you get stalled out in the middle of nowhere." :) >There are a few situations in which certain basic information about >the system can help, for example in a Fortran program that accesses >a huge multidimensional array; if it accesses it in the wrong order, >performance might be poor due to virtual memory "thrashing". But >knowing what machine opcodes and addressing modes exist is of no real >value to a Fortran programmer. For this ONE particular example, knowing OPcodes isn't really necessary, but knowing how memory is reserved for arrays certainly helps. See my above example. I'm sure you could pick out MANY instances where it's not necessary to know assembly, but MANY instances, it is either almost a necesity, or it's extremely helpful to know assembly. There ARE quirks about machines that you just can't work around without knowing assembly. Sure, you're code will more than likely work without knowing assembly, but the more assembly you know, the better your code is going to be. ---------------------------------------- BITNET-- mquinn@utcvm <------------send files here pro-line-- mquinn@pro-gsplus.cts.com