Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

P1788 An ARM hardware Perspective (was: Kulisch Rounded Ops)

On 16/05/11 00:10, Ralph Baker Kearfott wrote:

Dan, P-1788,

I'm a bit confused at this point.  I think the confusion
comes from not knowing precisely what is meant by
"processor."  Does "processor" include a software
environment, or does it mean a  hardware processor, as in
"8087 floating point processor?"


Baker,
I have recently been involved in spinning out an ARM multi-processor rather than arithmetic _per_se_ and can say a little bit about the ARM hardware perspective on P-1788.
(1) The FPU is a bolt-on extra. Actually the FPU concept is really very similar to the 8087 for 8086, except that the co-processor is physically present on the die.
(2) Although there is a "standard" arrangement between the two units (ALU and FPU), one could imagine doing what I _think_ Professor Kulisch wants. 

  (a) Add two FPUs;
  (b) Add special decode logic for the new instructions
  (c) feed the data through to both units
  (d) perform operations and feed results back.
(3) To provide code compatibility between those processors with zero, one, or two FPUs, we would exploit the ability to trap out "unexpected instructions", and drop out to interrupt service routines.
(4) The reason that many ARM chip designers would select (3) over (2) is that of power efficiency.
In other words in the mobile device market (20 billion of our ARM chips have been licensed so far), we need to be mindful of the power efficiency of our devices just as much as we do the execution efficiency.
For illustrative purposes, adding an FPU to our cores will double the power consumption of each core. Adding two will cause battery life to plummet to 33% of the original. We have also tripled the silicon area of the core as well.
Of course, one possible answer to this is: "We're not concerned with power and low performance devices". However, this answer would mean that P1788 could not be sensibly used with modern hand-held devices, and I suggest that this is a market that we _should_ be considering. After all a modern mobile phone has more computing power than a desk top of twenty five years ago.
If it helps, consider whether you'd like field engineers to have cheap, hand-held, battery powered P1788 compliant devices. If so, then insisting on a specific way of realizing this may hamper their provision, as getting the battery life will be key to the device's acceptability, not execution speed alone.
This is a plea to let the chip designers optimize their devices to achieve the best overall performance and to not second guess us by mandating -- or even suggesting -- an unhelpful and ill-considered (not to say ill-defined) "hardware" solution. 

Regards,

Dave Lester, Manchester University.





Baker

On 05/15/2011 10:42 AM, Dan Zuras Intervals wrote:

Date: Sun, 15 May 2011 17:06:05 +0200
From: Ulrich Kulisch<Ulrich.Kulisch@xxxxxxxxxxx>
To: Ian McIntosh<ianm@xxxxxxxxxx>
CC: stds-1788@xxxxxxxxxxxxxxxxx
Subject: Re: I vote NO on Motion P1788/M0024.02:RoundedOperations


Ian:
As I said already in my answer on Dan's mail the motion does not require 
hardware instructions with explicit rounding modes!
The motion requires arithmetic operations with the directed roundings as 
distinct operations. The rounding shall be an integral part of the
operation.

These operations are the basic building blocks for interval arithmetic.
For a quarter of a century these operations have not been available and
this was felt as great deficiency for interval arithmetic. Of course,
many tricks have been developed to code around this. But with an
interval arithmetic standard these times definitively shall be left behind. 

Best wishes
Ulrich



    Ulrich,

    I quote from your motion:

        Instead, a future interval arithmetic standard should
        require that EVERY FUTURE PROCESSOR shall provide the
        16 operations listed above as distinct instructions.

    (emphasis yours in bold).

    The key word is "shall".  In the nomenclature of a standard
    the word "shall" is used to describe something that is
    mandatory.

    If, as you say, you intend that these instructions are NOT
    required, the word that indicates that is "should".

    The fly in the ointment is that the word "should" is
    interpreted by implementers as "need NOT be done".

    In that case we, as a standards body, cannot count on the
    mentioned feature to be there&  we must write the rest of
    our standard to presume that it is not.

    Those are your choices for a motion: Require it with "shall"
&  eliminate Intel, IBM,&  nearly all other current machines
    from conforming to our standard.  Or recommend it with
    "should" and assume it is not there.

    The third alternative is not to mention it at all&  count
    on enlightened self interest to encourage the implementers
    out there to innovate in their own ways to beat the
    competition as they see best.

    I choose this last which is why I voted no.

    I apologise if my argument centers around wordsmithing
    but in this case I think it goes to intent as well.

    Yours,

                Dan