|
Prev: CVF help -- was: Re: It Hurts When I Do This -- diversion...
Next: Reading unknown number of lines in unknown number of files
From: Terence on 24 Apr 2008 01:46 Ever since I started on Fortran, (II) I always wanted the Logical variable to be an unsigned bit-wise variable upon which I could operate with the 16 theoretical parallel bitwise AND, OR, XOR, NOR etc combinations, (most of which "etc" have uncommon names). It wouldn't affect the more common single truth value purpose. Then there would be no need to use Integer variables for the bitwise logical work I needed, and nobody would confuse arithmetic operation intentions with logical ones. By the time F77 came out and it STILL didn't have bitwise AND, OR and so on, I wrote them in assembler and included them in my compiler's library. Huh!
From: robert.corbett on 24 Apr 2008 01:55 On Apr 23, 12:27 am, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > Actually, I think it will still be a little while before it is > really a problem. For C, pointer variables will have to go to 64 > bits, but it will be much less important for subscript values. > > For four byte integer and eight byte real, you can address > 8GB and 16GB respectively with a signed 32 bit integer. > (Double that if you allow negative values.) > > Most programs need more than one array, so the needed size will > be even smaller. For a square matrix, even 16 bit integers will > be big enough for 4GB. The subscript calculation still has > to be done in more than 32 bits, and compilers should adjust > to that. It has already been a problem for users of Sun Fortran. They have let us know it. Bob Corbett
From: Sebastian Hanigk on 24 Apr 2008 02:54 Terence <tbwright(a)cantv.net> writes: > Ever since I started on Fortran, (II) I always wanted the Logical > variable to be an unsigned bit-wise variable upon which I could > operate with the 16 theoretical parallel bitwise AND, OR, XOR, NOR etc > combinations, (most of which "etc" have uncommon names). > It wouldn't affect the more common single truth value purpose. I find it a bit strange to operate on a - dedicated nonetheless! - Boolean type with bit operators while there are the usual operators from Boolean logic available. Having true LOGICALs (pun not intended) is, apart from arrays of course, for me one of the best selling points of Fortran over the horrendous ugliness of Boolean logic handling in C and C-like languages. > Then there would be no need to use Integer variables for the bitwise > logical work I needed, and nobody would confuse arithmetic operation > intentions with logical ones. I'm a bit confused here, why do you need bitwise logical operations on integers anyway? I've used integers in that way in a half-C, half-Fortran code where one conditio sine qua non was a status bitfield with 10 to 20 flags which was already implemented as 32-bit integer in C. Bitfields can save memory in such a situation, but I suspect it isn't that important for most tasks. Sebastian
From: glen herrmannsfeldt on 24 Apr 2008 03:44 robert.corbett(a)sun.com wrote: (I wrote) >>Actually, I think it will still be a little while before it is >>really a problem. For C, pointer variables will have to go to 64 >>bits, but it will be much less important for subscript values. >>For four byte integer and eight byte real, you can address >>8GB and 16GB respectively with a signed 32 bit integer. >>(Double that if you allow negative values.) >>Most programs need more than one array, so the needed size will >>be even smaller. For a square matrix, even 16 bit integers will >>be big enough for 4GB. The subscript calculation still has >>to be done in more than 32 bits, and compilers should adjust >>to that. > It has already been a problem for users of Sun Fortran. > They have let us know it. Which problem? That the default integer isn't 8 bytes, or that no integer is eight bytes. I claimed that for most programs it wouldn't be a problem, which leaves room for those where it is. My first thought would be that for those either some or all integer variables would change to 64 bits. That does assume that 64 bit integer subscripts are supported. For Java, subscripts are defined to be int, and int is defined to be 32 bits. Presumably a new version of the language can change that, but it does seem like it will change some day. -- glen
From: glen herrmannsfeldt on 24 Apr 2008 03:51
Terence wrote: > Ever since I started on Fortran, (II) I always wanted the Logical > variable to be an unsigned bit-wise variable upon which I could > operate with the 16 theoretical parallel bitwise AND, OR, XOR, NOR etc > combinations, (most of which "etc" have uncommon names). > It wouldn't affect the more common single truth value purpose. PL/I has the BOOL function which will supply any of the 16 bitwise operations between two variables. a=bool(b,c,d); d is between 0 and 15 to select the appropriate operation. (It is converted to a BIT(4) value.) -- glen |