minow@decvax.UUCP (Martin Minow) (01/08/85)
Ken Yap mentioned that the VMS Fortran compiler puts constants in read-only memory so the operating system could trap subroutines that incorrectly write to their parameters. He asked if other compilers did the same. Some very old Fortran compilers initialized all variables to an "illegal" floating point constant (I think -0 was used on the 7090) to trap the fairly common error where a variable was read before it was initialized. The PDP-11 floating-point format has an "illegal float" defined for just that purpose, but I don't think it's used by any '11 language. Martin Minow decvax!minow
emigh@ecsvax.UUCP (Ted Emigh) (01/09/85)
The current WATFIV compiler for the IBM 360 compatible computers
still initializes all variables to an invalid floating point constant
(creates bad memory parity if *MY* memory serves me right). Nice
feature for debugging FORTRAN programs.
--
Ted H. Emigh Genetics and Statistics, North Carolina State U, Raleigh NC
USENET: {akgua decvax duke ihnp4 unc}!mcnc!ecsvax!emigh
ARPA: decvax!mcnc!ecsvax!emigh@BERKELEYtom@hcrvx1.UUCP (Tom Kelly) (01/09/85)
Some compilers on the Burroughs B7xxx/B6xxx also use hardware features
to detect various run-time errors.
I worked on a Pascal compiler that started all scalar values off
with a special value (a TAG 6 for you Burroughs hackers) that could
not be referenced for a value, only stored into. This caught references
to uninitialized variables. It didn't do it for arrays, just scalars.
Another Pascal compiler (from U. of Tasmania) put a TAG 6 into the
index variable of a for loop, because its value is undefined at loop
termination.
The Fortran 77 compiler uses call by value/result for parameter passing.
A constant parameter is passed by value. An attempt to modify it
won't be detected (I think), but will not affect the caller.
If my memory serves me correctly, we thought about trying to detect
this, and decided it was not worth the trouble, although it would
be possible.
Also, the Fortran 77 compiler uses a hardware recognised "thunk" (a PCW),
to detect misuse of parameters in subroutines with multiple ENTRYs.
If you reference a parameter that is invalid because it is not defined
as part of the ENTRY through which you enter the subroutine, the
program is aborted with an appropriate error message.
The TAG 6 word is also used in the implementaton of the ASSIGNED GOTO
statement. The hardware detects an attempt to do arithmetic on
a variable that as had a label value ASSIGNED to it (as in ASSIGN 10 TO I).
Similarly, an attempt to do an ASSIGNED GOTO to a variable that contains
an integer instead of a label is also detected.
Tom Kelly (416) 922-1937
{utzoo, ihnp4, decvax}!hcr!hcrvx1!tomhugh@hcrvx1.UUCP (Hugh Redelmeier) (01/10/85)
Watfor for the IBM7040 initialized variables to a bad parity word using an undocumented (I am given to understand) machine instruction. This caught one of the more common errors: use of uninitialized variables. However, if the memory got a real parity error ...
herbie@watdcsu.UUCP (Herb Chong [DCS]) (01/12/85)
In article <481@ecsvax.UUCP> emigh@ecsvax.UUCP (Ted Emigh) writes: > >The current WATFIV compiler for the IBM 360 compatible computers >still initializes all variables to an invalid floating point constant >(creates bad memory parity if *MY* memory serves me right). Nice >feature for debugging FORTRAN programs. >-- > >Ted H. Emigh Genetics and Statistics, North Carolina State U, Raleigh NC >USENET: {akgua decvax duke ihnp4 unc}!mcnc!ecsvax!emigh >ARPA: decvax!mcnc!ecsvax!emigh@BERKELEY Quoted from the latest WATFIV-S manual (for version 1980 V2L1): "When a WATFIV program is compiled, any variable which is not assigned an initial value has a bit pattern of '10000000' put in each byte of memory reserved for the value of that variable. ... The pattern represents an INTEGER value of -2139062144 and a REAL value of -0.4335017E-77." What you say may have been true for WATFOR on older IBM machines, but for the 360/370 series of machines, this definition has stood for as long as WATFIV has been in existence. Herb Chong, BASc Computer Consultant I'm user-friendly -- I don't byte, I nybble.... UUCP: {decvax|utzoo|ihnp4|allegra|clyde}!watmath!water!watdcsu!herbie CSNET: herbie%watdcsu@waterloo.csnet ARPA: herbie%watdcsu%waterloo.csnet@csnet-relay.arpa NETNORTH, BITNET: herbie@watdcs, herbie@watdcsu POST: Department of Computing Services University of Waterloo N2L 3G1 (519)885-1211 x3524
ndiamond@watdaisy.UUCP (Norman Diamond) (01/13/85)
> The current WATFIV compiler for the IBM 360 compatible computers > still initializes all variables to an invalid floating point constant > (creates bad memory parity if *MY* memory serves me right). Nice > feature for debugging FORTRAN programs. > Ted H. Emigh Genetics and Statistics, North Carolina State U, Raleigh NC Nope; Watfiv generates CODE to check whether a variable contains the magic value (hex 80 in every byte, the semantic "value" depending on the datatype). A compiler option can be used to turn off generation of error-checking code, for that error only. This option is rarely used. The inverse option (to perform such checking) is rarely available in real-world compilers. It is unfortunate that a lot of people still think that it would be more expensive to use such checks in the debugging stages of programs than it is to pay programmers to find the same bugs. The Diagnose machine instruction (the real one) might generate bad parity among its tests, but a problem program like Watfiv would not be able to take advantage of it. -- Norman Diamond UUCP: {decvax|utzoo|ihnp4|allegra|clyde}!watmath!watdaisy!ndiamond CSNET: ndiamond%watdaisy@waterloo.csnet ARPA: ndiamond%watdaisy%waterloo.csnet@csnet-relay.arpa "Opinions are those of the keyboard, and do not reflect on me or higher-ups."
herbie@watdcsu.UUCP (Herb Chong [DCS]) (01/14/85)
In article <6854@watdaisy.UUCP> ndiamond@watdaisy.UUCP (Norman Diamond) writes: >The Diagnose machine instruction (the real one) might generate bad parity >among its tests, but a problem program like Watfiv would not be able to take >advantage of it. > >-- Norman Diamond the in a VM environment, a DIAGNOSE instruction is also known as a hypervisor call (as opposed to a supervisor call). it traps to the real operating system as opposed to the virtual one. the DIAGNOSE instruction issued by the CP component of of VM can do these things, but in a VM, it will always go to the operating system and not the hardware. incidentally, the DIAGNOSE instruction is a machine instruction that is defined to be model dependent. it is supposed to call up microcode for debugging the hardware and things like that. Herb Chong... I'm user-friendly -- I don't byte, I nybble.... UUCP: {decvax|utzoo|ihnp4|allegra|clyde}!watmath!water!watdcsu!herbie CSNET: herbie%watdcsu@waterloo.csnet ARPA: herbie%watdcsu%waterloo.csnet@csnet-relay.arpa NETNORTH, BITNET: herbie@watdcs, herbie@watdcsu
rcd@opus.UUCP (Dick Dunn) (01/17/85)
> Some very old Fortran compilers initialized all variables to > an "illegal" floating point constant (I think -0 was used on > the 7090) to trap the fairly common error where a variable > was read before it was initialized. The PDP-11 floating-point > format has an "illegal float" defined for just that purpose, > but I don't think it's used by any '11 language. The CDC 6x00,Cyber machines had (oops, have) an illegal form; the value is something which would be called "negative indefinite" (where "indefinite" is what you get from 0.0/0.0). It produces an exception (arithmetic error mode 4 to the cognoscenti) when used, and it will be identifiable because it's something that the floating-point unit won't generate. The value is determined by the high-order (exponent) bits so that you can play around with the lower bits. The exponent has the effect of a no-op if executed, but there's enough room in the rest of the word to tuck away an instruction which will bomb out and even get the address of the word in the bottom (so that if it gets picked up and moved about, you'll still know where it came from). We modified a CDC loader to initialize memory to this sort of pattern. After some intense complaints from a few disgruntled (and unfortunately influential) users, the initialization to bogus value was made an option so that these folks could still get initialization to 0 and keep running their programs with uninitialized-variable bugs. -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...A friend of the devil is a friend of mine.