Dave Cole noted on Monday, March 18, 2013 2:34 PM re:
At 3/18/2013 11:18 AM, Andreas F. Geissbuehler wrote:
- IBM opcodes will remain [A-Z]
H... TRAP2 and TRAP4 come to mind.
Schwarz, Barry asked on Tuesday, March 19, 2013 2:42 PM re:
My 2 bits:
- IBM opcodes will remain [A-Z]
Did you
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-
l...@listserv.uga.edu] On Behalf Of Andreas F. Geissbuehler
Sent: Monday, March 18, 2013 8:19 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Extended Mnemonics After Unsigned Arithmetic
Snip
My 2 bits
At 3/18/2013 11:18 AM, Andreas F. Geissbuehler wrote:
- IBM opcodes will remain [A-Z]
H... TRAP2 and TRAP4 come to mind.
Dave Cole REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow RoadVOICE:540-456-8536
Afton, VA
And even if this stricture had not already been violated, it was ripe,
even overripe, for violation. Ad hoc notions of this kind are
worthless.
The .MAC and .ASM syntax, on the other hand, . . .
John Gilmore, Ashland, MA 01721 - USA
On Mar 19, 2013, at 12:42, EXT-Schwarz, Barry wrote:
My 2 bits:
- IBM opcodes will remain [A-Z]
Did you mean first letter or entire name? Many macro names contain digits
and at least one contains lower case letters.
Macros perhaps. Opcodes, no. Does HLASM enforce the latter?
Does HLASM
On Mar 18, 2013, at 08:03, John Gilmore wrote:
All is not, however, lost. There is nothing to prevent anyone who
needs them from packaging up a set or sets of OPSYNs that introduce
the extended mnemonics he or she wants/needs.
A prudent ISV would avoid this technique in distributed
source
On 3/18/13, Paul Gilmartin paulgboul...@aim.com wrote:
On Mar 18, 2013, at 08:03, John Gilmore wrote:
All is not, however, lost. There is nothing to prevent anyone who
needs them from packaging up a set or sets of OPSYNs that introduce
the extended mnemonics he or she wants/needs.
A
On Mon, 18 Mar 2013 12:37:04 +0200, wrote:
Wasn't there an IBM warning that user macros should be greater than five
characters since all opcodes were to be five characters or less, and thus this
problem would be avoided?
Maybe so, but there have been six character mnemonics for quite a while.
Ref: Your note of Mon, 18 Mar 2013 09:03:18 -0500
I agree that management of the opcode name space is difficult,
and I've been looking at ways to improve it from long before I
joined the HLASM team. The mnemonic suffix system with :ASM or
:MAC helps a bit, but I think systematic use of OPSYN
Paul Gilmartinäs response to Binyamin Dissen:
Wasn't there an IBM warning that user macros should be greater than five
characters since all opcodes were to be five characters or less, and thus
this
problem would be avoided?
Right.
Thusfar I often inclued a $ # @ in my 'cute' (=short) macro
I cheat horribly. I put my personal HLASM macros in a UNIX directory. HLASM
accepts the _ character as a valid alphanumeric. ISPF doesn't for member
names in a PDS, but will for a UNIX file name. So I name my personal macros
such that they are all 8 or fewer characters; upper case alphabetic,
Alex Kodat noted:
... depends on one's view of the assembler. If the view is that it's gone
about as fer as it can go ...
Oh, there's lots more we'd love to do, had we but world enough, and time.
8-)
John Ehrman
Paul Gilmartin noted:
Isn't there lately a construct that explicitly invokes a macro rather than
an opcode? There should be.
There is indeed! Suffix ':MAC' or ':ASM' as appropriate, as in 'MSG:MAC'
and 'MSG:ASM'.
John Ehrman
I think a SHARE requirement would be a useful start to discussing
additional extended mnemonics. I'd follow that up with a HLASM RFE
request.
I must admit to being somewhat bewildered as to what prompted Ed to initiate
this discussion at all. As John E intimated, I reckon this cat has well
Ed,
I think a SHARE requirement would be a useful start to discussing
additional extended mnemonics. I'd follow that up with a HLASM RFE
request.
How do we start the SHARE requirement ? and would you expect to discuss
this at Boston or before ?
Sharuff
Sharuff Morsa
HLASM IBM Hursley
Unless
On 3/15/2013 4:39 PM, robin wrote:
(It's the reason that 32K is
a limit in so many places in z/OS e.g., block sizes, number of ASIDs,
etc.)
No it's not. It's the result of using the halfword instructions such
as LH, AH, SH, etc
which automatically sign-extend to 32 bits. (Incidentally, the
In the original S/360, nearly all instructions that manipulated binary
integers treated them as signed quantities. (It's the reason that 32K is
a limit in so many places in z/OS e.g., block sizes, number of ASIDs,
etc.) The assembler has a robust implementation of extended mnemonics to
be used
On 3/15/2013 10:36 AM, Paul Gilmartin wrote:
On Mar 15, 2013, at 11:27, Ed Jaffe wrote:
... There is now logical load, ...
How does Logical Load differ from Illogical load? I might
expect a difference, however, for Logical Load and Test.
Example: LGF extends the sign bit through the high
On 3/15/2013 10:43 AM, John Ehrman wrote:
One reason for the Assembler's not having implemented a fuller set of
extended branch mnemonics is that once the original (incomplete) set
wasprovided, many users implemented their own macro-based extensions.
Given the decades-long lack of a mechanism
From: Ed Jaffe edja...@phoenixsoftware.com
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Sent: Friday, March 15, 2013 1:30:54 PM
Subject: Re: Extended Mnemonics After Unsigned Arithmetic
Many developers might have already done this only to have it
all stop working when the assembler added JLO to mean
On 3/15/2013 10:27 AM, Ed Jaffe wrote:
Has anyone thought this through already and come up with what the
mnemonics should be?
I'm noticing that the most often used mnemonics after subtract seem to
be JP and JNP. For example:
L Rx,y
S Rx,z
JPlabel1 jump if processing
On 15 March 2013 14:30, Ed Jaffe edja...@phoenixsoftware.com wrote:
It seems to me the most obvious choice for logical extended mnemonics
would have been to insert the letter 'L' as in Jxxx - JLxxx. Had I
written these macros years ago, I might have created (for example) JLO
to branch on
From: Ed Jaffe edja...@phoenixsoftware.com
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Sent: Saturday, 16 March 2013 4:27 AM
In the original S/360, nearly all instructions that manipulated binary
integers treated them as signed quantities.
AL, SL, ALR, SLR come to mind.
These were intended to
23 matches
Mail list logo
