From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,31d67020d4b04d5b
X-Google-Attributes: gid103376,public
From: eachus@spectre.mitre.org (Robert I. Eachus)
Subject: Re: Simple Real_Time.Time_Span question
Date: 1998/10/16
Message-ID: <EACHUS.98Oct16162633@spectre.mitre.org>#1/1
X-Deja-AN: 401914306
References: <6vvsgo$rvo$1@nnrp1.dejanews.com>
 <700usk$cht$1@nnrp1.dejanews.com> <702b25$30a$1@nnrp1.dejanews.com>
 <EACHUS.98Oct14135537@spectre.mitre.org> <705g81$g9s$1@nnrp1.dejanews.com>
Organization: The Mitre Corp., Bedford, MA.
Newsgroups: comp.lang.ada
Date: 1998-10-16T00:00:00+00:00
List-Id: <comp.lang.ada>

In article <705g81$g9s$1@nnrp1.dejanews.com> dennison@telepath.com writes:

  > Hmmm. I guess there's a bit of a hole in my education where
  > multiprecision integer arithmetic is concerned. I assume an
  > add-with-carry instruction has some way of handling when *two*
  > bits need to be carried (eg: the msbit of both previous operands
  > was a 1, and there was a carry-in to that bit-position). Or
  > perhaps you have to add one to the second word of the result if
  > there was a carry and the msbit of the first word of the result is
  > 0?

  You are losing me a bit here, but I think I can answer your
question.  Let's assume a 32-bit machine (with 32-bit registers) where
we want to add two 64-bit numbers.  Let's be specific and use the
680x0 family.  Assume that the quantity in the register pair D0,D1 is
to be added to the quantity in the register pair D2,D3:

   ADD.L D1,D3
   ADDX  D0,D2

   The ADDX instruction adds the carry bit to the source and
destination, and puts the result in the destination register.  For the
case of a double length add, that is all there is to it.  After the
ADDX, all the condition code values are what you would want.  The Z
bit is only set if the entire result is zero, the N bit is set if the
quantity as a whole is negative, etc.  If you want to do a series of
such adds, then you do something like:

   ADD.L D2,D5
   ADDX  D1,D4
   ADDX  D0,D3

   And so on.  In any case, there is only one possible carry bit, just
as you can only carry a value between 0 and 9 when adding decimal
numbers by hand.

 > Either way it sounds like simple arithmetic will be significantly
 > slower for a Duration implemented in this way than one would
 > typically expect of a predefined type. I can certianly see where
 > compiler vendors for some real-time platforms might decide *not* to
 > do that. So I don't think I can safely assume that a Time_Span of a
 > few microseconds will translate well into Duration on any platform
 > that this code may end up on (or even its platform, 'till I find
 > out for sure).

   You are confused. I left out register loading code above, any
required overflow checking, etc.  From experience, adding or
subtracting 64-bit integer quantities on a 32-bit register machine is
less than 20 percent slower at most than the same algorithm using
32-bit quantities.  Multiplication by small factors, expecially if
constant, doesn't affect these results, but any use of division can
and will have a large impact.

   Since arithmetic as a part of time-keeping is almost all addition
and subtraction, this means that a 64-bit Duration type will have an
almost negligible impact on code speed.  (Remember, in recent hardware
on-chip processing times are dominated by memory access bandwidth.
And of course one of the ways that chip-manufacturers speed things up
is by reading an entire cache line in one buss operation, which may
take dozens of CPU cycles.)
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...