04/18/80 Potentially incompatible code changes generated by the PL/I compiler Since the Multics PL/I compiler was written, it has had a bug which may cause two external procedures to communicate incorrectly via parameters, based variables or external static variables. This is PL/I bug number 1186, known informally as the padded reference bug. This bug involves the conventions that two external procedures use to communicate, and hence cannot be fixed without recompiling every program at every Multics site. Release 26 of the Multics PL/I compiler implements the first phase of fixing this bug. The second phase will be completed in about two years. Users will have to recompile every program with release 26 or later before the second phase is installed. Some programs with invalid PL/I that worked with release 25 or earlier will fail when compiled with release 26 or later. There shouldn't be too many programs that fail. Programs that misdeclare an entry will fail if there is a mismatch in the alignment attribute for short bit string or short character string parameters or return values. Short means two words or less. The rest of this info seg describes what the padded reference bug is, and exactly what code sequences are changing. Padded references: Some short bit strings or short character strings are padded. Short means two words or less, i.e. for character strings, 8 characters or less, and for bit strings, 72 bits or less. Some short character strings or bit strings have unused bits in a word. For example: dcl v bit (1) aligned; dcl w bit (1); One word of storage will be used for v. The first bit will be the value of v and the remaining bits will be zero. 0 1 35 -------------------------- | v | pad - must be zero | -------------------------- The variable w, since it is unaligned, only needs one bit for its value. 0 ----- | w | ----- The compiler will try to pad w, as in v, if it is not a member of a structure, if it is automatic and if it the variable is only referred to by one name (This checking is not done correctly). Variables may be padded even if they are declared unaligned. The bit string b in the following structure won't be padded since there is another variable declared to use the remaining part of the word. dcl 1 s unaligned, 2 b bit (2), 2 c bit (34); The compiler could generate better code if it used the unused bits in the word. That way it could use word oriented instructions directly, such as lda or ldaq, instead of masking the unused bits. Often, such as with unaligned parameters, exactly which bits are unused is not known until runtime. A reference to a short string is called a "padded reference" if the unused bits in the word are used. When a padded reference is stored, the pad bits are zeroed. When a padded reference is fetched, the unused bits are assumed to be zero. In order for this to work, references to a short string must either be all padded or all unpadded. This is easy to determine if the reference is only used within one external procedure. If the reference is used by more than one external procedure, for example, if it is passed as an argument by reference, then the compiler must ensure that all references in any external procedure are either all padded or all unpadded. The padded reference bug: Sometimes the compiler pads some references to a variable, and inconsistently at other times, uses unpadded references to the variable. For example: dcl c char (5); dcl cb char (5) based (addr (c)); References to c are padded while references to cb are not. The program will fail if c is always set by refering to cb, and always read by refering to c. If a string can be padded and is passed as an argument in a program, then set references to that string are not padded. However, if the called program does not pass the string as an argument, the called program's references are padded. Communication will fail if the calling program sets the string and the called program reads the string. The calling program won't pad the string, but the called program will assume the string was padded when it was set. Release 26 code changes: The padded reference bug will be fixed in two phases. The first phase is done in release 26. All set references that should be padded will be padded. More set references will be padded in release 26 than in previous releases. The second phase is to correctly pad read references. This phase will be done in about two years. Since the effect of the first phase is to pad more references, it is a compatible change. The second phase will assume that references are padded according to the release 26 conventions. All programs should be recompiled with the release 26 compiler, or a later compiler, before the compiler implementing the second phase is installed. Note that most symptoms of the padded reference bug will disappear once programs are recompiled with the release 26 compiler. One of the contexts in which release 26 will pad references is short, aligned, string parameters or return values. For example, a program calls the following procedure: called_proc: procedure (short_cs, short_bs); dcl short_cs char (2) aligned; dcl short_bs bit (5) aligned; short_cs = "ab"; short_bs = ""b; end called_proc; The release 25 compiler generates the following code: short_cs = "ab"; lda 49762,du epp7 pr6|26,* epp5 pr7|2,* short_cs stba pr5|0,60 short_cs short_bs = ""b; lda 3,ic 000022 = 017777777777 ansa pr7|4,* short_bs Note that the unused bits are not padded. The release 26 compiler pads these references. It generates: short_cs = "ab"; lda 49762,du epp7 pr6|26,* sta pr7|2,* short_cs short_bs = ""b; stz pr7|4,* short_bs The compiler can pad these references since the strings are aligned. This is a compatible change for valid PL/I programs. However, certain invalid PL/I programs will fail. For example: calling_proc: procedure; dcl called_proc entry (char (2), bit (5)); /* Invalid */ dcl 1 s, 2 cs char (2), 2 x char (2) init ("cd"); dcl 1 t, 2 bs bit (5), 2 y bit (31) init ((31)"1"b); call called_proc (s.cs, t.bs); ... end calling_proc; Note that calling_proc has misdeclared called_proc to have unaligned short string parameters instead of aligned short string parameters. The values of s.x and t.y won't change if called_proc is compiled with release 25. However, once called_proc is compiled with release 26, the values of s.x and t.y will be obliterated. The affected programs misdeclare an entry so there is a mismatch in the alignment attribute for short bit string or short character string parameters or return values. This change should not affect too many programs. ----------------------------------------------------------- Historical Background This edition of the Multics software materials and documentation is provided and donated to Massachusetts Institute of Technology by Group BULL including BULL HN Information Systems Inc. as a contribution to computer science knowledge. This donation is made also to give evidence of the common contributions of Massachusetts Institute of Technology, Bell Laboratories, General Electric, Honeywell Information Systems Inc., Honeywell BULL Inc., Groupe BULL and BULL HN Information Systems Inc. to the development of this operating system. Multics development was initiated by Massachusetts Institute of Technology Project MAC (1963-1970), renamed the MIT Laboratory for Computer Science and Artificial Intelligence in the mid 1970s, under the leadership of Professor Fernando Jose Corbato. Users consider that Multics provided the best software architecture for managing computer hardware properly and for executing programs. Many subsequent operating systems incorporated Multics principles. Multics was distributed in 1975 to 2000 by Group Bull in Europe , and in the U.S. by Bull HN Information Systems Inc., as successor in interest by change in name only to Honeywell Bull Inc. and Honeywell Information Systems Inc. . ----------------------------------------------------------- Permission to use, copy, modify, and distribute these programs and their documentation for any purpose and without fee is hereby granted,provided that the below copyright notice and historical background appear in all copies and that both the copyright notice and historical background and this permission notice appear in supporting documentation, and that the names of MIT, HIS, BULL or BULL HN not be used in advertising or publicity pertaining to distribution of the programs without specific prior written permission. Copyright 1972 by Massachusetts Institute of Technology and Honeywell Information Systems Inc. Copyright 2006 by BULL HN Information Systems Inc. Copyright 2006 by Bull SAS All Rights Reserved