Re: C lang. embedded HLASM latest z/OS 2.1
And with assembler if you re-write it you are stuck with the new architecture, unless you keep the old assembler and the two are functionally equivalent (i.e., has not been enhanced since you re-wrote it). With C or C++, if your boss says "we have to ship this to a customer with a z900" you just re-compile with ARCH(5) and you have it. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Saturday, October 24, 2015 1:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: C lang. embedded HLASM latest z/OS 2.1 On 23/10/2015 8:28 PM, Jerry Callen wrote: > As to rewriting HLASM code in C - if you mostly just groveling through > control blocks and using non-authorized services, why not? It'll make the > code more accessible by others, in many cases it's just as efficient, and - > it's fun! I would say it can be significantly more efficient. I've re-compiled C programs for new architecture and got a x2 performance improvement. You're not going to get that with assembler. You have to rewrite the program. The fly in the ointment is SYS1.MACLIB is in HLASM/PL/X and the DSECT converter tool is not perfect. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C lang. embedded HLASM latest z/OS 2.1
On 23/10/2015 8:28 PM, Jerry Callen wrote: As to rewriting HLASM code in C - if you mostly just groveling through control blocks and using non-authorized services, why not? It'll make the code more accessible by others, in many cases it's just as efficient, and - it's fun! I would say it can be significantly more efficient. I've re-compiled C programs for new architecture and got a x2 performance improvement. You're not going to get that with assembler. You have to rewrite the program. The fly in the ointment is SYS1.MACLIB is in HLASM/PL/X and the DSECT converter tool is not perfect. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C lang. embedded HLASM latest z/OS 2.1
> What I'm aiming at is to rewrite my CBT distributed UNIX HLASM programs as C > programs instead. > Although I don't really know why I should. Just another of my oddities, I > guess. [...] I doubt there > are many z/OS people who like playing on the UNIX command line instead of in > ISPF. Count me in! I use emacs in USS (yes, it exists for z/OS - see http://www-03.ibm.com/systems/z/os/zos/features/unix/bpxa1ty1.html), and I find that it enables me to be much more productive than I am with ISPF. I was fluent with ISPF back in the 80's, but many years of living in Unixland has perverted me. :-) But you're right - we're probably a tiny minority. And I'm mostly working with data in the Unix file system, not z/OS datasets, which colors my perspective. As to rewriting HLASM code in C - if you mostly just groveling through control blocks and using non-authorized services, why not? It'll make the code more accessible by others, in many cases it's just as efficient, and - it's fun! -- Jerry Callen Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C lang. embedded HLASM latest z/OS 2.1
On 22 October 2015 at 11:17, Farley, Peter x23353 < peter.far...@broadridge.com> wrote: > And to your desire to replace the C prologue and epilogue -- Check out > Metal C. It allows you to do precisely that. You lose almost all I/O > facilities though, and you are thus forced / allowed to use inline > assembler I/O or your own custom-built I/O subroutines. There would seem to be no reason that one couldn't generate LE-compatible prologue/epilogue code in Metal C, and thus get the advantages, such as they are, of both schemes. Well pretty much the only thing I can think of is AR-mode support within the C language, which is all fine until an exception comes along that LE tries to handle... Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C lang. embedded HLASM latest z/OS 2.1
On Thu, Oct 22, 2015 at 10:17 AM, Farley, Peter x23353 <
peter.far...@broadridge.com> wrote:
> John,
>
> Depending on the OPT, ARCH and TUNE compiler settings I suspect it may be
> an optimization to avoid AGI (Address Generation Interlock). Nothing to do
> with alignment per se.
>
> And to your desire to replace the C prologue and epilogue -- Check out
> Metal C. It allows you to do precisely that. You lose almost all I/O
> facilities though, and you are thus forced / allowed to use inline
> assembler I/O or your own custom-built I/O subroutines.
>
I was really trying to avoid Metal C. What I'm aiming at is to rewrite my
CBT distributed UNIX HLASM programs as C programs instead. Although I don't
really know why I should. Just another of my oddities, I guess. I don't
even know if those programs are very popular or nor. I would guess not. I
doubt there are many z/OS people who like playing on the UNIX command line
instead of in ISPF.
I am just guessing that the newest xlc compiler was enhanced with in-line
assembler for non-Metal C mainly due the GNU C's ability to do so. Some of
the options in xlc seem to be "echoing" some of the abilities that GNU C
has. Perhaps to lure some GNU / Linux people to at least consider xlc.
>
> HTH
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John McKown
> Sent: Thursday, October 22, 2015 10:59 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: C lang. embedded HLASM latest z/OS 2.1
>
> On Thu, Oct 22, 2015 at 9:40 AM, Elardus Engelbrecht <
> elardus.engelbre...@sita.co.za> wrote:
>
> > John McKown wrote:
> >
> > >Mainly that the compiler inserted an NOPR 0 after my simple command.
> >
> > Hmmm, I remembered that Borland Turbo Pascal [1] could do that similar
> > trick, but I don't have MSDOS and Pascal anymore.
> >
> > I never tried that [inserting machine code to speed up things] out with C
> > and C++.
> >
> > > *04 0700 9 NOPR 0
> > > 74 581D 00B009 | L
> r1,176(r13,)
> >
> > Is that compiler action just for [full word / half word?] alignment?
> > Increase/decrease the instruction length by 1 or 2 bytes with same or
> other
> > instruction and see where it ends up.
> >
>
> Hum, I inserted a second instruction "LR 2,1" after the first one:
>
>09 | * __asm(" L 1,%0\n LR
> 2,1":"=m"(i3)::"r1","r2");
> *00 581D 00B0000B0 8 L 1,176(13)
> 09
> *04 1821 9 LR2,1
> 09
> *06 0700 10 NOPR 0
> 09
> 74 581D 00B009 | Lr1,176(r13,)
>
> 78 1821 09 | LR r2,r1
>
> 7A 0700 09 | NOPR 0
>10 | * printf("%.*s\n",i1,word);
>
>
> The NOPR is still there. I wonder if it is somehow used if I were to set a
> break point in a debugging session. I.e. the NOPR is there so that it can
> be overlain with the debug SVC or whatever is used.
>
> I'm just doing this to see if I can get up to the real desire: to embed
> assembler macros, such as TPG (TSO terminal I/O), in my C code. Although
> it might actually be simpler to just continue writing LE enabled HLASM
> "service" routines.
> Hum, wish I had a way to make an HLASM "program" which could be "in
> lined" by the C compiler in order to avoid the entry/exit code overhead. I
> am still, perhaps stupidly, concerned with "CPU overhead". If I weren't I
> could be a Windows programmer!
>
> --
>
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, please notify us immediately by
> e-mail and delete the message and any attachments from your system.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instruct
Re: C lang. embedded HLASM latest z/OS 2.1
John,
Depending on the OPT, ARCH and TUNE compiler settings I suspect it may be an
optimization to avoid AGI (Address Generation Interlock). Nothing to do with
alignment per se.
And to your desire to replace the C prologue and epilogue -- Check out Metal C.
It allows you to do precisely that. You lose almost all I/O facilities
though, and you are thus forced / allowed to use inline assembler I/O or your
own custom-built I/O subroutines.
HTH
Peter
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of John McKown
Sent: Thursday, October 22, 2015 10:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: C lang. embedded HLASM latest z/OS 2.1
On Thu, Oct 22, 2015 at 9:40 AM, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:
> John McKown wrote:
>
> >Mainly that the compiler inserted an NOPR 0 after my simple command.
>
> Hmmm, I remembered that Borland Turbo Pascal [1] could do that similar
> trick, but I don't have MSDOS and Pascal anymore.
>
> I never tried that [inserting machine code to speed up things] out with C
> and C++.
>
> > *04 0700 9 NOPR 0
> > 74 581D 00B009 | Lr1,176(r13,)
>
> Is that compiler action just for [full word / half word?] alignment?
> Increase/decrease the instruction length by 1 or 2 bytes with same or other
> instruction and see where it ends up.
>
Hum, I inserted a second instruction "LR 2,1" after the first one:
09 | * __asm(" L 1,%0\n LR
2,1":"=m"(i3)::"r1","r2");
*00 581D 00B0000B0 8 L 1,176(13)
09
*04 1821 9 LR2,1
09
*06 0700 10 NOPR 0
09
74 581D 00B009 | Lr1,176(r13,)
78 1821 09 | LR r2,r1
7A 0700 09 | NOPR 0
10 | * printf("%.*s\n",i1,word);
The NOPR is still there. I wonder if it is somehow used if I were to set a
break point in a debugging session. I.e. the NOPR is there so that it can
be overlain with the debug SVC or whatever is used.
I'm just doing this to see if I can get up to the real desire: to embed
assembler macros, such as TPG (TSO terminal I/O), in my C code. Although
it might actually be simpler to just continue writing LE enabled HLASM
"service" routines.
Hum, wish I had a way to make an HLASM "program" which could be "in
lined" by the C compiler in order to avoid the entry/exit code overhead. I
am still, perhaps stupidly, concerned with "CPU overhead". If I weren't I
could be a Windows programmer!
--
This message and any attachments are intended only for the use of the addressee
and may contain information that is privileged and confidential. If the reader
of the message is not the intended recipient or an authorized representative of
the intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication
in error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C lang. embedded HLASM latest z/OS 2.1
On Thu, Oct 22, 2015 at 9:40 AM, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:
> John McKown wrote:
>
> >Mainly that the compiler inserted an NOPR 0 after my simple command.
>
> Hmmm, I remembered that Borland Turbo Pascal [1] could do that similar
> trick, but I don't have MSDOS and Pascal anymore.
>
> I never tried that [inserting machine code to speed up things] out with C
> and C++.
>
> > *04 0700 9 NOPR 0
> > 74 581D 00B009 | Lr1,176(r13,)
>
> Is that compiler action just for [full word / half word?] alignment?
> Increase/decrease the instruction length by 1 or 2 bytes with same or other
> instruction and see where it ends up.
>
Hum, I inserted a second instruction "LR 2,1" after the first one:
09 | * __asm(" L 1,%0\n LR
2,1":"=m"(i3)::"r1","r2");
*00 581D 00B0000B0 8 L 1,176(13)
09
*04 1821 9 LR2,1
09
*06 0700 10 NOPR 0
09
74 581D 00B009 | Lr1,176(r13,)
78 1821 09 | LR r2,r1
7A 0700 09 | NOPR 0
10 | * printf("%.*s\n",i1,word);
The NOPR is still there. I wonder if it is somehow used if I were to set a
break point in a debugging session. I.e. the NOPR is there so that it can
be overlain with the debug SVC or whatever is used.
I'm just doing this to see if I can get up to the real desire: to embed
assembler macros, such as TPG (TSO terminal I/O), in my C code. Although
it might actually be simpler to just continue writing LE enabled HLASM
"service" routines.
Hum, wish I had a way to make an HLASM "program" which could be "in
lined" by the C compiler in order to avoid the entry/exit code overhead. I
am still, perhaps stupidly, concerned with "CPU overhead". If I weren't I
could be a Windows programmer!
>
> >This is just curiosity on my part. It is not a "bug" or a complaint.
>
> This is why we all need you. You learn on the hard way and we look on the
> easy way. ;-D
>
> Groete / Greetings
> Elardus Engelbrecht
>
> [1] - I wrote cryptographic code in mix of Turbo Pascal and MASM to
> protect my and my clients files. Good old MSDOS days when nothing was
> available for pure protection.
>
>
--
Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.
Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.
He's about as useful as a wax frying pan.
10 to the 12th power microphones = 1 Megaphone
Maranatha! <><
John McKown
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C lang. embedded HLASM latest z/OS 2.1
John McKown wrote: >Mainly that the compiler inserted an NOPR 0 after my simple command. Hmmm, I remembered that Borland Turbo Pascal [1] could do that similar trick, but I don't have MSDOS and Pascal anymore. I never tried that [inserting machine code to speed up things] out with C and C++. > *04 0700 9 NOPR 0 > 74 581D 00B009 | Lr1,176(r13,) Is that compiler action just for [full word / half word?] alignment? Increase/decrease the instruction length by 1 or 2 bytes with same or other instruction and see where it ends up. >This is just curiosity on my part. It is not a "bug" or a complaint. This is why we all need you. You learn on the hard way and we look on the easy way. ;-D Groete / Greetings Elardus Engelbrecht [1] - I wrote cryptographic code in mix of Turbo Pascal and MASM to protect my and my clients files. Good old MSDOS days when nothing was available for pure protection. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
C lang. embedded HLASM latest z/OS 2.1
Just "for fun and profit" (learning), I inserted an unnecessary HLASM
statement into a C program (helloworld.c type). I am curious about the
generated code. Mainly that the compiler inserted an NOPR 0 after my simple
command. The statement was the first executable in main() and output in the
compiler listing looks like:
08 | * char word[]="123456";
6E D206 D0B4 1000 08 | MVC
word$init$0(7,r13,180),+CONSTANT_AREA(r1,0)
09 | * __asm(" L
1,%0":"=m"(i3)::"r1");
*00 581D 00B0000B0 8 L 1,176(13)
09
*04 0700 9 NOPR 0
09
74 581D 00B009 | Lr1,176(r13,)
78 0700 09 | NOPR 0
10 | * printf("%.*s\n",i1,word);
The compile was done on z/OS UNIX shell invocation of xlc:
xlc -qaggregate -qasm -qchars=unsigned -qevents=hello.events -qexpmac
-qinfo -qlanglvl=extc1x -qoffset -qshowinc -qlist -qskipsrc=hide
-qsource=hello.lst hello.c
The compiler said it was: "5650ZOS V2.1.1 z/OS XL C"
This is just curiosity on my part. It is not a "bug" or a complaint.
--
Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.
Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.
He's about as useful as a wax frying pan.
10 to the 12th power microphones = 1 Megaphone
Maranatha! <><
John McKown
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
