Re: Porting HP C from Alpha to Itanium - __DIVG_C

On Mon, 04 Jun 2007 05:17:36 -0700, FredK <fred.nospam@xxxxxxx> wrote:


"Robert Deininger" <rdeininger@xxxxxxxxxxxxxxxxx> wrote in message
news:rdeininger-0306072027510001@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
In article <4661CE79.2F6A7B21@xxxxxxxxxxxxxxxx>, David J Dachtera
<djesys.no@xxxxxxxxxxxxxxxx> wrote:

For those of you keeping score at home, the three services are:

SYS$IEEE_SET_FP_CONTROL
SYS$IEEE_SET_PRECISION_MODE
SYS$IEEE_SET_ROUNDING_MODE

All documented and supported.

...which, of course, goes well beyond the highly touted "re-compile and
re-link"
source-code compatibility (other than privileged code, that is).

Who touted that, as an all-encompassing principle? VMS Engineering has
always made it perfectly clear that some non-privileged code won't port
easily.

The HW architecture-specific builtins are just that - HW specific. In some
cases, the usage was so widespread, and/or the replacement was so
straightforward - that they were provided.

The apparent provenance of the __DIVx_C builtin was that they were provided
for the people implementing the Alpha math library. The belief/feeling was
that they are only used by math & floating point experts who required
something very specific, and that such experts would be aware that when the
underlying floating point implementation completely changed - that they
would need to use alternative methods.

Having said that, I believe (and have suggested internally) that we (HP/VMS)
were remiss in not providing some type of writeup explaining the underlying
usage and suggesting alternatives.

In the case of __DIVG_C - I don't think it would have been a good idea to
try and emulate the instruction transparently. It was provided to allow
writing of some very specific high-performance math function - so wrapping a
sys$ieee_set_rounding_mode call around it may have provided very poor
performance if this builtin was inside a loop.

For the most part, typical C language programs are compile and go. A
typical C program doesn't use Alpha-specific builtins available only in HP
C.


I respectfully disagree. Requiring customers to recompile their apps is
bad enough and not providing transparency, because they are experts and
can fix it themselves is very poor business practice that borders on
arrogance.




--
PL/I for OpenVMS
www.kednos.com
.

Relevant Pages

  • Re: polygon normals and spherical co-ordinate systems
    ... > Just wondering why while most math books / courses (and internet math ... > But when I get to computer graphics texts or usage it seems to me ... describing polygon normals with a spherical system ... looking at light transfer issues in ray tracing and radiosity-like ...
    (comp.graphics.algorithms)
  • polygon normals and spherical co-ordinate systems
    ... Just wondering why while most math books / courses (and internet math ... well as cartesian co-ordinate systems. ... But when I get to computer graphics texts or usage it seems to me ... describing polygon normals with a spherical system ...
    (comp.graphics.algorithms)
  • Re: Raatikainens critique of Chaitin
    ... Jesse F. Hughes writes: ... > Robin Chapman writes: ... > Unfortunately for those of us with backgrounds in math and logic, ... > It's not a usage I like, but it's common enough to be in some ...
    (sci.math)
  • Re: Excel - Double Negatives (Past, Present and Future)
    ... I think there have a few that did the math (odd/even parms). ... >> Another usage is to convert numbers which are returned from string ...
    (microsoft.public.excel.programming)
  • Re: mod, modulo and % under 2.4 and 2.5
    ... There is no builtin modfunction at all, but there are (in Py 2.4, 2.5, ... in 'math' module: fmod() function ... since Py 2.5 in 'operator' module there is imod() and ...
    (comp.lang.python)