From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu>
Sent: Wednesday, April 20, 2022 10:32 AM
C programmers don't give a damn about overflows. An unfortunate consequence,
probably, of hardware architectures which, unlike 360, lack unsigned
instructions, forcing compilers to
On 2022-04-20 20:05, Thomas David Rivers wrote:
That's a great explanation Thomas.
I'm curious though:Â how come both compilers produce this
same sequence of instructions? I'd have thought it was a
rather obscure combination. Is it perhaps more common
than I'd suspected, or do GCC and
Thanks, John, Good information as always.
I asked Frank Chu to open the support case. He did so about an hour ago.
Dave
At 4/20/2022 03:48 PM, Jonathan Scott wrote:
Ref: Your note of Wed, 20 Apr 2022 15:41:44 -0400
Dave Cole writes:
> Here is the snippet from an assembly listing...
>
On Wed, 20 Apr 2022 at 13:03, Charles Mills wrote:
> > USING *,16
> I was wondering about R16. Would come in handy.
Maybe on the z16...?
[There was an old PL/I Optimizer APAR (1980ish?) complaining that a
new compiler release could not generate code for certain large source
modules that had
Ref: Your note of Wed, 20 Apr 2022 15:41:44 -0400
Dave Cole writes:
> Here is the snippet from an assembly listing...
> 93657+ENDCMDS DS0D,F
> 93658+DXDCMDS DXD (ENDCMDS+8-TFSCMDS)X
> ** ASMA500W Requested alignment exceeds section alignment
Any case where the DXD has
Hi John,
Thanks for your comments. They're helpful.
My actual case is similar to your example, but is not quite the same.
Below is a snippet from the listing.
I am using DXDs to record the length of a csect. It occurs at the end
of the assembly, and it assigns a duplication factor to a
I was wondering about R16. Would come in handy.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Steve Smith
Sent: Wednesday, April 20, 2022 9:31 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Quadword constant
Sheesh. Sorry, I meant ORG *,16.
On Wed, Apr 20, 2022 at 12:30 PM Steve Smith wrote:
> That's the old-fashioned way. This is the new way:
>
> USING *,16
>
> There are some caveats. For CSECTs, HLASM will complain if SECALGN is
> insufficient. For DSECTs, it's your responsibility to ensure
That's the old-fashioned way. This is the new way:
USING *,16
There are some caveats. For CSECTs, HLASM will complain if SECALGN is
insufficient. For DSECTs, it's your responsibility to ensure the alignment
matches (if it's real important). Fortunately, STORAGE has a corresponding
alignment
>doesn't current z model have a specific Unsigned Multiply instruction?<
ML, MLR, MLG, and MLGR called "Multiply Logical" are unsigned with no cc change
since overflow does not occur with 64 and 128 bit results.
Don Higgins
d...@higgins.net
www.don-higgins.net
-Original Message-
From:
On Apr 20, 2022, at 07:46:49, Ian Worthington wrote:
>
> Whilst looking at reliable techniques to detect signed and unsigned overflow
> in integer multiplication I was checking out the late John Erhman's
> "Assembler Language Programming for IBM System z™ Servers" in which I
> discovered he
Ed;
Of course, what you said about the LQ type of DC is true, and I too
have used LQ data types in some of my code too. However, the
SECTALGN requirement is a bit of an issue when assembling code with
2**3 (double word) section alignment and which also contains DSECTs
which map quad word
On 2022-04-21 00:19, Seymour J Metz wrote:
That has at least two bugs: the first test will incorrectly treat 1*-1
The task is to form the product of two POSITIVE integers.
as having an overflow and the second test is testing all of R0,
The second test must test R1, as shown, not R0.
not
The first case is ruled "out of scope" by the wording of the question wherein
both inputs are deemed to be positive. (Though I think that makes it a bit of
a hokey example).
Best wishes / Mejores deseos / Meilleurs vœux
Ian ...
On Wednesday, April 20, 2022, 04:19:32 PM GMT+2, Seymour
On 2022-04-20 23:46, Ian Worthington wrote:
Whilst looking at reliable techniques to detect signed and unsigned
overflow in integer multiplication I was checking out the late John
Erhman's "Assembler Language Programming for IBM System z™ Servers" in
which I discovered he presented this problem
That has at least two bugs: the first test will incorrectly treat 1*-1 as
having an overflow and the second test is testing all of R0, not just the high
bit.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List
Whilst looking at reliable techniques to detect signed and unsigned overflow in
integer multiplication I was checking out the late John Erhman's "Assembler
Language Programming for IBM System z™ Servers" in which I discovered he
presented this problem and solution:
18.2.13.(2)+ A programmer
Yes, but I know of no way to define a quadword binary fixed point integer
constant in the current HLASM.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Ed Jaffe
Dave Cole, please raise a support case for this.
APAR PH40885 exposed a bug when the duplication factor on a DXD
involves a forward reference, for example:
DXD1 DXD (A)X
AEQU 3
The problem is that if a DXD definition has to be deferred
because it cannot be resolved immediately,
>
> That's a great explanation Thomas.
> I'm curious though:Â how come both compilers produce this
> same sequence of instructions? I'd have thought it was a
> rather obscure combination. Is it perhaps more common
> than I'd suspected, or do GCC and Dignus have some common heritage
> in the
Many thanks, comments below ...
Am 20.04.2022 um 04:17 schrieb Thomas David Rivers:
The "secret" is in the operation of the LPR and LCR
instructions for the 2's complement maximum negative
value (X'8000'): These notes in the Principles of
Operation give a hint:
LPR:
An overflow
That's a great explanation Thomas.
I'm curious though: how come both compilers produce this same sequence of
instructions? I'd have thought it was a rather obscure combination. Is it
perhaps more common than I'd suspected, or do GCC and Dignus have some common
heritage in the back end?
> C programmers don't give a damn about overflows. An unfortunate consequence,
> probably, of hardware architectures which, unlike 360, lack unsigned
> instructions, forcing compilers to generate signed instructions for
> unsigned operations.
I've spent more of the last week finding out more
> ccpm and carrybit are probably ints or unsigned ints,
> because of the L and N instructions, which read them.
> The final STC moves the rightmost 8 bits to the bool variable;
> bool (no C standard type) is probably a typedef which means char.
> I hope, I understood the coding correctly.
Indeed.
24 matches
Mail list logo
