|Re: failure due to compiler? firstname.lastname@example.org (1996-07-04)|
|failure due to compiler? email@example.com (1996-07-09)|
|Re: failure due to compiler? firstname.lastname@example.org (1996-07-10)|
|Randomized compilation order (was: failure due to compiler?) email@example.com (1996-07-13)|
|Re: Randomized compilation order (was: failure due to compiler?) firstname.lastname@example.org (Darius Blasband) (1996-07-24)|
|Re: Randomized compilation order (was: failure due to compiler?) email@example.com (Matthew B Grice) (1996-07-26)|
|Re: Randomized compilation order (was: failure due to compiler?) firstname.lastname@example.org (1996-07-31)|
|From:||email@example.com (Steve Masticola)|
|Date:||13 Jul 1996 22:06:32 -0400|
|Organization:||Siemens Corporate Research, Princeton (Plainsboro), NJ|
|References:||96-07-041 96-07-056 96-07-070|
firstname.lastname@example.org (Cliff Click) writes:
>email@example.com (Peter L Flake) writes:
[ Code for procedures emitted in randomized order in old Multics BCPL
compiler. - Steve. ]
>> [Anyone got any insight into why in the world they made a non-deterministic
>> compiler? -John]
>A universal hash function? Guaranteed performance, even in the face of
>pathological inputs, because the hash function changes every time and any
>given instance of the hash function has a very small chance of being
>pathologically bad? Just my guess...
It might also have been an attempt to reduce disk latency problems
when paging instructions in. If the caller was always right next to
the callee, the disk would have to travel a full rotation on any call
that produced a page fault.
If so, they could have done it far better by cruising the call graph a
- Steve (firstname.lastname@example.org).
Return to the
Search the comp.compilers archives again.