Quite a few compilers support different representations for LOGICAL
types: 1 byte, 2 byte 4 byte...and 8 byte?

What applications are there for 8 byte LOGICAL types? (Or for 2 byte
types?)

I understand that the default size is often 4 bytes for likely
performance reasons (register loads and stores, address alignment).

Smaller sizes are useful for packing data, but if space is an issue,
why pack logicals into two bytes and not one?

Just curious...

Andrej

Even 128-bit.

Storage association rules require than a default INTEGER takes up
the same space as a default LOGICAL. N1601.pdf, section 16.4.3.1:

"In a storage association context
(1) A nonpointer scalar object of type default integer, default
real, or default logical occupies a single numeric storage unit;"

On Apr 22, 9:15 pm, "James Van Buskirk" comcast.net> wrote:

e p chandler juno.com> wrote:

Yes, though that would be a slightly odd choice for reals, which can
often use the extra precision. Still, it is definitely legal. Comparable
things have been done with various compilers in the past. I don't recall
that exact one, but I have seen:

Integers that take 4 bytes of storage, but only use 2 of them.

Double precision reals that take 128 bytes of storage, but only use 80
of them.

Considering the subject of the thread, logicals that take any of several
sizes, but only use one bit.

And a few other such variants, which have been mentioned here in the
past.

e p chandler wrote:
(snip)

My guess is that they will cheat.

In the 16 bit days, (such as the PDP-11 and DG Eclipse) they
stored default integers in 16 bit words by default. The DEC
compilers I know had the option of storing in 32 bits, but
I believe still only used 16.

Even with cheap memory, I find it unlikely that the default will
be eight byte integer and real, with 16 byte double precision.
(Until good hardware support for 16 byte reals.)

-- glen

On Apr 22, 10:50 pm, glen herrmannsfeldt ugcs.caltech.edu>
wrote:

Even when there is hardware support for 128-bit floating-point,
the default type sizes are unlikely to double. The biggest
bottleneck in many high-performance applications is memory
bandwidth, not the speed of floating-point operations. As long
as buyers of high-performance machines care about high-performance,
compiler vendors are unlikely to make programs take twice as long.

Programmers are going to have to get used to using INTEGER*8
variables to hold subscript values.

Bob Corbett

robert.corbett@sun.com 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.

As if by magic, glen herrmannsfeldt appeared !

Well I'm coming across codes that are hitting it, though I can't
claim that it is very common ( or elegant ! )

The situation is packed symmetric matrices, and in particular
runs on parallel machines where, for reasons I don't want to
go in to, they are either replicated or stored in a shared
memory segment. Actualy the parallel is not a requirement, it's
just to perform these runs one processor does not give enough ooomph,

Ian

On Apr 23, 2:15 am, "James Van Buskirk" comcast.net> wrote:

This looks to me like a hole in the language. Is there a
SELECTED_LOGICAL_KIND that would allow me to specify (portably) the
smallest available logical type, for instances where I do not want to
burn up 128 bits to store T/F values in a large array?