Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!uwm.edu!bionet!agate!ucbvax!MP.CS.NIU.EDU!rickert From: rickert@MP.CS.NIU.EDU (Neil Rickert) Newsgroups: comp.lang.asm370 Subject: Re: Postholes Message-ID: <9104192208.AA01957@ucbvax.Berkeley.EDU> Date: 19 Apr 91 20:57:29 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: IBM 370 Assembly Programming Discussion List Distribution: inet Organization: The Internet Lines: 97 In article <1991Apr19.191345.12504@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) writes: >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 Yes. But the Unix mechanism is much more limited. (Don't get me wrong. I am not trying to bash Unix. I use it a lot, and am replying from a Unix system). >not (outside of the kernel) the sharable resource is a file or device. Thus But that is one of the limitations of Unix. In MVS the shareable resource need not be a file or a device. It is completely generalized. Essentially you share named resources by means of synchronizing access to the name, and the assignment of names to resources is completely outside the operating system. >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). Using lock files can be a big pain when a failure leaves lock files lying around. >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. You never deal with records either in Unix, because they don't exist. Thus a database application which wants to lock at the record level is a big pain since the record being locked is not an entity with any meaning to the system. >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. I agree that it is no coincidence, although I suspect we have rather different views on which is cause and which is effect. >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 Excuse me, but the "obvious" way to do this in PL/I is to use the builtin TRANSLATE function, which would probably be compiled into a TR. (I hope I got the function name right - I haven't use PL/I for a few years, and much prefer C). >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 I am afraid that attitude is alive and well. Just look at all the hacker investigations, and the apparent believe in security by obscurity. I agree with you - we should provide complete information, and design the security of our systems so that providing such information does not cause security problems. >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. One place where you can easily beat it (or probably any compiler) is in fixed point numeric computations. The hardware of most machines gives you access to overflow and carry information which compilers just don't make available. When you have intense computations which require getting 64 bit products of two 32 bit integers, and the compiler only provides 32 bit results, assembler coding will win hands down. > 3. You just can't justify doing this with 1,000 to 100,000 line > Fortran applications anyway. It is pretty dumb to try programming a complete FORTRAN application in assembler anyway. But programming the innermost loops can sometimes be very useful. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940