David writes:
>
> complaint.  Why do many of the new intrinsics insist that the date be
> in one specific format?  This design goes to a lot of work to define a
...
> Why not have HPDATEDIFF look like:
>
>      HPDATEDIFF(firstdate,firstcode,seconddate,secondcode,diffindays,status)
>
> Yes, it means that *all* callers will now have to pass in date codes
> for each of the dates.  But if you leave the date codes off of these
> intrinsics the *majority* of callers will have to make additional
> intrinsic calls (often more than one) just to get the dates into a
> format that something like HPDATEDIFF can handle.

I agree, and point out that the costs aren't all that high.  Assuming
the user is passing in type 18 (which the original proposal required),
the additional CPU cost (above the original proposal) is minimal, as
can be seen in the following annotated pseudo-code:

   var
      internal_first_date : integer;
      internal_second_date : integer;
      local_status        : hpe_status;

   try
      begin
#1    if firstcode = 18 then
#2       internal_first_date := firstdate
#3
      else
         begin
         internalHPDATECONVERT (...firstdate & firstcode ..., local_status);
         if local_status.all <> 0 then
            begin
            hperrpush (local_status.all);
            escape (bad first date);
            end;
         end;

      if secondcode = 18 then
         internal_second_date := seconddate
      else
         begin
         internalHPDATECONVERT (...seconddate & secondcode ..., local_status);
         if local_status.all <> 0 then
            begin
            hperrpush (local_status.all);
            escape (bad second date);
            end;
         end;

      ...do calculation using the two internal type-18 dates.

#4    status.all := 0;        {all ok}
      end

   recover
      status.all := escapecode;


notes:

   #1  cost: 1 LDW, one LDI, one COMB ... cheap.

   #2  cost: 1 register move, cheap  (assuming optimized code)

   #3  cost: 2 cycles (the BRanch over the "else" part of the code)

   #4  cost: 1 instruction (LDW the STATUS address ... the extra
             parameters for the date type pushed the STATUS parameter
             from being in a register to being in passed in memory)

Total: about 13 instructions, three of which are memory references.

If the user had been forced to call HPDATECONVERT prior to EVERY
HPDATEDIFF (sp?) call, the cost is much higher ... so this proposal
can save some costs (for one, the "status" parameter address wouldn't have to
be checked 3 times).  This assumes that the routine "internalHPDATECONVERT"
only checks the validity of the date address, not the status address.

--
Stan Sieler                                          [log in to unmask]