Re: How declare in C++ a constant in an assembler module?

[Bernd Oppolzer]

bit fields in C are a very strange and IMHO ill-faited construct,
I never use them. You don't even have control if the bits are allocated
from the left or from the right in the word; that is not specified in 
the standard.


What I do, if I have to deal with bits: use the bit shift operations, and
the logical operations. This is far more portable (of course, the problem
with the endianness remains, but as long as you dont move this data
across system boundaries, all is well ... when moving, you need to convert
this data to a format that will survive the platform move, for example
hexadecimal edited or readable decimal digits).

If you need to be sure about the size of an integer across platforms,
the only way is to define something like

typedef int INT32;

and to do it different on different platforms, controlled by #ifdef ...

but most of the time, this is not needed, because today (for example),
you don't have 16 bit platforms any more, and every int is guaranteed
to have 32 bits.

Kind regards

Bernd



Am 20.11.2014 23:19, schrieb retired mainframer:

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Shmuel Metz (Seymour J.)
Sent: Thursday, November 20, 2014 10:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How declare in C++ a constant in an assembler module?


  

But I'd like to know how, in C, I can specify the size of an integer
in bits, so that I get the proper allocation when I am on a 12-bit, an
18-bit, a 24-bit, a 30-bit, a 36-bit, a 48-bit, a 60-bit or a 64-bit
machine.

The standard provides optional types for 8, 16, 32, and 64.  In the general
case, the only way I know is to use a bit-field within a structure.  With
judicious use of placeholder bit-fields, you can even specify which set of
bits within the bytes you want the integer to occupy.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How declare in C++ a constant in an assembler module?

[Bernd Oppolzer]

Until today, PL/1 does not support 64 bit (addressing mode), so this 
discussion comes too early.
As already mentioned, the types that have explicit bit numbers like BIN 
FIXED (15),
BIN FIXED (31) or BIN FIXED (63) - which exists already - and the 
UNSIGNED variants,

as - for example - BIN FIXED (64) UNSIGNED, have no problem.

What really would be a problem for a 64 bit exploiting PL/1 compiler:
all PTR variables would suddenly need 8 bytes, and that would break most of
the current structure definitions etc., because much code implicitely 
assumes
that the pointers need 4 bytes. This is exactly the same problem that we 
faced

when we first migrated our insurance math package to a 64 bit Linux.

Another problem, when doing this migration, was, that all long declarations
(which were 4 bytes until this time) had to be changed to int, because long
now was 8 bytes, too, which was a big problem for us. This problem would
not have occured with the PL/1 notation BIN FIXED (31). So I am not sure,
what is better in this case.

(similar problem some 20 years ago, when int was 16 bit on PC platform,
so we had to code long back then, to get 31 bit on all platforms ...
PCs, Unix, z/OS ... which was OS/390 then).

Kind regards

Bernd



Am 20.11.2014 18:26, schrieb Paul Gilmartin:

On Thu, 20 Nov 2014 11:32:22 -0500, Tony Harminc wrote:

Why would you have to/want to change the declarations? Specify the
size needed for your application data, and let the compiler figure out
what to do internally. Of course if you're doing something bizarre
like UNSPECing a pointer value into a FIXED BIN (31)...


Especially if it's a pointer to above-the-bar storage.

Are there separate 24-bit, 31-bit, and 64-bit pointer types?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How declare in C++ a constant in an assembler module?

[David Crayford]

On 21/11/2014 12:32 AM, Tony Harminc wrote:

On 20 November 2014 05:30, David Crayford  wrote:

I'm interested in how easy it is to recompile a PL/I program for 64-bit when 
you have to explicitly specify bit widths on the types. That's trivial to do in 
C.

Why would you have to/want to change the declarations? Specify the
size needed for your application data, and let the compiler figure out
what to do internally. Of course if you're doing something bizarre
like UNSPECing a pointer value into a FIXED BIN (31)...


I should have asked a different question. Does Enterprise PL/I support 
64-bit?



Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How declare in C++ a constant in an assembler module?

[retired mainframer]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Shmuel Metz (Seymour J.)
> Sent: Thursday, November 20, 2014 10:36 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: How declare in C++ a constant in an assembler module?


 
> But I'd like to know how, in C, I can specify the size of an integer
> in bits, so that I get the proper allocation when I am on a 12-bit, an
> 18-bit, a 24-bit, a 30-bit, a 36-bit, a 48-bit, a 60-bit or a 64-bit
> machine.

The standard provides optional types for 8, 16, 32, and 64.  In the general
case, the only way I know is to use a bit-field within a structure.  With
judicious use of placeholder bit-fields, you can even specify which set of
bits within the bytes you want the integer to occupy.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How declare in C++ a constant in an assembler module?

[Shmuel Metz (Seymour J.)]

In , on 11/20/2014
   at 06:30 PM, David Crayford  said:

>I'm interested in how easy it is to recompile a PL/I program for
>64-bit when you have to explicitly specify bit widths on the types.

Your question has an assumption contrary to fact. You can specify the
size of an integer in PL.I, but you don't have to.

But I'd like to know how, in C, I can specify the size of an integer
in bits, so that I get the proper allocation when I am on a 12-bit, an
18-bit, a 24-bit, a 30-bit, a 36-bit, a 48-bit, a 60-bit or a 64-bit
machine.

No, #define doesn't answer the question.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How declare in C++ a constant in an assembler module?

[Paul Gilmartin]

On Thu, 20 Nov 2014 11:32:22 -0500, Tony Harminc wrote:
>
>Why would you have to/want to change the declarations? Specify the
>size needed for your application data, and let the compiler figure out
>what to do internally. Of course if you're doing something bizarre
>like UNSPECing a pointer value into a FIXED BIN (31)...
> 
Especially if it's a pointer to above-the-bar storage.

Are there separate 24-bit, 31-bit, and 64-bit pointer types?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How declare in C++ a constant in an assembler module?

[Tony Harminc]

On 20 November 2014 05:30, David Crayford  wrote:
> I'm interested in how easy it is to recompile a PL/I program for 64-bit when 
> you have to explicitly specify bit widths on the types. That's trivial to do 
> in C.

Why would you have to/want to change the declarations? Specify the
size needed for your application data, and let the compiler figure out
what to do internally. Of course if you're doing something bizarre
like UNSPECing a pointer value into a FIXED BIN (31)...

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How declare in C++ a constant in an assembler module?

[David Crayford]

I'm interested in how easy it is to recompile a PL/I program for 64-bit when 
you have to explicitly specify bit widths on the types. That's trivial to do in 
C. 

> On 19 Nov 2014, at 8:53 pm, John Gilmore  wrote:
> 
> As I have had occasion to note here before, the traditions of C and
> its sequelæ interest me chiefly as illustrations of  one or another
> pathology.
> 
> The PL/I tradition provides better positive guidance.  From the
> beginning, with the PL/I F
> compiler, such a construction as
> 
> declare hashvcs entry(character(*) varying, binary fixed(15,0))
>  returns(binary fixed(15,0)) ;
> . . .
> declare hashin character(*) varying, hashval binary fixed(15,0) ;
> 
> hashval = hashvcs(hashin, 1101b) ;
> 
> resulted in the creation of a halfword temporary initialized  to have
> the binary value 1101b (decimal 13).  The address of that temporary,
> not that of the (internal/converted) value of the literal 1101b, was
> then made available to the entry hashvcs, which was free to mutilate
> it without non-local effect.
> 
> Today, one can make corresponding distinctions within a function like
> hashvcs, as in
> 
> hashvcs: procedure(vcs, modulus)
>  returns(signed binary fixed(15,0))
>  reorder ;
> 
>  declare (vcs character(*) varying2,
> modulus signed binary fixed(15,0))
> nonassignable parameter ;
> 
>  . . .
>  return(hashval) ;
> 
> end hashvcs ;
> 
> C and its sequelæ are and now seem likely to remain toys.  They have
> achieved all of  the portability of assembly language without its
> expressive power.
> 
> John Gilmore, Ashland, MA 01721 - USA
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How declare in C++ a constant in an assembler module?

[Shmuel Metz (Seymour J.)]

In <1624998193642608.wa.paulgboulderaim@listserv.ua.edu>, on
11/19/2014
   at 07:41 AM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> said:

>PL/I might be more likely,

Too late; it's already been done.

Note: the OP and I don't agree on much, but he's right about the
comparison of C and PL/I.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How declare in C++ a constant in an assembler module?

[Bernd Oppolzer]

I don't like C++ very much, for several reasons, but I am working with C 
(and PL/1)
for more than 20 years now, and IMHO and in my experience C is a 
wonderful language
where I can create large, secure, reliable and effective software 
products ... of course
it has to be well done, as with every other language, too. C is NO TOY 
language.


More arguments below.

Very respectfully, kind regards

Bernd Oppolzer


Am 19.11.2014 13:53, schrieb John Gilmore:

As I have had occasion to note here before, the traditions of C and
its sequelæ interest me chiefly as illustrations of  one or another
pathology.

The PL/I tradition provides better positive guidance.  From the
beginning, with the PL/I F
compiler, such a construction as

declare hashvcs entry(character(*) varying, binary fixed(15,0))
   returns(binary fixed(15,0)) ;
. . .
declare hashin character(*) varying, hashval binary fixed(15,0) ;

hashval = hashvcs(hashin, 1101b) ;

you can do similar function calls in C; I don't see your problem;
you only have to take the call-by-value paradigm into account
and you need to make all your call-by-reference parameters explicit
by passing pointers.

In C, this would look like

hashval = hashvcs (hashin, 0x0d);   /* hex instead of binary */

the function prototype could look like this:

int hashvcs (char *hashin, int hashval);

there are some possible variations; the int parameter and result type 
could be short
(but I would prefer int, because C promotes parameters to int anyway), 
and the char *hashin
could be something more sophisticated, maybe a structure containing a 
length, or the
length could be passed as another parameter. I don't like the convention 
with the
zero byte at the end very much ... but it's just that: a convention ... 
you can define
your function interfaces without using it. You can even emulate PL/1 
varchars, if you

want.

BTW: at the site I am working we are calling all the time C libraries 
from PL/1; we solved
all the problems with different data representation etc., no problem at 
all. The reason for
us to do this: the C part of the application needs to be present on all 
platforms

(insurance math). I believe I told you already.

resulted in the creation of a halfword temporary initialized  to have
the binary value 1101b (decimal 13).  The address of that temporary,
not that of the (internal/converted) value of the literal 1101b, was
then made available to the entry hashvcs, which was free to mutilate
it without non-local effect.

the call-by-value paradigm also doesn't generate non-local effects.
Sometimes for performance reasons parameters which are not meant to be 
changed
by the function are passed by reference (via pointer). In this case, the 
function
specification tells, that the parameter is not changed by the function. 
If it is changed,
this is an error in the function implementation and can (and must) be 
fixed locally.



Today, one can make corresponding distinctions within a function like
hashvcs, as in

hashvcs: procedure(vcs, modulus)
   returns(signed binary fixed(15,0))
   reorder ;

   declare (vcs character(*) varying2,
  modulus signed binary fixed(15,0))
  nonassignable parameter ;

   . . .
   return(hashval) ;

end hashvcs ;

C and its sequelæ are and now seem likely to remain toys.  They have
achieved all of  the portability of assembly language without its
expressive power.

No. With C, it was for example possible for me to write an XML parser that
works on Windows, Linux, other Unixes, OS/2 and z/OS, with the same 
source, without

platform or opsys dependencies. Validating or non-validating, SAX and DOM,
three times faster than XerCes, a storage management on top of standard
ANSI malloc, that outperforms malloc in most cases for many small 
allocations
of storage (and returns all storage to the system at the end of the XML 
processing).


I see no other language which would make this possible.

I have a lot of other tools written in C, all are running on all the 
platforms above from the start.


John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How declare in C++ a constant in an assembler module?

[Steve Comstock]

On 11/19/2014 6:41 AM, Paul Gilmartin wrote:

On Wed, 19 Nov 2014 07:53:56 -0500, John Gilmore wrote:


C and its sequelæ are and now seem likely to remain toys.  They have
achieved all of  the portability of assembly language without its
expressive power.


An amusing aphorism, about 1/3 true.

The preponderance of expressive power of HLASM rests in its
preprocessor, but that shouldn't be discounted.

"[P]ortability"?  Be serious.  I can compile and execute"

#include 
int  main( void ) { printf("Hello, world!\n"); }

... on z, x86, ARM, Sparc, undoubtedly others I haven't access
to test.  Please exhibit a HLASM program of comparable complexity
and portability.  I don't believe even:

  START
  END

... will compile on most of those architectures (barring Hercules
or z390 which I shall call "toys").

Entire operating systems which support great enterprises are
implemented in C on those platforms and others.  How many
in HLASM?  There are candidates to supersede C.  I don't
count HLASM among them.  PL/I might be more likely, but
a very long shot.


Paul: it was humor / sarcasm. [At least that's how I read it.]

-Steve Comstock



-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How declare in C++ a constant in an assembler module?

[Paul Gilmartin]

On Wed, 19 Nov 2014 07:53:56 -0500, John Gilmore wrote:
>
>C and its sequelæ are and now seem likely to remain toys.  They have
>achieved all of  the portability of assembly language without its
>expressive power.
> 
An amusing aphorism, about 1/3 true.

The preponderance of expressive power of HLASM rests in its
preprocessor, but that shouldn't be discounted.

"[P]ortability"?  Be serious.  I can compile and execute"

#include 
int  main( void ) { printf("Hello, world!\n"); }

... on z, x86, ARM, Sparc, undoubtedly others I haven't access
to test.  Please exhibit a HLASM program of comparable complexity
and portability.  I don't believe even:

 START
 END

... will compile on most of those architectures (barring Hercules
or z390 which I shall call "toys").

Entire operating systems which support great enterprises are
implemented in C on those platforms and others.  How many
in HLASM?  There are candidates to supersede C.  I don't
count HLASM among them.  PL/I might be more likely, but
a very long shot.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How declare in C++ a constant in an assembler module?

[John Gilmore]

As I have had occasion to note here before, the traditions of C and
its sequelæ interest me chiefly as illustrations of  one or another
pathology.

The PL/I tradition provides better positive guidance.  From the
beginning, with the PL/I F
compiler, such a construction as

declare hashvcs entry(character(*) varying, binary fixed(15,0))
  returns(binary fixed(15,0)) ;
. . .
declare hashin character(*) varying, hashval binary fixed(15,0) ;

hashval = hashvcs(hashin, 1101b) ;

resulted in the creation of a halfword temporary initialized  to have
the binary value 1101b (decimal 13).  The address of that temporary,
not that of the (internal/converted) value of the literal 1101b, was
then made available to the entry hashvcs, which was free to mutilate
it without non-local effect.

Today, one can make corresponding distinctions within a function like
hashvcs, as in

hashvcs: procedure(vcs, modulus)
  returns(signed binary fixed(15,0))
  reorder ;

  declare (vcs character(*) varying2,
 modulus signed binary fixed(15,0))
 nonassignable parameter ;

  . . .
  return(hashval) ;

end hashvcs ;

C and its sequelæ are and now seem likely to remain toys.  They have
achieved all of  the portability of assembly language without its
expressive power.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How declare in C++ a constant in an assembler module?

[David Crayford]

On 18/11/2014 9:33 PM, Paul Gilmartin wrote:

Bad history.  The original C did not provide "const" so:

o programmers passed string literals to functions that declared them
   as "char *" rather than "const char *".


Very true. That's a *good* history lesson.

These days everybody understands const correctness and almost all 
runtime libraries demand it. If you see a C function with an input 
variable of char * then you should be judicious about using it. Side 
effects are evil!
Some languages like Ada have in/out keywords that do a much better job 
than C/C++ const. C++ is a different beast because you can have a const 
argument that actually copies the input value via a copy constructor 
even when you

think it's a constant reference - void( const std::sting & in ).


o In those days, some programmers modified string literals.

So for compatibility with traditional practice and malpractice, the
implied type of a string literal is not const.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How declare in C++ a constant in an assembler module?

[Paul Gilmartin]

On Tue, 18 Nov 2014 05:52:59 -0500, John Gilmore wrote:

>What is a non-static constant?  What is the rationale for, say, an
>automatic one?
> 
Bad overloading of terminology/semantics.  "static" implies that no
ESD LD is generated for the object.  Like "own" in other languages.
Absent "static" the object (possibly a constant) is to be accessible
in other translation units.

>Named and unnamed constants, literals, should properly be treated as a
>separate storage class
> 
Bad history.  The original C did not provide "const" so:

o programmers passed string literals to functions that declared them
  as "char *" rather than "const char *".

o In those days, some programmers modified string literals.

So for compatibility with traditional practice and malpractice, the
implied type of a string literal is not const.


On Tue, 18 Nov 2014 17:18:13 +0800, David Crayford wrote:
>> 
>> IIRC, the SAS/C compiler put them inline if declared "const";
>> in WSA otherwise.  I believe it does not violate ANSI C if an
>> object is declared "const" in one translation unit, with "const"
>> omitted in another, as long as it is not modified by the former.
>> Of course, this caused chaos with SAS/C.
>
>IMO, static const should be inlined like C++ does but certainly not
>extern variables.
>
I wrote "const" but not "static const".  In a non-rent compilation,
extern variables may be inlined or in a separate CSECT with no
requirement to copy to WSA. I don't believe ANSI allows "const"
to be dissociated from non-"const".

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How declare in C++ a constant in an assembler module?

[David Crayford]

On 18/11/2014 6:52 PM, John Gilmore wrote:

What is a non-static constant?  What is the rationale for, say, an
automatic one?


In C or C++ you can easily cast it to non-const. It's more explicit in 
C++ because one would use a const_cast<> expression. But in C it's not 
so obvious.



Named and unnamed constants, literals, should properly be treated as a
separate storage class

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How declare in C++ a constant in an assembler module?

[David Crayford]

On 18/11/2014 6:47 PM, Bernd Oppolzer wrote:

IIRC, there is a compiler option ROCONST that deals with this,
but maybe only for ANSI C, not for C++.

If ROCONST is specified, static const variables will be placed
in STATIC CSECT, not in WSA, even if compiler option RENT
is specified (please look into the manuals for details).



It's not the same thing. ROCONST places constants into a literal pool 
and does not assign any stack space to them. #pragma 
variable(varname,norent) makes the variable a VCON and let's the linker

deal with it.

We had problems with large static read-only arrays being allocated two 
times

(in STATIC as init pattern and once again in WSA, which lead to storage
problems).

Kind regards

Bernd


Am 18.11.2014 10:18, schrieb David Crayford:

On 18/11/2014 1:07 PM, Paul Gilmartin wrote:

On Mon, 17 Nov 2014 17:55:10 -0800, Charles Mills wrote:


Bingo! Thanks.


IIRC, the SAS/C compiler put them inline if declared "const";
in WSA otherwise.  I believe it does not violate ANSI C if an
object is declared "const" in one translation unit, with "const"
omitted in another, as long as it is not modified by the former.
Of course, this caused chaos with SAS/C.


Hmm, and that's the problem with ANSI C (and C++). The standards can 
be interpreted in different ways which leads to inconsistent 
implementations. Throw into the mix the likes of Microsoft compilers 
violating the

standard and you have the problem we have today with portability issues.

IMO, static const should be inlined like C++ does but certainly not 
extern variables.



(BTDT)


-Original Message-
From: David Crayford
Sent: Monday, November 17, 2014 5:38 PM

The compiler wants to put all external variables into WSA. To turn 
that off

specify norent.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How declare in C++ a constant in an assembler module?

[John Gilmore]

What is a non-static constant?  What is the rationale for, say, an
automatic one?

Named and unnamed constants, literals, should properly be treated as a
separate storage class

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How declare in C++ a constant in an assembler module?

[Bernd Oppolzer]

IIRC, there is a compiler option ROCONST that deals with this,
but maybe only for ANSI C, not for C++.

If ROCONST is specified, static const variables will be placed
in STATIC CSECT, not in WSA, even if compiler option RENT
is specified (please look into the manuals for details).

We had problems with large static read-only arrays being allocated two times
(in STATIC as init pattern and once again in WSA, which lead to storage
problems).

Kind regards

Bernd


Am 18.11.2014 10:18, schrieb David Crayford:

On 18/11/2014 1:07 PM, Paul Gilmartin wrote:

On Mon, 17 Nov 2014 17:55:10 -0800, Charles Mills wrote:


Bingo! Thanks.


IIRC, the SAS/C compiler put them inline if declared "const";
in WSA otherwise.  I believe it does not violate ANSI C if an
object is declared "const" in one translation unit, with "const"
omitted in another, as long as it is not modified by the former.
Of course, this caused chaos with SAS/C.


Hmm, and that's the problem with ANSI C (and C++). The standards can 
be interpreted in different ways which leads to inconsistent 
implementations. Throw into the mix the likes of Microsoft compilers 
violating the

standard and you have the problem we have today with portability issues.

IMO, static const should be inlined like C++ does but certainly not 
extern variables.



(BTDT)


-Original Message-
From: David Crayford
Sent: Monday, November 17, 2014 5:38 PM

The compiler wants to put all external variables into WSA. To turn 
that off

specify norent.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How declare in C++ a constant in an assembler module?

[David Crayford]

On 18/11/2014 1:07 PM, Paul Gilmartin wrote:

On Mon, 17 Nov 2014 17:55:10 -0800, Charles Mills wrote:


Bingo! Thanks.


IIRC, the SAS/C compiler put them inline if declared "const";
in WSA otherwise.  I believe it does not violate ANSI C if an
object is declared "const" in one translation unit, with "const"
omitted in another, as long as it is not modified by the former.
Of course, this caused chaos with SAS/C.


Hmm, and that's the problem with ANSI C (and C++). The standards can be 
interpreted in different ways which leads to inconsistent 
implementations. Throw into the mix the likes of Microsoft compilers 
violating the

standard and you have the problem we have today with portability issues.

IMO, static const should be inlined like C++ does but certainly not 
extern variables.



(BTDT)


-Original Message-
From: David Crayford
Sent: Monday, November 17, 2014 5:38 PM

The compiler wants to put all external variables into WSA. To turn that off
specify norent.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How declare in C++ a constant in an assembler module?

[Charles Mills]

It struck me that it seemed like a static declared const need not be "made 
reentrant." But what if someone were to cast it non-const? You gun, your 
bullet, your foot.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, November 17, 2014 9:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How declare in C++ a constant in an assembler module?

On Mon, 17 Nov 2014 17:55:10 -0800, Charles Mills wrote:

>Bingo! Thanks.
> 
IIRC, the SAS/C compiler put them inline if declared "const"; in WSA otherwise. 
 I believe it does not violate ANSI C if an object is declared "const" in one 
translation unit, with "const"
omitted in another, as long as it is not modified by the former.
Of course, this caused chaos with SAS/C.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How declare in C++ a constant in an assembler module?

[Paul Gilmartin]

On Mon, 17 Nov 2014 17:55:10 -0800, Charles Mills wrote:

>Bingo! Thanks.
> 
IIRC, the SAS/C compiler put them inline if declared "const";
in WSA otherwise.  I believe it does not violate ANSI C if an
object is declared "const" in one translation unit, with "const"
omitted in another, as long as it is not modified by the former.
Of course, this caused chaos with SAS/C.

(BTDT)

>-Original Message-
>From: David Crayford
>Sent: Monday, November 17, 2014 5:38 PM
>
>The compiler wants to put all external variables into WSA. To turn that off
>specify norent.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How declare in C++ a constant in an assembler module?

[Charles Mills]

Bingo! Thanks.

I almost wrote to you directly rather than asking the list ...

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Crayford
Sent: Monday, November 17, 2014 5:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How declare in C++ a constant in an assembler module?

The compiler wants to put all external variables into WSA. To turn that off
specify norent.

#pragma variable(FOO,norent)
extern const long FOO;

On 18/11/2014 9:31 AM, Charles Mills wrote:
> I have a C++ program. I have three "global" constants that I wish to 
> define in assembler modules. Environment: prelinker, non-XPLINK, RENT.
>
> Here is what I am doing now:
>
> In the C++ at namespace scope:
>
> extern const long FOO;
>
> In the Assembler:
>
> FOO  DCF'123'
>   ENTRY FOO
>
> The error I am getting from the prelinker is ERROR EDC4014: Undefined 
> writable static objects are detected: FOO
>
> I suspect this is due to the fact that the C++ compiler and link 
> magically make static variables reentrant: if you say static int bar 
> there is actually one copy of bar for each executing instance of your
program.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How declare in C++ a constant in an assembler module?

[David Crayford]

The compiler wants to put all external variables into WSA. To turn that off 
specify norent.

#pragma variable(FOO,norent)
extern const long FOO;

On 18/11/2014 9:31 AM, Charles Mills wrote:

I have a C++ program. I have three "global" constants that I wish to define
in assembler modules. Environment: prelinker, non-XPLINK, RENT.

Here is what I am doing now:

In the C++ at namespace scope:

extern const long FOO;

In the Assembler:

FOO  DCF'123'
  ENTRY FOO

The error I am getting from the prelinker is ERROR EDC4014: Undefined
writable static objects are detected: FOO

I suspect this is due to the fact that the C++ compiler and link magically
make static variables reentrant: if you say static int bar there is actually
one copy of bar for each executing instance of your program.

Does anyone know if there is some linkage or similar that I need to specify
on the extern declaration?

RTFM not much help -- everything I see refers to subroutines in Assembler,
not variables. Worst case I can wrap subroutines around the variables and
return their values, but that seems a little silly. (I have a lot of
experience with calling Assembler from C++.)

Charles

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

How declare in C++ a constant in an assembler module?

[Charles Mills]

I have a C++ program. I have three "global" constants that I wish to define
in assembler modules. Environment: prelinker, non-XPLINK, RENT.

Here is what I am doing now:

In the C++ at namespace scope:

extern const long FOO;

In the Assembler:

FOO  DCF'123'
 ENTRY FOO

The error I am getting from the prelinker is ERROR EDC4014: Undefined
writable static objects are detected: FOO

I suspect this is due to the fact that the C++ compiler and link magically
make static variables reentrant: if you say static int bar there is actually
one copy of bar for each executing instance of your program.

Does anyone know if there is some linkage or similar that I need to specify
on the extern declaration?

RTFM not much help -- everything I see refers to subroutines in Assembler,
not variables. Worst case I can wrap subroutines around the variables and
return their values, but that seems a little silly. (I have a lot of
experience with calling Assembler from C++.)

Charles

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN