🚀 go-pugleaf

In article <1k1dcdINNpm3@rs2.hrz.th-darmstadt.de>, kroeker@oc1.oc.chemie.th-darmstadt.de (Martin Kroeker) writes:
|> Many thanks to all who responded to my query about coding non-standard
|> bit manipulation functions in fortran, especially to Eric Haug, who provided
|> the simple (ouch !) solution in C:
|> long btest (long *a, long *b)
|>            return(*a>>*b);

This is clearly an incorrect solution.  Suppose the first argument is
eight and the second is one, this version of btest returns four - which
is *not* the value of the bit addressed by the second argument in either
big- or little-endian bit numbering.  In little-endian, the following
operation would be correct:

  long btest (long *a, long *b)
             return(*a>>*b & 1);

|> After my plea for help I had finally found a clumsy solution in fortran, but
|> this one naturally beats it easily.

I've never run across a Fortran implementation which did not have 
these as operations as either intrinsic functions or operators which 
are inlined and which use the hardware instructions (if the hardware 
has them) to perform these operations.  A glance at the document for 
your particular Fortran implementation would probably have revealed a 
non-clumsy Fortran solution.  Certainly it's less clumsy to use a
implementation defined extension to Fortran than to rely on C (the
interface to which is also implementation defined and not portable).

-- 
J. Giles

In article <1993Jan26.190831.8026@newshost.lanl.gov>, jlg@cochiti.lanl.gov (J. Giles) writes:
> I've never run across a Fortran implementation which did not have 
> these as operations as either intrinsic functions or operators which 
> are inlined and which use the hardware instructions (if the hardware 
> has them) to perform these operations.  A glance at the document for 
> your particular Fortran implementation would probably have revealed a 
> non-clumsy Fortran solution.  Certainly it's less clumsy to use a
> implementation defined extension to Fortran than to rely on C (the
> interface to which is also implementation defined and not portable).
 The original post mentioned that the compiler, if you can call it that, was
f2c, which is a translator. The version of f2c which I have used does not
recognize IAND,IOR, etc., as intrinsic functions and generates a function
call.
 This turns out to be a mildly interesting problem if the Fortran program
uses the aforementioned LOGICAL functions as generic, i.e., calling it with
different data types within the same program. This creates a problem for
the translator since it doesn't know how to prototype the function. My
version of f2c (it's old, I don't know if there's anything newer) issues a
warning in this case.
 The correct answer to the original question is, indeed, to write C code to
implement the functions. I might be tempted to replace (inline) the function
calls in the f2c output (C source) with the appropriate C code due to the
problem I mentioned above. In any case, one must use code that is correct.

David Robinow		DROBINOW@falcon.aamrl.wpafb.af.mil
Logicon Technical Services, Inc.
P.O. Box 317258
Dayton, Ohio 45431-7258		  (speaking for myself)