Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site watdcsu.UUCP Path: utzoo!watmath!watdcsu!herbie From: herbie@watdcsu.UUCP (Herb Chong, Computing Services) Newsgroups: net.unix-wizards,net.lang Subject: Re: smart compilers Message-ID: <789@watdcsu.UUCP> Date: Tue, 25-Dec-84 08:45:03 EST Article-I.D.: watdcsu.789 Posted: Tue Dec 25 08:45:03 1984 Date-Received: Wed, 26-Dec-84 01:51:56 EST References: <6599@brl-tgr.ARPA> <979@opus.UUCP> <6831@watdaisy.UUCP> <1151@ut-ngp.UUCP> Organization: U of Waterloo, Ontario Lines: 29 > Another goody from IBM, this time from the PL/I Programmer's > Guide: > > The use of bit strings in a multiprocessing environment may, > occasionally, lead to incorrect results. Taken out of context, this statement is indeed very silly. You have to read the paragraphs before and after this to understand that the PL/I program can be easily communicating with another process sharing the same address space and possibly written in another language. No matter what the compiler does, the silliness of the other program can wipe out the best code generation. The other thing is that the 370 architecture does not allow bit addressing. If you want to examine or modify a bit, you have to fetch at least 1 byte and store at least one byte. That byte you are interested in may easily contain other bits that are being used by other processes. The PL/I language requires that if you are modifying a bit string shared between two processes (and therefore in the same address space), you must provide your own synchronization although it doesn't really come out and say so in one place. I might also mention (although this is nitpicking) that if you were to refering to the PL/I Checkout or Optimizing compilers, the manual is the PL/I Language Reference where this is explained in detail. Herb Chong... I'm user-friendly -- I don't byte, I nybble....