(j3.2006) BEQ, BNE?

Bill Long longb
Wed Jan 30 14:55:32 EST 2013


I did, in fact, work on a Unisaurus 1108 and 1110 in school.  Which is 
why I added "relevant" since I doubt anyone will be writing an f2008 
compiler for this system.

Cheers,
Bill


On 1/30/13 1:51 PM, Toon Moene wrote:
> On 01/30/2013 02:33 PM, Bill Long wrote:
>
>> I assume this is a theoretical question since I don't know of any
>> relevant hardware implementation that distinguishes between +0 and -0
>> for integers.  If such hardware ever appears on the horizon, we  could
>> add in BEQ and BNE.  If I recall, the goal was to add the actually
>> useful cases while trying to limit the ever-expanding list of intrinsics.
>
> I get it you never worked on Univac 1100 systems ?  1111...1111 and
> 0000....0000 both being treated as zero (especially if only *some* of
> the instructions do that) leads to .... hmmm, interesting problems.
>
> The following might serve as an example.
>
> Some thirty years ago I *did* do support for Fortran and Fortran related
> applications (DISSPLA, SPSS) on Univac 1100 systems at the Dutch Postal
> Services (then the largest employer in the Netherlands, with 100,000
> employees).
>
> In the bug report system of the vendor the following appeared
> (paraphrased):
>
> "I have a large subroutine, and upon (optimized) compilation, only a
> tiny object file remains, which doesn't do anything useful."
>
> Analysis:
>
> "The Fortran compiler, upon optimizing your routine, first made a list
> of all basic blocks, and then determined which of them were unreachable,
> giving them a 0 bit in an bit-array of double (72-bit) words.
> Unfortunately, on checking whether basic blocks were reachable, the
> compiler, as an optimization, checked a full double word for 0 to deal
> with 72 blocks at once."
>
> Of course, at that time (late 70s, early 80s) the hype of the day in
> systems programming was to use a high-level (Pascal-like) language to
> write programs like compilers in.  It was the compiler for *that*
> language that made the mistake of optimizing a bit-array check for zero
> as a series of jump-on-double-word-equal-zero instructions, which
> happened to be just as satisfied with a double-word filled with 72 one
> bits for zero.
>

-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101





More information about the J3 mailing list