Dennis Handly ([log in to unmask]) wrote:

>Ken Graham ([log in to unmask]) wrote:
>: By this I mean that the supplied intrinsic to do 64 bit pointer
manipulation
>: only does a single operation PTR=PTR+constant.  As any programmer can
tell
>: you, that is not sufficient

>What more do you need?  Compares?

Well, yes, or more specifically, pointer difference computation, to make the
suite of mathematical functions complete.

>: when the compiler overrides 64 bit pointer comparison, and
>:strips the top 32 bits prior to expression evaluation.

> would assume a 64 bit pointer comparison would work correctly for ==
> and !=.  But not all of the time for the others.  :-(
> (If you cast to longint/bit52, then it would work.)

The C compiler is written in such a way as to make simple casting not work.
This was reported to the lab, and they said it will not be fixed.

>: Had the compilers simply had a pragma for MPE added to allow TRUE 64 bit
>: manipulation,

>Or a new data type.  Though you are right, a pragma could switch the
>compiler to have a different internal data type.

The ^ptr is a new data type already, and not part of the original ANSI C,
or even POSIX C, standards.

>: >   HPFMOVEDATALTOR ... ditto, in a known order (allowing "clever"
>: >   HPFMOVEDATARTOL ... ditto, in a known order (allowing "clever"
>: These two should have been rolled into HPFMOVEDATA.

>Except that makes HPFMOVEDATA slower.  That's why you have memcpy(3) and
>memmove(3).

You are right.  Though for me the question was why have one routine for
shifting left, and another for shifting right, when a simple compare
would be all that is required if only one routine were created.

>: Since PASCAL is the language being used, maybe the developers have not
>: heard of K&R, and probably have no idea what I am even talking about.

>If you mention ANSI C, everyone could know what you're talking about.
>(K&R is some old dialect of C.  :-)

I like that: "some old dialect of C."  ;-)))

>: >OTOH, MPE has had a history of what seems like at least 10 years of
>: >neglect from the Compiler Language group within HP.

>(Disclaimer: I have no idea what CSY is doing.)

>There use to be only one language organization doing the work.  6 to 7
>years ago, CSY went its own way.

>So there is one group doing HP-UX (IA64 and PA) and one for MPE/iX.
>I assume the coordination is much better for the IA64 efforts.

It is my understanding that this is not the case at least for C.
There is one group doing the language and they do it for HP-UX, and
secondarily
for MPE.  That is why you can compile MPE C code on an HP-UX box, and bring
the object modules over to the MPE to link them, and it works just fine.
The argument from the lab against making any changes to the C compiler was
that it was the same compiler as the one on HP-UX.

>: There exists only one pointer manipulation intrinsic, which adds a
constant
>: to a pointer, as stated.

>Not really a constant.  Hopefully an expression.

Constant here refers to the type of value being passed, not its syntax.

>: I also implemented the rest of the suite of functions that should have
been
>: done as well.
>: Ken Graham.

>Did you make them inline Pascal functions using casts to longint?
>Or do you use C?

I use C which is why the errors in the documentation about the parameter
types on
the calls referenced were an issue.

Ken Graham.