Re: HLASM religious texts, was Variable symbol without leading &

[Gary Weinhold]

The PoOp manual has always gone beyond the hardware definitions of machine language instructions to provide the symbolic format in HLASM (and its predecessors) of each machine language instruction, e.g., MVC D1(L,B1),D2(B2).
There could be many other zSeries assemblers (I don't know of any) that do not use the symbolic format documented in the PoOp to create those machine language instructions. HLASM relies on the PoOp to document the symbolic format of zSeries insructions. When we code in that format, we rely on HLASM to convert the code into machine language instructions. Otherwise we'd have to code machine language instructions as constants, either directly or in macros.

It appears that the PoOp, by documenting the HLASM symbolic format of instructions, is a critical and necessary supplement to the HLASM Reference manuals. Since AFAIK HLASM only supports IBM's zSeries (and predecessors) hardware, it would be close to useless without the PoOp.


Gary Weinhold
Senior Application Architect
DATAKINETICS | Data Performance & Optimization
Phone:+1.613.523.5500 x216
Email: wein...@dkl.com
Visit us online at www.DKL.com
E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.

[Seymour J Metz]

Yes, you need PoOps to determine what format each instruction has, but the actual syntax of each field is documented only in the HLASM reference manual.

________________________________________
From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> on behalf of Gary Weinhold <wein...@DKL.COM>
Sent: Thursday, June 29, 2023 11:27 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: HLASM religious texts, was Variable symbol without leading &

The PoOp manual has always gone beyond the hardware definitions of machine language instructions to provide the symbolic format in HLASM (and its predecessors) of each machine language instruction, e.g., MVC D1(L,B1),D2(B2).
There could be many other zSeries assemblers (I don't know of any) that do not use the symbolic format documented in the PoOp to create those machine language instructions. HLASM relies on the PoOp to document the symbolic format of zSeries insructions. When we code in that format, we rely on HLASM to convert the code into machine language instructions. Otherwise we'd have to code machine language instructions as constants, either directly or in macros.

It appears that the PoOp, by documenting the HLASM symbolic format of instructions, is a critical and necessary supplement to the HLASM Reference manuals. Since AFAIK HLASM only supports IBM's zSeries (and predecessors) hardware, it would be close to useless without the PoOp.

Gary Weinhold
Senior Application Architect
DATAKINETICS | Data Performance & Optimization
Phone:+1.613.523.5500 x216
Email: wein...@dkl.com

Visit us online at http://secure-web.cisco.com/1ndcMZTfeISGrp8uEhbfCGuxvypenFIsth9o2h0QwGHoN93zUooDFVOvibVmJmLsA0VgDW5PhXR_TD0bH5n3A4G8Uc63ezdZVnjJayudzugHySXLIXM8dt1CpmRVifPIBhP8-AAKhT45j_lWFNUAo7H0UodkmASX8SOiVmUcbTw_MJ8wxXfu_zuH2sAnW_vvH8y3hgQ5Ix7WQz5w9LYbWFxrNqnX-k_MWqslEKVeA1DPKhHQdu9qbW8DaStYX0LhSWy8rEOQA1N13HuPVDJspZOZbGeyTajXptTMu0kByg-R0RCjAgL8NSEkFDVMlbuUNLbRHvVZE8AT3MjQ4K_Nkgc-iYoQouhr_NYBRG4nTVIFqRTPRnRQjQT7m37KrSq9Of_ah85Chj92HXyKf4aZ0LBmCJobfPS1vdR6p9vz-scY5rBOetedo8zpcXrW5pID2/http%3A%2F%2Fwww.DKL.com

[Charles Mills]

Nope. @Gary absolutely nailed it.

You could have a perfectly valid and usable "alternative" assembler that
used XML or some other syntax to specify instructions, and assemble them
into valid Z binary instructions.

The opcode-blank-op1,op2 with operands in the disp(base) or disp(index,base)
and similar formats is not at all an architectural thing -- but it is in the
Principles nonetheless.

Principles is effectively an HLASM manual as well as an architecture
specification.

Charles

[Jonathan Scott]

Ref: Your note of Thu, 29 Jun 2023 08:57:50 -0700

The GNU assembler as used for Linux on IBM Z uses a similar
"raw" format for instructions to that shown in Principles of
Operation, although with some differences. There is more
information about it here, comparing with HLASM:

http://linuxvm.org/Present/SHARE99/S8131db.pdf

Jonathan Scott, HLASM
IBM Hursley, UK

[Seymour J Metz]

It looks like it supports expressions but not USING.

________________________________________
From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> on behalf of Jonathan Scott <jonatha...@VNET.IBM.COM>
Sent: Thursday, June 29, 2023 12:22 PM

To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: HLASM religious texts, was Variable symbol without leading &

Ref: Your note of Thu, 29 Jun 2023 08:57:50 -0700

The GNU assembler as used for Linux on IBM Z uses a similar
"raw" format for instructions to that shown in Principles of
Operation, although with some differences. There is more
information about it here, comparing with HLASM:

http://secure-web.cisco.com/164iyEgpWbUJavTf-6_rgAlU3dioQWeCabqtRHRrbFegtOIpqH2v6aVaF8DOr5hLL5noHenII54JtZK7p-odbC6_3ob6NGTqpkBMr9_pZoKWWtED8dFYRnR2m8Px6zL2-Q3tb6dmcux134qDwfAnB5Ryo8_cJPNF6MUcVFgKfBbgnpuIp_kEcOG7zEm8Bird7h4pL8ri5ksBAnrdS5StmbOyRlOhL5LwiUnaxcS-Ivxucre8UcTqDXMkbmYAl3vek2nlBGGWBs3dLBCsxFjK_tteQlgMeWj56qtgzQh0_FSMpw05qbrlh4HCEQorVEIoYsc0QpeI0trZ0Csle5exClJyiw0fBgoD077J1z16g6FNmtNxlqqPrAlSi6uDyWhF6dt8Pwrljsfhw555Hm0iYwQlMeYn9b8a0oBmdDOO4O0k/http%3A%2F%2Flinuxvm.org%2FPresent%2FSHARE99%2FS8131db.pdf

[Michael Watkins]

Does anyone have a pdf copy of the IBM TotalStorage Redbook, 'Enhanced Catalog Sharing and Management, SG24-5594' that they'd be willing to share?

I think it was originally published in 1999.

[Peter Sylvester]

One page that describes that index and base registers  are exchanged in GAS reminds me to a
suggestion I have made for HLASM.

No, not to do the same, but issue a warning when you have

      rxinst  ra,offset(ra)
instead of
      rxinst  ra,offset(,ra)

IBM's Mühlen mahlen langsam :-) Langsam ernährt sich das Eichhörnchen, Nüsschen für NüsscheN.

Best

[Paul Rogers]

Good afternoon,

It appears that a copy is available via the Wayback Machine:

https://web.archive.org/web/20040724104820/http://www.redbooks.ibm.com:80/pubs/pdfs/redbooks/sg245594.pdf

Hope this helps!

Paul

[Michael Watkins]

Thanks so much. I'd never used the wayback machine before and never considered looking there.

-----Original Message-----
From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> On Behalf Of Paul Rogers
Sent: Thursday, June 29, 2023 1:23 PM
To: ASSEMBL...@LISTSERV.UGA.EDU

Subject: Re: pdf Copy 'Enhanced Catalog Sharing and Management, SG24-5594' (1999)?

CAUTION: This email originated from outside of the Texas Comptroller's email system.
DO NOT click links or open attachments unless you expect them from the sender and know the content is safe.

[Paul Gilmartin]

On 6/29/23 11:17:06, Seymour J Metz wrote:
> It looks like it supports expressions but not USING.
>

Does it support division by 0? The mavens hereabouts have told me
that is a valuable feature of HLASM when I'd rather see it treated
as an error.

I can think of exactly one good reason for not using HLASM on Linux.

But GNU is probably a fork of a hardware-neutral assembler. I once
needed to modify some ISV source code like that. I don't recall
whether it was USING-aware. It was rife with BALR RBASE,0 rather
than using a code base register. And it dedicated two registers
to -4096 and -8192 so they could simulate negative displacements
in an era before the hardware provided them.

> ________________________________________
> From: Jonathan Scott <jonatha...@VNET.IBM.COM>

> Sent: Thursday, June 29, 2023 12:22 PM
>

> The GNU assembler as used for Linux on IBM Z uses a similar
> "raw" format for instructions to that shown in Principles of
> Operation, although with some differences. There is more
> information about it here, comparing with HLASM:
>
> http://secure-web.cisco.com/164iyEgpWbUJavTf-6_rgAlU3dioQWeCabqtRHRrbFegtOIpqH2v6aVaF8DOr5hLL5noHenII54JtZK7p-odbC6_3ob6NGTqpkBMr9_pZoKWWtED8dFYRnR2m8Px6zL2-Q3tb6dmcux134qDwfAnB5Ryo8_cJPNF6MUcVFgKfBbgnpuIp_kEcOG7zEm8Bird7h4pL8ri5ksBAnrdS5StmbOyRlOhL5LwiUnaxcS-Ivxucre8UcTqDXMkbmYAl3vek2nlBGGWBs3dLBCsxFjK_tteQlgMeWj56qtgzQh0_FSMpw05qbrlh4HCEQorVEIoYsc0QpeI0trZ0Csle5exClJyiw0fBgoD077J1z16g6FNmtNxlqqPrAlSi6uDyWhF6dt8Pwrljsfhw555Hm0iYwQlMeYn9b8a0oBmdDOO4O0k/http%3A%2F%2Flinuxvm.org%2FPresent%2FSHARE99%2FS8131db.pdf

--
gil

[Seymour J Metz]

Yes, gas is a generic assembler that supports many platform. I don't understand why division by zero is valuable and not an error.

HLASM? Presumably because it is proprietary.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List [ASSEMBL...@LISTSERV.UGA.EDU] on behalf of Paul Gilmartin [00000014e0e4a59...@LISTSERV.UGA.EDU]
Sent: Thursday, June 29, 2023 3:19 PM

To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: HLASM religious texts, was Variable symbol without leading &

[Paul Gilmartin]

On 6/29/23 13:31:11, Seymour J Metz wrote:
> ... I don't understand why division by zero is valuable and not an error.
>
IIRC, it provides a (too) clever way of generating a boolean at
assembly (not conditional) time:
(X-Y)/(X-Y) is one iff X<>Y.

--
gil

[Rick Troth]

Or maybe "limber" instead of "limbo", meaning flexible. But puns and
analogies always break down in the end. I have come to accept that.

Started this before I left town for a few days.
It's initially knee-jerk, but seemed worth saying.

I do love HLASM, and I miss it in my current role.
What's so great about it? Well, like with any assembler, you get full
control of the machine (within constraints: privileged mode or not,
stuff like that).
I've known other assemblers (I mean for other architectures) and enjoyed
them. But none were as robust. That's partly because of the assemblers
themselves, but also because of the architectures. Z is Z.

I love C (and I don't miss it: it's everywhere).
But then, I refuse to step into "obfuscations" and other trickery that
some C coders love to dabble in. You know, keep it simple!
What I like about C is that it gets me as close as possible to the
machine and yet remain highly portable. You say C code is not portable?
Au contraire! I can demonstrate that it is (or that it "can be").
Other assemblers are not as much fun as HLASM. I can avoid them when I
use C.

Don't get me started about C++.
Some love it, but it's a different language. If you really want C++
maybe consider Java.

This is what tripped me up:

> Beyond all the fighting here, just be glad the assembler macro
language is so powerful.
> Every time I have to do something in C that call out for a macro, I'm
appalled at how pathetic that language is!

I've spoken with PHSiii about his post, and he was talking more about
the C pre-processor (where I mostly concur, it's kinda sucky) than about
C the language.
But there are plenty people who truly dislike C from all sides. I've
become sensitive after reading a lot of C bashing (not on this list, but
in other fora).

Critique of the language, and especially of what some call "macros", I
willingly accept.
It's that P-word adjective that really bites. (pathetic)
Where else can I find anything as close to the hardware and yet not
directly ISA-bound? That's anything but pathetic.

*instruction-set architecture

Indeed, HLSAM has a powerful macro feature.
By comparison, C has a "pre-processor". I use it for a handful of
symbolic constants. Beyond that, it uglifies my code, so I avoid it.

There's no accounting for taste, but C is a very good language,
especially for HLASM fans.
If one just doesn't like the language, that's a matter of taste. I hope
that we all can steer clear of languages we dislike.
Seriously, if you just don't like C then I hope you never have to use
it. But let's not engage in language flame wars.
I'd like to think that I'm somewhat broad minded: I hate Java, but not
the language, rather the requirement for the JVM and the ecosystem which
has grown up around it.

*Java was a language looking for a purpose, then found popularity when
the web was young

It's possible to write ugly pathetically byzantine unmaintainable code
in C.
It's possible to write ugly pathetically byzantine unmaintainable code
in HLASM.

C takes a lot of flack these days, as people are (or claim to be) very
concerned about security (while protecting the WRONG THINGS, but I
digress).
Buffer overruns and other such things lead the charge as they look for
"safe" languages. Something about guns and feet might fit here, or the
Kilpatrick to Alexander spoof from the movie Airplane. (James Kilpatrick
played by William Tregoe with Shana Alexander off-screen. You know the
one!) "They bought their compilers. They knew what they were getting into!"

Ironic that none of these C haters (in the field, not on this list)
throw a single dart at assembler. Why is that?

The up-and-coming "safe" language intended for "systems" is Rust.
Who thought up that name? What did they want to convey? Maybe they think
"systems" level coding is old and weathered and ... er, uh ... rusty?
But I am trying to have Rust (compiler) in my doctor's bag-o-tricks.
It's almost as difficult to build as LLVM and 'clang'.
Rust enjoys growing popularity because it is touted as a "systems"
language without the risks of C (like for stepping on your own memory,
y'all have heard the stories).
That takes me back to the reason I *like* C: it lets me do much of what
I can do in assembler (stepping on my own memory) but somewhat portably.

Question: if Rust is "safe" will it actually let me flip bits with the
same precision as C?

https://www.youtube.com/watch?v=uhU7Fgw5PmI


-- R; <><

[Seymour J Metz]

C might be close to the machine on a OPDP-11, but it's certainly not close to the machine on, e.g., VAX, Z. Theree are things that take one line of assembler but many lines of code on C. It is one of my least favorite languages.

OTOH, even though I hate, loathe and despise C, I found myself defending C when someone complained about for (;;), which I thought was perfectly clear.

De gustibus non disputandum est.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: IBM Mainframe Assembler List [ASSEMBL...@LISTSERV.UGA.EDU] on behalf of Rick Troth [tro...@GMAIL.COM]
Sent: Tuesday, July 18, 2023 3:30 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: looking for limbo languages - how low can you go?

[Phil Smith III]

Rick wrote about C and its power. As he noted, I *was* referring to the macro language/preprocessor when I said "pathetic". Because it is. It's old enough that it really should be more mature.

[Paul Gilmartin]

On 7/18/23 15:10:47, Phil Smith III wrote:
> Rick wrote about C and its power. As he noted, I *was* referring to the macro language/preprocessor when I said "pathetic". Because it is. It's old enough that it really should be more mature.

Pascal has no macros.

If the language is (FSVO) sufficiently complete it shouldn't need
them. Perhaps expanding subroutines inline for optimization.

--
gil

[Paul Gilmartin]

On 7/18/23 13:30:35, Rick Troth wrote:
>
> I'd like to think that I'm somewhat broad minded: I hate Java, but not the language, rather the requirement for the JVM and the ecosystem which has grown up around it.

Java can be done very wrong. I've sought a portable (i.e. to more
than one desktop OS) unXmit. I thought Java might be a solution,
but what I find is a .tar.gz archive containing dozens of files.

In contrast, identical jedit .jar files (with small wrapper scripts)
run on Linux and MacOS. and <https://math.hws.edu/xJava/MB/index.html>
GUI runs alike on Linux, displaying via X11 and MacOS, displaying via
system graphics. The file open dialog works on both. I guess thee
things are implemented in the maligned JVM. the separate CLI works
on desktop and z/OS.

> *Java was a language looking for a purpose, then found popularity when the web was young

Java? Or Javascript?

--
gil

[Seymour J Metz]

That approach doesn't work well for, e.g., decision-table macros, report-generator macros.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: IBM Mainframe Assembler List [ASSEMBL...@LISTSERV.UGA.EDU] on behalf of Paul Gilmartin [00000014e0e4a59...@LISTSERV.UGA.EDU]
Sent: Tuesday, July 18, 2023 7:13 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: looking for limbo languages - how low can you go?

[Jon Perryman]

Rick,
I'm not hating on C. It's silly to say that C hardware near. I would say less than 5% of the x86 or z instructions are used by the language. Look at the x86 instruction manual or the IBM POPS. Do you think malloc is written in C? C gives you access assembler at a minimum, there is an assembler SVC coded in the C program. Only assembler is hardware near.

C is not a good language for solving complicated problems because it over complicates solutions. Without the macro language in assembler, it would have the same problems. Ask yourself, how would you implement STORAGE, DCB, OPEN or other macro important system macro. Would you create a struct and fill it in? Would you have various calls with various parameter lists. How would you validate that the correct combination of arguments have been coded.

[zMan]

Pascal? That language that's widely used and available on every platform?
Oh, wait...
Seriously, I'm not sure what point you were trying to make?

--
zMan -- "I've got a mainframe and I'm not afraid to use it"

[Seymour J Metz]

The point that I am trying to make is that there are things that are easy with macros but difficult with just procedures. Or were you asking Phil, who was the one to mention Pascal?

Of course, in a language like LISP where you can build code on the fly, things are different.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: IBM Mainframe Assembler List [ASSEMBL...@LISTSERV.UGA.EDU] on behalf of zMan [zedgar...@GMAIL.COM]
Sent: Tuesday, July 18, 2023 11:30 PM

[Rick Troth]

On 7/18/23 19:30, Paul Gilmartin wrote:
>> *Java was a language looking for a purpose, then found popularity
>> when the web was young
>
> Java?  Or Javascript?

Java


JavaSCRIPT was originally called ECMAScript. I don't know its history,
but pretty sure it was designed from the get-go to be embedded. (See
also: Tcl)


Java was a language looking for a purpose. It became viable during the
era when the web was new.
The language itself is pretty good. (And FWIW does not have macros.) But
it has some quirky packaging concepts (see also: Ada) and my real beef
against it is the need for the JVM. It is difficult, and it's
particularly "heavy", to call native from Java. It's impossible to call
Java from native.


-- R; <><

[Ian Worthington]

> Java was a language looking for a purpose.

Java was a language designed for set top boxes


Best wishes / Mejores deseos /  Meilleurs vœux

Ian ...

[Rick Troth]

On 7/19/23 09:29, Ian Worthington wrote:
>> Java was a language looking for a purpose.
> Java was a language designed for set top boxes

That is correct.

Java was created by James Gosling and others, then at Sun.

My jab is because, at the time, there were no specific set-top boxes or
similar appliances on the Java development team's radar (that they were
talking about). So one of the first Java applications was a web browser.
It was an effective demonstration.

My beef against it is, because of the nature of JVM and the fact that in
the Java ecosystem nobody compiles to native, it is difficult to
interface with other languages.

Java as a language is actually very good, and very "up stack" (compared
to C or HLASM or any other assembler). It would offer a good
complementary relationship with "limbo languages" if it interfaced better.


-- R; <><

[Rick Troth]

On 7/18/23 23:24, Jon Perryman wrote:
> I'm not hating on C. It's silly to say that C hardware near. I would say less than 5% of the x86 or z instructions are used by the language. Look at the x86 instruction manual or the IBM POPS. Do you think malloc is written in C? C gives you access assembler at a minimum, there is an assembler SVC coded in the C program. Only assembler is hardware near.

Apologies for not being more clear.
I was trying to say that C is as close as I (personally) can get to the
hardware and yet be portable.
Compare C with any assembler, and no, it's not "hardware near". But it
IS portable, which no assembler can be, by nature of assemblers.

> C is not a good language for solving complicated problems because it over complicates solutions. Without the macro language in assembler, it would have the same problems. Ask yourself, how would you implement STORAGE, DCB, OPEN or other macro important system macro. Would you create a struct and fill it in? Would you have various calls with various parameter lists. How would you validate that the correct combination of arguments have been coded.

It's fair to say, even with the sophisticated macro capability of HLASM,
any assembler is "not a good language for solving complicated problems".
At least, not any better than C. Complicated problems are where one
wants "up stack" languages (Java perhaps, or Rexx, or Python, or even
Tcl). C is tedious. Assembler is also tedious. With stock macros (that
we all use), HLASM is much less tedious than other assemblers, but is
not less tedious than C.

I see that I presumed upon combining languages. I do realize that few
projects start out intentionally using more than one language. Doing
selective details in C or assembler while doing "big stuff" in Python or
Rexx is better (for many projects) than doing the whole work in just one
language.


I am surprised, and sorry, that my post has led to some flamage.
I had not considered that our various opinions would drag us so far from
objectivity.


-- R; <><

[Dave Jones]

I very much dislike C. I find many of its concepts hard to understand,
especially the use of pointers and memory management. It's just not a
high-enough programming language for what I want to do. Of all of the
languages that I have run across (admittedly not that many) I prefer PL/I.
It has a formal definition, with very little "implementation defined"
stuff. In my thinking, C does the easy stuff while leaving me to do the
hard stuff, and it's just the opposite with PL/I.
Yes, I realize it is hard to write a compiler for, which does limit its
availability, although there is now a very good implementation for Intel
Linux for free.
Just my $0.02 worth of course.
DJ

[Chris Craddock]

Hi Jon,

"It's silly to say that C hardware near. I would say less than 5% of the x86 or z instructions are used by the language."

I just delivered a brand new z/OS automation product that's about 40% HLASM and 60% C++. Yes really, it's IBM's C++ running APF authorized under LE in a z/OS STC. The old me would have been horrified, but times change. It would have been untenable to write the whole thing in HLASM.

You would be shocked if you looked at a z/OS C++ listing. Spoiler: the C/C++ compiler and libraries exploit the living shit out of the z architecture instruction set. There are waaaay more new instructions in the generated C++ than in the HLASM part (I wrote both parts).

It is true that the C/C++ macro processor is pretty dumb compared to the HLASM macro language. And yet that doesn't seem to be much of a limitation if any. The programming models are just different.

CC
________________________________
From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> on behalf of Jon Perryman <jper...@PACBELL.NET>
Sent: Tuesday, July 18, 2023 10:24 PM
To: ASSEMBL...@LISTSERV.UGA.EDU <ASSEMBL...@LISTSERV.UGA.EDU>

Subject: Re: looking for limbo languages - how low can you go?

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DuhU7Fgw5PmI&data=05%7C01%7C%7Cb536e26441554531eba208db8807a55d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638253338693015997%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=NqhSHYmSKupvrkyz0wjjPdSbXEZhgzT4YeEBYrDUDno%3D&reserved=0<https://www.youtube.com/watch?v=uhU7Fgw5PmI>


-- R; <><

[Phil Smith III]

Chris Craddock wrote, in part, re:

>>"It's silly to say that C hardware near. I would say less than 5% of the x86 or z instructions are used by the language."

>You would be shocked if you looked at a z/OS C++ listing. Spoiler: the
>C/C++ compiler and libraries exploit the living shit out of the z
>architecture instruction set. There are waaaay more new instructions
>in the generated C++ than in the HLASM part (I wrote both parts).

Indeed! And the generated code between opt(0) and opt(3) is so different, it's hard to believe it's doing the same thing, yet it is. It's impressive as hell. In the one compute-intensive case that we measured, unoptimized used half again as much CPU.

>It is true that the C/C++ macro processor is pretty dumb compared to
>the HLASM macro language. And yet that doesn't seem to be much of a
>limitation if any. The programming models are just different.

Well.like all good questions, "it depends". We hit limitations with the macro preprocessor pretty often, in part because our code is multi-platform, so we have lots of multipathing for which #if and friends just don't suffice. I'll admit that it probably doesn't help that I'm an assembler guy and thus immediately think "Gee, this would be trivial with an assembler macro". Sometimes there are ways to do it with the macro preprocessor; sometimes I'm told "You just can't do that". And in those cases, I'm assuming that the folks telling me that know what they're on about. Which, of course, might be wrong!

...phsiii

[Ian Worthington]

> Indeed! And the generated code between opt(0) and opt(3) is so different, it's hard to believe it's doing the same thing, yet it is. It's impressive as hell. In the one compute-intensive case that we measured, unoptimized used half again as much CPU.

In fact it convinced me that we should probably not be coding assembler language by hand as we have to write for comprehension and maintainability, not efficiency.

Best wishes / Mejores deseos /  Meilleurs vœux

Ian ...

[Seymour J Metz]

For half a century there have been compilers that generated highly optimized code for, e.g, FORTRAN. The problem with C is not the way the compiler optimizes, but rather the semantic repertoire.

________________________________________
From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> on behalf of Chris Craddock <cras...@HOTMAIL.COM>
Sent: Wednesday, July 19, 2023 11:24 AM
To: ASSEMBL...@LISTSERV.UGA.EDU

Subject: Re: looking for limbo languages - how low can you go?

Hi Jon,

[zMan]

You mean Paul Gilmartin...and yes, in gmail I somehow responded to wrong
note, probably by hitting Reply at the bottom instead of by the actual note
in question! Sorry for confusion.

[Chris Craddock]

Hi Phil,

wrt: "We hit limitations with the macro preprocessor pretty often, in part because our code is multi-platform, so we have lots of multipathing for which #if and friends just don't suffice. I'll admit that it probably doesn't help that I'm an assembler guy and thus immediately think "Gee, this would be trivial with an assembler macro"."

I too am "an assembler guy", but I was writing C in the late 70's, long before I wrote my first 370 asm program. I wrote the new product on my Mac so I could use a good IDE - JetBrains CLion. This forced me to use some boilerplate like this ...

#define plist_id 0x40e3d7d3 // " TPL"
// calling Assembly programs from C++ is a PITA in IBM's C++. The code
// below expands correctly on the mainframe and the IDE doesn't whine
#ifdef __IBMCPP__
#pragma map(doAuthCall,"TAAGOAPF")
extern "OS" { int doAuthCall(parm_array *); }
#else
extern "C" { int doAuthCall(parm_array *); }
#endif

but really not that much. I really did not need or use much of the C/C++ macro preprocessor. Wherever I needed to use assembler, the C++ code would just call the assembler program, which had LE entry and exit macros. From there I could do anything I needed (issue PC calls etc.)

As the comment implies, this allowed the IDE to properly validate data types, parameter lists etc. and, quite frankly, it was a life saver. I knew before I even compiled the code on z/OS that it was syntactically valid. The rest was just making sure it did what I wanted and for that, I used Dave Cole's c/XDC. As usual, I can't say enough good things about Cole Software.

If I was doing more z systems software development, I would be sorely tempted to reuse this approach. Worked like a charm.

CC
________________________________
From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> on behalf of Phil Smith III <li...@AKPHS.COM>
Sent: Wednesday, July 19, 2023 4:38 PM
To: ASSEMBL...@LISTSERV.UGA.EDU <ASSEMBL...@LISTSERV.UGA.EDU>

Subject: Re: looking for limbo languages - how low can you go?

[David Cole]

Chris Craddock wrote:

> The rest was just making sure it did what I wanted and for that, I
used Dave Cole's c/XDC.
> As usual, I can't say enough good things about Cole Software.

Thanks for the shout out, Chris. Always Appreciated.

Dave
dbc...@gmail.com (personal)
dbc...@colesoft.com (business)
540-456-6518 (cell)




At 7/20/2023 10:57 AM, Chris Craddock wrote:
>Hi Phil,
>wrt: "We hit limitations with the macro preprocessor pretty often,

>in part because our code is multi-platform, so we have lots of
>multipathing for which #if and friends just don't suffice. I'll
>admit that it probably doesn't help that I'm an assembler guy and
>thus immediately think "Gee, this would be trivial with an assembler macro"."