Re: pointers in different storage models

Hi, Michael:

Another approach would be to not "mess with" the C source at all, but to use compiler switches to compile the entire C module(s) with 128-bit pointers. This does not preclude using teraspace.

In other words, you can compile your C modules with:

CRTCMOD ... TERASPACE(*YES *TSIFC) DTAMDL(*P128) STGMDL(*TERASPACE)

This means all pointers within your code will use 128-bit pointers, yet you can take advantage of teraspace storage.

All the best,

Mark

> On 6/5/2010 2:10 AM, Schmidt, Mihael wrote:

Thanx. Yes that helped a lot. Though I don't want mess that much with the source.

After some tries it actually worked even in an RPG program. Great.

Though after I changed some other code to __ptr128 I got the following error:

prop_object.c, 1106.46: CZM0280(30) Function argument assignment between
types "void* __ptr128* __ptr64" and "void* __ptr64* __ptr64" is not
allowed.

typedef void * __ptr128 prop_object_t;

bool
prop_object_equals_with_error(prop_object_t obj1_128, prop_object_t obj2_128,
bool *error_flag)
{
void * obj1, obj2;
obj1 = obj1_128;
obj2 = obj2_128;
...


line 1106: if (!_prop_stack_pop(&stack,&obj1,&obj2,
&stored_pointer1,&stored_pointer2))



bool _prop_stack_pop(prop_stack_t, prop_object_t *, void ** , void **, void **);


My guess is that it is the third parameter on the call to pop() put I don't know enough about C to know why this happened and how it can be fixed. My understanding is that obj1 and obj2 are 64 bit pointers. So why the error message with 128 bit pointer?

Thanx in advance

Mihael



-----Original Message-----
From: c400-l-bounces+mihael.schmidt=rossmann.de@xxxxxxxxxxxx [mailto:c400-l-bounces+mihael.schmidt=rossmann.de@xxxxxxxxxxxx] On Behalf Of Mark S. Waterbury
Sent: Saturday, June 05, 2010 12:36 AM
To: C programming iSeries / AS400
Subject: Re: [C400-L] pointers in different storage models

Hi, Mihael:

I think rather than creating a whole new "layer" or "wrapper" around
your service program, if you have the source for the *MODULEs comprising
the service program, you could just change the "interfaces" to the
exported procedures and functions so they use 128-bit pointers, e.g.
using the special __ptr128 keyword:

char * __ptr128 p;

Then, within your procedures, the first thing you do is copy the
parameter pointer to a local variable that is a 64-bit pointer, then use
only 64-bit pointers inside the C or C++ code, which is more efficient.
Then, if you need to return a pointer, convert that from a 64-bit
pointer to a 128-bit pointer just before the return.

Does that make sense?

In other words, you don't need a whole extra layer. If your intention
is that this *SRVPGM procedures are callable from any other ILE
language, all parameters should be 128-bit pointers, because I don't
think any other ILE HLL languages besides C and C++ currently support
64-bit pointers.

Does that help?

Mark S. Waterbury

> On 6/4/2010 5:16 PM, Schmidt, Mihael wrote:

Oh. I think I missed something. Pointer conversion will automatically take place for C and C++ programs. Does the RPG compiler / runtime automatically convert pointers? If I take the result of my program my guess is that it doesn't.

Is the solution to build a C wrapper service program for the "real" service program which contains a wrapper procedure for every procedure containing pointer as return values or parameters, so that they will be converted from 16 byte to 8 byte and vice versa?

Mihael