Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!bionet!agate!ucbvax!UX1.CSO.UIUC.EDU!phil From: phil@UX1.CSO.UIUC.EDU (Phil Howard KA9WGN) Newsgroups: comp.lang.asm370 Subject: Re: Postholes Message-ID: <9104192055.AA29420@ucbvax.Berkeley.EDU> Date: 19 Apr 91 19:13:45 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: IBM 370 Assembly Programming Discussion List Distribution: inet Organization: The Internet Lines: 103 rickert@mp.cs.niu.edu (Neil Rickert) writes: >In article <9104190111.AA00321@ucbvax.Berkeley.EDU> writes: >>I notice that very very little assembler language programming is done on >>UNIX systems. In part this is due to the fact that UNIX makes it easy to >>do system level functions in C and other languages. But there is also the > And in part this is due to the fact that the system features you would use >assembler programming on in say MVS do not even exist in Unix. (I think >for example of the ENQ/DEQ functions for interprocess synchronization, or >the ability to create channel programs for a device not yet supported by >the operating system). UNIX does have syncronization facilities. But these facilities are different in ways that reflect the nature of what UNIX is. For instance if you want to make sure that you don't end up with TWO processes concurrently trying to work on some sharable resource, you need to syncronize the processes in some way. UNIX does in fact need to do this, and has a means to do so. More often than not (outside of the kernel) the sharable resource is a file or device. Thus it makes sense to have a mechanism to lock files (devices are accessed via the file space in UNIX) directly. But if you need to share something else besides a file, it's no big deal to make up a null file and lock on it anyway and this is readily done in C (though not so readily in shell scripts I have found out). Channel programming is needed more than it should be needed. IBM has always taken an approach to passing much of the detail of device control to the application in its operating systems. Applications have to typically at least deal with things like the block size (and you have OPEN exits in MVS and CMS to let you do it in assembler). UNIX takes the opposite approach. You never (very rarely anyway) need to deal with a disk blocksize just to do I/O to a file. You need to when dealing with tape because of the nature of the data, but even then you can get away without dealing with it when sharing data with another UNIX application that has done so. My point is that assembler is easier on some systems, and it is NEEDED on some systems, and it is NO coincindence that these happen to be the SAME systems. > When it comes to optimization, things are not always what they seem. I >remember a few years writing the same program in Assembler, PL/I, and >FORTRAN. I looked at the generated code for each compiler. Like all >compiler generated code it looked pretty cruddy. But in the innermost >loop my hand optimized assembler code had only one less instruction than >the FORTRAN code (at that time using the H-extended compiler with maximum >optimization). The PL/I code had more than twice as many instructions in >the innermost loop. For many things I have found this to be the case as well. I've learned to recognize when it does me no good to use assembler instead of Fortran. Still in other cases it makes a big difference. Since we are bashing PL/1 I might mention a program a friend of mine wrote. He wanted to take each byte in a file and reverse the order of the bits. He did this the "obvious" way in PL/1 by defining a bit structure and taking each bit out one by one and putting them back in another one in reverse order. He discovered that his program ran "horribly" slow. It processed a file of 1000 80-byte records in about 75 seconds of CPU time on a 370/158. I wrote the same thing in aseembler. Not knowing the linkage to PL/1 at the time (due to lack of documentation for students, which is another issue) I wrote the whole thing in assembler using TR. It took less than 1 second. Doubling the size of the file didn't even seen to affect the time, so I suspect it was running under the "noise". BTW, looking back at my days as a student, I realize that in those cases where there was a lack of documentation, I ended up working around the problem by doing things in ways that would not make sense in a professional environment. It took a while to UNLEARN all the wrong things I learned in school just because someone in the computer center was paranoid about me "learning too much" about the system and keeping back documentation. I would really like to stamp out that attitude. There are times when assembler is appropriate and there are times when it is not. Students should be allowed to learn what these are. > I also remember a few years ago talking to someone at a highly Unix oriented >company which happened to also run a large IBM/MVS shop. I thought this >was strange, so I questionned it. The reply was that FORTRAN was used in >their chip design software, and no Unix FORTRAN compiler came close to >matching the optimization provided by the IBM compiler. The Fortran compiler is the toughest one to beat. It *IS* beatable by good assembler programmers, but the benefits of trying to do so are reduced now because: 1. The margin is getting narrower with better compilers. 2. Processors are caching better making the difference between good code and bad code smaller. 3. You just can't justify doing this with 1,000 to 100,000 line Fortran applications anyway. So you probably want to stick with optimizing the bottlenecks ONLY, once you determine where they are. More often a good choice of mathematical algorithm can improve things more than rewriting in assembler, depending on the scale of the problem and the machine. For instance there is a way to do a 2x2 matrix multiply with only 7 instead of 8 multiply instructions, at the cost of doing a few (5 I think) extra additions. You can recursively extend this to larger matrices with eventually a tremendous speedup. But this is only going to do you any good when a multiply costs more than an add. Some chips are now doing BOTH in one cycle. -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/