HP3000-L Archives

November 2000, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Emerson, Tom # El Monte" <[log in to unmask]>
Reply To:
Emerson, Tom # El Monte
Date:
Mon, 20 Nov 2000 19:58:02 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (74 lines)
> -----Original Message-----
> From: Gavin Scott [mailto:[log in to unmask]]
> Looking at the code:
> [...]
>
> we see that the first parameter to HPCIGETVAR is a "hidden" integer
> parameter (passed by value) indicating how many actual
> parameters are being
> passed to this "extensible" Intrinsic.  So something like:
>
> HPCIGETVAR(6, varname, &status, 10, &strlen, 2, varvalu);
>
> Will probably work.  (I'm at home with a cold at the moment
> and my brain
> isn't working well enough to actually go try this right now :-)

since I'm still at the computer where I generated the original message, I
tried it -- it looks like this is on the right track -- changing it as
follows:

    HPCIGETVAR(/* PARM COUNT: */ 6,
        varname,&status,
        10,&strlen,
         2, varvalu);

doesn't "fail spectactularly" -- it just simply fails...

R:[/EMERSON/WORK]> gcc -o psysidx psysidx.c
R:[/EMERSON/WORK]> ./psysidx
The system name starts with Z

[the output should have been "the system name starts with R", since
HPSYSNAME has the value "RAVEN"]

> -----Original Message-----
> From: Gavin Scott [mailto:[log in to unmask]]
> Emerson, Tom # El Monte writes:
>
> > I'm encountering a strange problem calling the system
> > intrinsic HPCIGETVAR
> [...]
> > One thing I did notice in the web-based documentation
> > [indicates] "#pragma intrinsic" isn't a valid
> > pre-processor statement

> This is indeed the problem.  Since gcc has no knowlege of the
> MPE Intrinsic
> mechanism, you have to get the parameters right when you call
> an Intrinsic
> from one of the Gnu languages.  This includes accounting for "hidden"
> parameters, long versus short addresses, etc.
>
[...]
>
> FInding a more permanent solution to this problem is probably the most
> popular enhancement request among our GCC support customers
> at the moment.

According to Mark's documentation [which I suspect is a pretty straight copy
of the standard gnu gcc documentation] under the "miscellaneous preprocessor
directives" heading (at http://www.dis.com/gnu/gcc/cpp_39.html#SEC40) is the
following paragraph:

"The ANSI standard specifies that the effect of the `#pragma' directive is
implementation-defined. In the GNU C preprocessor, `#pragma' directives are
not used, except for `#pragma once' (see section Once-Only Include Files).
However, they are left in the preprocessor output, so they are available to
the compilation pass."

This somewhat implies that it's "fair game" to create a "#pragma intrinsic"
directive that applies only to the MPE/iX implementation, but at the same
time seems to indicate that if you implement anything other than "#pragma
once", you're Gcc isn't gcc...

ATOM RSS1 RSS2