Mike Sobers <sob### [at] mindspringcom> wrote:
> Well, I don't know.  I'm not an OS programming expert.

  It's not a question of OS. It's a question of processor architecture.

>  Maybe it's not
> possible, but in any case it's probably unlikely that an OS would be
> designed to operate this way,

  In which way?

  A 64-bit processor has 64-bit registers. That's about it. All the
opcodes are still the same (well, mostly).

  I don't know what you think a 64-bit processor is, but it's basically
the exact same thing as a 32-bit processor with the only difference that
registers are 64-bit long instead of 32-bit.

  What does it mean that they are twice as long? It means that you can
make integer calculations with twice as many bits and also that you can
directly access a whole lot more of memory. How this could speed up
anything is beyond me.

> since dual 32-bit processors would be more
> efficient I would think.

  More efficient than what?

>  Mathematically, you could use the upper 32 bits
> of a 64-bit memory allocation simultaneously with the lower 32-bits by
> shifting the information in the registry upward.  That way one 64-bit
> operation could accomplish two 32-bit operations.

  Only if the operation made in the lower half of the register doesn't
overflow or underflow. And it would only work with additions and
substractions, hardly on multiplications and divisions.

  And even then, it would probably be slower to load, shift, load,
calculate, store, shift, store than doing the same thing using two
registers without the shifts. Why you think that adding additional
shifts to basic operations would make anything faster is beyond my
comprehension.

> While 64-bit generally means more
> _precision_ in the calculations,

  No, no more precision (well, except perhaps if you are using fixed-point
arithmetics), just a wider range of values (and more addressable memory).

> a program could utilize the extra memory
> capacity available to each 64-bit operation to accomplish two 32-bit
> operations at the same time.

  With the overhead of additional shift operations? Hardly.

  Besides, as I said, it would only work if there's no overflow nor
underflow and hardly with anything else than additions and substractions
(and in the latter case the result must not be negative in either half
of the register). Hardly useful for anything practical.

  Also take into account that integer math operations are just a small
part of what a program does. A typical program does a whole lot of other
things than just additions and substractions. These things include eg.
reading and writing to memory, jumping around, comparing values (eg.
for a loop) and so on.

> That's why
> the question was asked in the first place, because a lot of us have a lot to
> learn about what advantages the new higher-precision hardware/software will
> provide.

  It's a mistake to think that 64 bits means "higher precision". It means
larger range of integer values. Integers are integers. They are already
exactly precise. There's no "higher precision" with integers.

  The only exception would be, as I said, if you used fixed-point
arithmetics. However, with current processors it's usually not advantageous
because the FPU is usually equally fast (if not even faster!) than using
fixed point with the CPU. In the era of 386's and 486's fixed point was
indeed faster than the FPU, but not nowadays.

  A 64-bit processor doesn't change how the FPU works. The FPU has used
64-bit (well, with Intel processors actually 80-bit) floating point since
at least the 80386 (if not even earlier).

-- 
                                                          - Warp

Post a reply to this message