Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!usc!apple!agate!ucbvax!ucf1vm.BITNET!news From: news@ucf1vm.BITNET Newsgroups: comp.lang.asm370 Subject: Re: Postholes Message-ID: <9104200542.AA13015@ucbvax.Berkeley.EDU> Date: 20 Apr 91 04:48:47 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: IBM 370 Assembly Programming Discussion List Distribution: inet Organization: The Internet Lines: 94 rickert@mp.cs.niu.edu (Neil Rickert) writes: > 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). I am replying from UNIX, too. What is an example? > 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. You can do this in UNIX, too. But the names exist in the file space in UNIX and MVS keeps them somewhere in the operating system memory. You can make two processes lock any resource with either system. UNIX lets you do it across a network of systems with NFS. I don't know if MVS can do this in loosely coupled systems. > Using lock files can be a big pain when a failure leaves lock files lying >around. The existance of the file is not what constitutes the lock, but rather the exclusive access to the file. I does not matter if the file exists or not. You lock onto it for exclusive access. If you get access to the file, then you have exclusive access to the implied resource. > 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. Sometimes we hear it is good to leave the operating system out of something, and sometimes we hear that it is good to let the operating system control it. Databases don't need to be one single giant file, either. It might be a tad bit easier to copy the whole thing if it were one file, but that is a rare activity. Many database systems are actually controlled by servers or daemons that control the locking of records or whatever other unit of access is needed. Thus with OS independence, you are again free to delve into new concepts and not have to upset the whole system. >>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). That did not exist at the time. Yes, today it would be appropriate. >>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. And apparently some major colleges and universities are guilty of this. > 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. True. And another case might be when you need BOTH the quotient AND the remainder from a division. It depends on how slick the compiler optimization is. >> 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. Yes. And they typically are found at places like "now invert this". -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/