> Date: Wed, 30 Mar 2005 09:46:43 -0500
> From: David LaFrance-Linden <[log in to unmask]>
> Date: Wed, 30 Mar 2005 12:45:39 +1000
> From: robin <[log in to unmask]>
>
> The discussion about logical representations may be summarised
> as follows.
>
> I beg to differ. This is not a summary, it is your opinions.
>
> 3. The negative 1/0 model is the least satisfactory of the three:
>
> (a) it may not be appropriate on a machine employing ones
> complement ALU.
>
> If it doesn't work, don't use it. I'm not trying to say ~0 (you
> insist on calling it -1) / 0 is best; I'm saying it is as reasonable
> as any other.
But that's the point, it isn't.
In point of fact:-
It isn't a value that's produced by hardware compare units.
Nor is it a value that that's easily [compared to the others] generated.
It isn't straightforwardly converted to a numeric value.
It requires that a whole word be stored when the
recipient is a LOGICAL variable (because all the bits
have to be set.)
(Compare that with 0/1, where only *one* but has to be set.)
> Hardware features may or may not dictate whether it
> gets used. And I suspect it works just fine on a ones-complement
> machine.
I take it that you havent met one that actually generates
NOT(0) for zero?
> (b) It requires an entire word to be stored.
>
> Says who?
In Fortran [because that's what we're talking about] --
it does. (You attempt to make use of this fact
below, where you attempt to equivalence an integer and a logical.)
> In C, I can store ~0 in a (signed or unsigned char, short,
> int, long, and long long, all of which have potentially different
> sizes. "All I'm doing" is flooding the storage (of whatever size)
> with the same bits, either all 1s or all 0s.
(And in PL/I, a single bit of storage is required.)
But we're talking about Fortran, not C.
> (c) It may inhibit optimization.
>
> Unsubstantiated claim.
Any arithmetic operation that uses
registers to carry out arithmetic renders the
earlier contents unusable.
Let's say that using one register is OK, and that using
two or more registers affects optimization.
Had any given register not been used for the purpose
of arithmetic, the earlier content would still be available for
a subsequent computation. Should that earlier value be required,
it will have to be re-loaded from memory.
Hence, the degree of optimisation is less than it would otherwise
have been.
> (d) Conversion to/from INTEGER not straightforward.
>
> You continue to claim this after it has been counter-demonstrated.
It hasn't been counter-demonstrated.
Unless the values are 0/1, conversion requires more steps.
No steps are required if the value is already in the form 1/0.
The value can be used "as is where is".
> The easiest way in fortran to convert them is to EQUIVALENCE a logical
> with an integer. In one case, the compiler will interpret the storage
> (I dare say "bits" because that sends you off into tangents) as a
> logical, and in the other case as an integer.
This would be feasible provided that the internal form were
some guaranteed value. At the moment it's not guaranteed,
because it's not defined.
(But having said that, EQUIVALENCE is somewhat dated.)
> (e) Requires extra time and instructrion space to generate.
>
> Again, you keep claiming this against the evidence.
None has been provided.
> Yes, on Alpha it
> requires an extra instruction to convert the hardware-generaged 1/0 to
> -1/0.
Why would you do that? It's already in suitable form.
> On IA64 the compare sets a predicate bit and you have to
> generate either value under predication, so the penalty for this
> scheme is no different than any other. In case you haven't been
> aware, compilers are pretty good these days about scheduling
> instructions.
On other systems, that's not the case. The PC is an example.
