I have a DSECT where I want to define a fullword such that the next address
after the fullword will be on a doubleword boundary. I would like the
alignment to be independent of the preceding alignment (be change-proof).
CNOP 4,8 would do exactly what I want, but CNOP seems inappropriate in
non-exe
If I mess it up let me know and I'll pull one tomorrow from a listing.
IIRC something like org (*+7)/8 will do it.
Sent from my iPad
> On Nov 27, 2016, at 8:14 PM, Charles Mills wrote:
>
> I have a DSECT where I want to define a fullword such that the next
> address after
.
More like org csect + (((*-csect)+7)/8)
If that's not it I'll pull one tomorrow.
We use it to round stuff up to page boundaries all over.
Sent from my iPad
> On Nov 27, 2016, at 8:31 PM, Charles Mills wrote:
>
> Yeah, I have done this in the past somehow with that kind of
&
Thanks all. I don't find any of the solutions totally obvious ("intuitive,"
simple to grasp) but I do have to agree with @Gil that "taking it one step
at a time" with a series of DS's comes closer to obvious.
I took Gil's solution and commented it with the potential offsets relative
to 8 of the lo
Noo!
What do a senior z/OS developer and I have in common? We both got our butts
bitten by this!
LLILF: "The second operand is placed in bit positions of the first operand. The
remainder of the first operand is set to zeros."
Charles
-Original Message-
From: IBM Mainfr
Depending on how complex the generated data is it might be possible to
generate it as a literal. The location of literal data is always somewhat
separate from machine instructions and easy to control with LTORG and LOCTR.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mail
And of course the traditional solution to this problem is MF=E/MF=L variants
of the macro.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Charles Mills
Sent: Friday, January 13, 2017 9:18 AM
To: ASSEMBLER-LIST
Absolutely.
That is standard for LE non-XPLINK linkage. You tell LE at the entry point
how much "extra" R13 storage you need. (I of course do it with a calculated
EQU.) Gives you stack-type storage for assembler just like in C and so
forth. Would make it easy, for example, to write an assembler ro
You are generating a WTO MF=L inline? You have your macro, and as part of
its expansion, it generates both a WTO MF=L and a WTO MF=E, all in-line?
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Peter Hunkeler
Sent: Sunda
Yeah, I whined on IBM-MAIN on Dec. 27 about not being able to use a relocatable
address in LLILF. Same answer. It does not work because ... it does not work.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Steve Smith
S
> Replication would then expand outside of the instruction and into the
> instruction stream
Not necessarily. AHI R1,2X'FF', were it valid, would presumably generate
exactly the same machine code as the valid AHI R1,X''. One could, for
example, write a series of macros (with names for examp
Another way of looking at things is that X' serves two different roles in the
assembler syntax. I became aware of this when I moved from a long career
writing assembler to C++ as my primary language.
X' signifies (a.) that the constant that follows is in hexadecimal notation and
(b.) a unit of
> > Take for example, AHI R1,2X'FF'. What does that even *mean*? If it
It is perhaps a silly example. But suppose R1 was to contain a pair of flag
byte values. Suppose the flags were equated. Now it might make sense to code
LHI R1,2AL1(MYFLAG1)
Or something like that. Yes you can code the foll
You can hypothesize objections to my hypothetical example. The example is
nonetheless instructive: there are situations where it would be clearer to
express the immediate operand of AHI or LHI as two bytes, not as a single
expression. Is it the most important shortcoming facing the mainframe? Of
co
For sure! It's not a problem I lose sleep over -- perhaps because my primary
language is now C++, no longer assembler.
I don't recall ever thinking about the issue until it came up on this list.
I'm a "design elegance" guy. It would please me if there were a single
expression processor such that
How would anyone know from your e-mail what "this" is?
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of John Walker
Sent: Wednesday, March 1, 2017 11:06 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: ASSEMBLER-LIST
> Should/does HLASM require that the target of BR is within the owning
CSECT?
No and no. (Or should I say "No/no"?)
1. No, the target of a BR is quite often in another CSECT, and quite happily
so: L R15,=V(some_entry_point)/BR R15 or LM R14,R12,12(R13)/BR R14
2. No, it is not something the assem
I *considered* it for a problem of updating a queue in a multiprocessor
reentrance situation. I ended up solving the problem with CSST which seemed
like a simpler approach.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf
Hardware address arithmetic has always allowed overflow, right?
I could load X'FFF0' into R1, do L R2,32(,R1) and get the CVT, right?
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Jonathan Scott
Sent: Monday, March
DU
Subject: Re: HLASM anomaly
On 2017-03-06, at 09:18, Charles Mills wrote:
> Hardware address arithmetic has always allowed overflow, right?
>
> I could load X'FFF0' into R1, do L R2,32(,R1) and get the CVT, right?
>
Not in AMODE 64. The example I gave was (slightly ad
X'0010'.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Monday, March 6, 2017 9:11 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: HLASM anomaly
On 2017-03-06, at 10:01, Charles M
Agreed.
Option to keep backward compatibility where deemed advisable.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Gary Weinhold
Sent: Friday, March 10, 2017 11:10 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re:
Yes, DOS-style code. DOS did not load R15 with the entry point, or at least was
not documented to do so. Also you should see no STM at the beginning: DOS gave
you your own registers. End-of -program was by SVC, not BR R14. (The EOJ macro
if memory serves.)
DOS used "core image" executable libra
The DOS assembler supported macros and SET symbols.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Rob van der Heij
Sent: Saturday, March 11, 2017 7:00 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: 50 year old as
Without having taken the time to parse every detail below I think I agree with
@Martin.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Martin Ward
Sent: Friday, March 17, 2017 3:45 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.E
I am heads down on a customer problem so cannot write a tutorial but I think
LOCTR might well be able to do what you want.
LOCTR will let you break the CSECT into pieces that are not necessarily in
the CSECT in the physical order of the instructions in the source. Let you
code stuff "now" that wil
If you wanted to load two equated flag values, FOO and BAR, into the two bytes
of the immediate operand of an LHI, how would you code it?
LHI 0,(FOO*256)+BAR?
The assertion here is that LHI 0,AL1(FOO,BAR) would be more readable.
Charles
-Original Message-
From: IBM Mainfra
I fail to see how making the two similar constant parsers more identical is an
obscene parody of some other language.
FWIW, I am not a young-un. I am competent in assembler -- my first professional
language -- and now quite competent in C++. I am not a religious bigot. Each
language has its pla
Apologies for the late reply. Outlook thought this was SPAM.
Warnings are not much better or different than errors. It sounds great to
say "issue a warning" but the fact is that then the programmer has to either
(a.) live with and ignore RC=4 for the life of the project; of (b.) change
the code. I
Different PTFs
CharlesSent from a mobile; please excuse the brevity.
Original message From: Peter Relson Date:
3/25/17 11:16 AM (GMT-08:00) To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re:
HLASM "Anomaly"
My "favorite" is the warning you get when the target of your
JAS/B
ORG *+3, DS XL3 or DS 3X seem good to me, FWIW. I don't perceive future ORG
problems, but I could be missing something.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of somitcw
Sent: Wednesday, April 5, 2017 11:49 AM
To
, 5 Apr 2017 12:14:38 -0400, Charles Mills posted:
> ORG *+3, DS XL3 or DS 3X seem good to me, FWIW. I don't perceive
>future ORG problems, but I could be missing something.
> Charles
Thanks.
DS would cause a strange issue to me.
You don't want to know.
If no one can recommen
17 13:26:51 -0400, Charles Mills posted:
> ORG , could produce other than the desired result.
> Charles
Yes, that is the question.
How could either "ORG *-4", "ORG *+3", or "ORG ," cause undesirable results?
ORG *-4
DC XL1'E3'
ORG *+3
or
ORG
Is this routine run millions of times? Is performance important? If so
LAR4,THATCLOK Address save area
LGGR7,0(R4)Load address into 64 bit register
is doing things the hard way. Why not just LG GR7,THATCLOK? Same for E1970,
MILL16 and THISCLOK.
If you are going to
y, April 20, 2017 3:56 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: CONVTOD Help
On 2017-04-20, at 14:14, Charles Mills wrote:
> Is this routine run millions of times? Is performance important? If so
>
> LAR4,THATCLOK Address save area
> LGGR7,0(R4)
ISTSERV.UGA.EDU
Subject: Re: CONVTOD Help
On 2017-04-20, at 17:22, Charles Mills wrote:
> Not sure what your question is?
>
> - Does using index registers as opposed to base registers hurt
performance?
> Maybe. Who knows anymore. "It depends." They don't help. They also a
> If you need a way to ABEND, use the proper LE service, or an assembler
routine. Anything else will bite you sooner or later.
AMEN!
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Peter Hunkeler
Sent: Thursday, May 11,
ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Thursday, May 11, 2017 10:13 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Performance of Decimal Floating Point Instruction
On 2017-05-11, at 06:34, Charles Mills wrote:
>> If you need a way to ABEND, use the proper LE service,
ating Point Instruction
Many years ago I knew a guy who would terminare programs by EX *
Sent from Yahoo Mail on Android
<https://overview.mail.yahoo.com/mobile/?.src=Android>
On Thu, May 11, 2017 at 1:18 PM, Charles Mills
wrote:
DC H'0' *is* an assembler routine!
It
y 11, 2017 10:24 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Performance of Decimal Floating Point Instruction
On Thu, May 11, 2017 at 12:12 PM, Paul Gilmartin <
00000014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
> On 2017-05-11, at 06:34, Charles Mills wrote:
>
> >> I
: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Performance of Decimal Floating Point Instruction
On Thu, May 11, 2017 at 12:32 PM, Charles Mills wrote:
> And one of these days the architecture starts allowing EX of an EX and
> it fails the bite test.
>
I really doubt that IBM would ma
to:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of John McKown
Sent: Thursday, May 11, 2017 1:52 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Performance of Decimal Floating Point Instruction
On Thu, May 11, 2017 at 12:32 PM, Charles Mills wrote:
> And one of these days the architecture starts
at 1:28 PM, Charles Mills wrote:
> Absent EX how do you do a variable length PACK or MVO or ...
>
I said that I didn't _like_ EX. Not that I didn't _use_ it. I'd prefer to
"synthesize" an instruction into a 64 bit GPR and then "EX" the contents of
the G
rsday, May 11, 2017 12:36 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Quick error termination of an assembler routine (Was: Performance
of Decimal Floating Point Instruction)
On Thu, 11 May 2017 10:44:25 -0700, Charles Mills wrote:
>What is *wrong* with DC H'0'? It has
Well, in reality you are right of course (who cares about the i-cache?) but
in theory one is branching around and NOT crashing, so not wasting the
i-cache is a desirable goal.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behal
That's what makes the JNx *+2 technique kind of cool. It is both "branch on
error" and simultaneously "in line."
My "who cares about the i-cache" was premised on my earlier assertion that
S0C1'ing is appropriate only for quick testing and so forth, not as a
"production" technique.
Charles
-
I've wondered the same thing. Does it make sense to use two branches where
one would do, to make the conditional branch the unlikely path?
> And next year's model may negate the effort with something such as JIT
analysis.
I think even last year's model is more sophisticated than simply "always
as
Create an Excel spreadsheet. In A1 put 1. In A2 put 2. Drag the two cells
down to row 9. You now have all the numbers from 1 to 9 with no
duplicates.
Put =RAND() in B1. Drag it down to row 9. You now have 99,999
pseudo-random numbers in column B. Sort the spreadsheet on column B. Colum
That is my recollection.
Are you using ASA control? Can you begin the line with a ! (new page) or 0
(double space)?
There is an equivalent for M control.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Tony Thigpen
S
That should be an EBCDIC '1' (one) for new page. Sorry - hit the shift key by
mistake.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Charles Mills
Sent: Thursday, May 25, 2017 11:15 AM
To: ASSE
I don't know the answer to your question but I share your general
consternation. This used to be so simple: program, task or subroutine, on entry
STM and chain.
I've spent enough time on it to think there is no good general answer. I could
be/hope I am wrong.
Charles
-Original Message---
31-bit C can use non-standard (whatever that means) XPLINK linkage.
64-bit C only uses XPLINK.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Swarbrick, Frank
Sent: Friday, June 9, 2017 8:54 AM
To: ASSEMBLER-LIST@LIST
Behalf Of Tom Marchant
Sent: Friday, June 9, 2017 11:38 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Save areas (not XPLINK).
On Fri, 9 Jun 2017 08:59:02 -0700, Charles Mills wrote:
>31-bit C can use non-standard (whatever that means) XPLINK linkage.
Standard linkage uses register 1
Friday, June 9, 2017 1:23 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Save areas (not XPLINK).
On Fri, 9 Jun 2017 11:50:39 -0700, Charles Mills wrote:
>I know what XPLINK means. Is XPLINK a standard? Then is XPLINK linkage
>non-standard? That was my "whatever that means.&
I have been out of the office and half-following this thread on my phone. If it
were I, I think I would do the most straightforward thing:
LOOP EQU *
CLI MASK.FIELD1,'*'
JE Wild1
CLC MASK.FIELD1,TABLE.FIELD1
JNE LOOPX
Wild1 EQU *
CLI MASK.FIELD2,'*'
Etc.
Makes sense, I think.
I would guess that about 10,000 programmers and/or shops (literally) have done
their own.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of John McKown
Sent: Thursday, July 20, 2017 11:52 AM
To: AS
Two sets of registers would change the whole architecture. I'm sure as the
gurus of the hardware sat around 20 (?) years ago pondering how to deal with
64-bit as the architecture went forward, certainly two separate sets of
registers crossed their whiteboards.
But I really like your "USING" ide
In other words, EXECUTABLE=YES is not some new RMODE=64 feature.
EXECUTABLE=NO is a new security feature. It is a guard against buffer overflow
type vulnerabilities in which a bad guy sends you some message (like a Web URL)
that is actually machine instructions and also manages to overlay code t
-LIST@LISTSERV.UGA.EDU] On
Behalf Of Charles Mills
Sent: Friday, July 28, 2017 12:07
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: LOC=64 executable code?
In other words, EXECUTABLE=YES is not some new RMODE=64 feature.
EXECUTABLE=NO is a new security feature. It is a guard against buffer overflow
It's not unlike virtual memory. Virtual memory acts like real memory but it
is actually a software fiction. But eventually, a word in virtual storage is
sitting in physical real memory when you reference it. (Yes, yes, backing
stores and cache, oh my -- but my fundamental point is valid.) So with a
>From the application's point of view -- and you must take this into
consideration in designing a multi-task application -- all tasks (TCBs) may
run "at the same time" even though there are more tasks than CPUs. If a task
loads a word, adds one to it, and stores it back, you have to consider that
a
RV.UGA.EDU
Subject: Re: Question about CPUs
Charles Mills wrote, in part:
>The effect of multiple CPUs on a multi-task program is even worse than
>the load, add, store example above. With two CPUs, it is possible for
>even single machine instructions to interleave. So if one task executes
>
BLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Sunday, July 30, 2017 11:01 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Question about CPUs
On 2017-07-30, at 22:57, Charles Mills wrote:
> Nay. Many, many instructions are not atomic. On a single CPU, yes. For
> multiple CPUs,
People are confusing single processors with multiple processors.
On a single processor, almost all instructions are atomic. The exceptions are
the obvious ones like MVCL, which are obviously designed to take an interrupt
and resume. Yes, all interruptions are at an instruction boundary, and the
Nope. I give up. You are of course free to believe whatever you wish. Just
please do not write any kernel code.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Keven Hall
Sent: Monday, July 31, 2017 8:51 PM
To: ASSEMBLER
.
Keven
> On Jul 31, 2017, at 23:18, Charles Mills wrote:
>
> Nope. I give up. You are of course free to believe whatever you wish.
> Just please do not write any kernel code.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Assembler
I worked on some micro or mini architectures where they solved this by having
an instruction "disable interrupts for the next two or three instructions."
Effectively let you group any two or three instructions together as atomic. (On
a uni-processor.)
Charles
-Original Message-
From:
Peter, would you care to share your opinion of CSST?
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Peter Relson
Sent: Friday, August 11, 2017 7:24 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: PLO
does anyone k
Let me volunteer to be the dumb one here.
> Note that use of transactional processing is inherently dual path.
> You would still need the "other" path even if every machine in the world
> already supported TBEGIN.
Why?
Charles
-Original Message-
From: IBM Mainframe Assembler List [mai
? Anyone?
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Ed Jaffe
Sent: Saturday, August 12, 2017 5:54 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: PLO
On 8/12/2017 2:20 PM, Charles Mills wrote:
> Let
And keep in mind that they use different locking mechanisms. If routine A
uses CS and routine B uses PLO to protect a given field, then they will not
lock each other out and you will potentially have collision problems.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailt
is not possible?
Thanks,
Charles Mills
stone
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Charles Mills
Sent: Thursday, 17 August 2017 11:01 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Source address significance for clearing MVCL
I don't see this explicitly in the P
Ref: Your note of 17 August 2017, 09:00:52 EDT
It is there in the book (SA22-7832-09, second sentence in the last paragraph
before the Resulting Condition Code heading):
When the length of an operand is zero, no access exceptions for that
operand are recognized.
Charles Mills wrote:
> I do
ce address significance for clearing MVCL
From: "Charles Mills"
Sent: Friday, August 18, 2017 12:33 AM
> Address 0 is a legal fetch address.
>
> The question is can I get away with not worrying about what is in the
> source address register? What, for example, if it points to
I am clearing the area to X'00' so the usual suspects (SR, XR, SLR, LHI) each
do it in one instruction.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Steve Smith
Sent: Thursday, August 17, 2017 12:04 PM
To: ASSEMBLER
Second 4K *page*
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Wayne Driscoll
Sent: Thursday, August 17, 2017 12:59 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Source address significance for clearing MVCL
Ad
I am writing a macro that I want to be parametrized by the MACHINE level:
generate one thing if MACHINE greater than or equal to ZS-6 and another
thing if less.
I can compare &SYSOPT_OPTABLE to 'ZS6' and jump if GE. But I would guess
that one of these days there will be a ZS-9 and then a ZS-10
Thanks @Jonathan and @Steve. I can make that work.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Jonathan Scott
Sent: Friday, September 29, 2017 5:16 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Determining MACH
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Charles Mills
Sent: Friday, September 29, 2017 8:09 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Determining MACHINE level in a macro
I am writing a macro that I want to be parametrized by the MACHINE l
Thanks. Very nice!
FWIW I am testing for support for "Fast Serialize" so this sort of approach
won't work.
It's a nasty situation because an LGFI, for example, on a back-level machine,
will produce a S0C1, but a fast serialize on a back-level machine will simply
fail silently.
Charles
-
Yeah, the architecture should have been to S0C6 if the bits were non-zero.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Steve Smith
Sent: Wednesday, October 11, 2017 2:19 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subjec
And I suspect "it depends."
Are the operands already in cache? Must the processor do a read-to-write switch
on a cache line? What instructions came before? What come after? What is the
preceding and succeeding usage of the register? What is the impact on the
i-cache of 8 bytes versus 6?
Me, I
expensive. Bugs are very expensive.
3. We don't know that MVC is any slower than IC/STC, and I can think of two
reasons that it might be faster (less i-cache, no register contention).
Charles
-Original Message-
From: Charles Mills [mailto:charl...@mcn.org]
Sent: Monday, Octob
Agreed.
"Compilers are more efficient than hand-coding assembler" is counter to what
we learned as newbies but is now true.
Sometimes, however, "is X faster than Y?" is an amusing exercise.
And certainly one can argue, as I did on the original thread here, that X is
*better* (not necessarily fas
So
ASCII_Left_Brace EQU A'['
MVI TARGET,ASCII_Left_Brace
does not work either?
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Tuesday, October 17, 2017 9:53 AM
To: ASSEMBLER-LIST@LISTSE
I guess not. I guess A is only allowed as a C "type extension" on a DC or
DS.
Sigh.
Not sure the problem is EBCDIC. Sounds like the problem is the assembler.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf
Jonathan -
If you have a free single letter you could use it for an ASCII character
constant. Rather than CA'X', just A'X'. Or some other letter of your choice.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Jonathan S
@Gil, I don't know if this was a "real problem" or just general venting
about EBCDIC and the HLASM, but it would seem to me like a good approach
would be the one-time effort to define a copy member with 256 statements
something like
ASCII_NUL EQU 0
ASCII_SOH EQU 1
...
ASCII_Space
I'm with you on the "outsourcing" to Unicode services. It's what I do in "my"
product. As you say, leave it to the experts.
I'm not with you on the one characters to two. It's assembler, man, it's not an
HLL (despite the name!). It's supposed to be 1:1 with what the developer codes,
not "solve
I am responsible for a product that uses Unicode Services to do a *lot* of
translation, typically EBCDIC to UTF-8, which is non-trivial. I measured the
overhead. I was pleasantly surprised.
On a z13s, with an optimized C++ compile, the total CPU time to translate 4016
records with an average le
Unfortunately, a lot of the high half instructions come along (not
surprisingly) with the "high-word facility" which is z196 and above. I've never
used it, but Add Immediate High (AIH) looks like what you are looking for --
but it's high-word facility.
How about the floating point registers? Co
Well, depending on his exact logic, quite possibly yes.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Robin Vowels
Sent: Friday, October 27, 2017 6:26 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Using the High
I believe those are all z Architecture instructions and should work on any z
Architecture machine.
NIHF might be your best bet for clearing the high half of a register: no
storage access. Requires the extended-immediate facility, available on a z9.
You could avoid the storage references on the
. IIRC the Assembler Services Guide has save area formats.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Charles Mills
Sent: Saturday, October 28, 2017 10:03 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Using the
EDMK is used when you want a "floating" (just before the first significant
digit) dollar sign or similar. You back up R1 by 1 and that is where your
dollar sign goes.
I think there are ED and EDMK examples in the PoOp, no? Read them carefully.
Read them very carefully. ED and EDMK are powerful
I believe the fill character may be any character whatsoever.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Robin Vowels
Sent: Thursday, November 2, 2017 6:49 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: edmk in
You must have mucked up something else. Either will "work" (in the sense that
they will fill the output, although x'00' is not printable; you want x'F0').
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Gray Gregory
Se
Very cool!
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Jonathan Scott
Sent: Thursday, November 2, 2017 7:22 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: ASCII self-defining constants
Ref: Your note of Thu, 1
> But perhaps the proper RFE would be for DfSMS to extend the applicability
of the CCSID parameter of the DD statement
Far be it from me to tell another company how to design their products -- I
have enough trouble with my own -- but it would just seem like an almost
no-brainer enhancement to z/OS
1 - 100 of 577 matches
Mail list logo
