Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!bionet!agate!ucbvax!microsoft.UUCP!davewh From: davewh@microsoft.UUCP Newsgroups: comp.sys.apple2 Subject: Re: Re- HLLs vs. Assembly Message-ID: <9104191901.AA13371@beaver.cs.washington.edu> Date: 18 Apr 91 14:42:23 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 115 MQUINN@UTCVM.BITNET writes: 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. Doug's right: >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). All of the stuff you just mentioned should NOT be needed for programming a general application. If you do "know" what it is today, what happens next year when they come out with a new model? Look at all the //e stuff that doesn't instantly take advantage of the GS's capabilities. Take a look at all the Mac stuff that does take advantage of the features of new models. I can take a program running on a 2MB Mac with 1-bit video and run it on a 8MB Mac with 24-bit video. The program code is the same. It doesn't need to know that the hardware supports 24-bit video, because Quickdraw handles that. The new features available are used right away. Don't believe me? Decode a GIF on a 24-bit system and cut the image to the clipboard. Paste it into some draw document. Now display that draw document on a 4 bit system. It won't look as good, but it'll still look OK. The draw program isn't doing anything to the bitmap - it just asks Quickdraw to draw it. >For a real example, if you know the paging size of a particular system, Now you're mixing Apples and Unixes. One certainly does NOT need to know any hardware facts about a unix system (namely, color res, I/O space, etc). Knowing page sizes is somewhat helpful, but just knowing the page size may not help if you happen to absolutely need (pagesize+1) bytes. On a Mac, with 32-bit QuickDraw, one simply asks for a color mix before drawing. If that specific color can't be generated on this machine (because it's running with 4-bit video and the color table is full) then QuickDraw will draw with a dither of available colors to give you the illusion of that color. It works quite well. The programmer need not worry. Only in extreme cases will this totally wipe out. In that event, the programmer probably couldn't do anything about it anyway. (BTW- QuickDraw does a superb job at this while X-Windows basically does not. In fact, X is lousy at dealing with colors and color tables correctly. Knowing what's available hardly helps with X.) Remember that a properly designed system has the hardware abstracted away from the applications programmer. When's the last time you accessed the SCSI controller directly to open a file? In fact, programmers who shirk the OS and go to the hardware directly on most machines are asking for serious trouble. For the most part, you can get away with such stunts only on the Apple // and not so much any more on the GS. >If you use dynamically allocated memory for an array instead of declaring >a definite 200k array that may not even be used to 50%. This has nothing to do with knowledge of assembly. This has to do with how to program efficiently. They teach efficient programming in HLL classes too... >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. Very true. But knowing assembly doesn't teach you how the HLL works. Knowing how a compiler works and how computers work is the best approach. See my other post... >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. Depends on the school. Depends on the class. My first CS class was in SCHEME and we centered on how to design a program. Other classes went into how to break down and design large programs (how to divide the work among several people, etc). My compiler class took the mystery of compilers away. My computation structures class took away the mystery of hardware and OS's. Now, I program on a Compaq 486 and have no knowledge of its assembly language. I have no idea how the IBM-compatibale hardware works, and I have little or no desire to learn it. I don't need to know it. I can still program very well because I know how the compiler operates and how the computer and OS function. I have no use for screen resolutions or color tables, even though I'm doing Windows programming. >---------------------------------------- > BITNET-- mquinn@utcvm <------------send files here > pro-line-- mquinn@pro-gsplus.cts.com Dave Whitney Microsoft Corp, Work Group Apps dcw@goldilocks.lcs.mit.edu or I wrote Z-Link and BinSCII - send me bug reports. {...}!uunet!microsoft!davewh I only work here. All opinions herein aren't Bill's, they're mine. "We're samplin' - Yeah we're doin' it. We take good music an' we ruin it." -- "Rap Isn't Music"