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
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
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
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
> -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 Arithm
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
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
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,
numer
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 na
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 and
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.
On 3/18/13, Paul Gilmartin 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 prudent ISV wou
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
sourc
Shane and John Ehrman have made the crucial point. It is just too
late for EJ's initiative.
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.
Municipal sets of these
On Mar 18, 2013, at 04:37, Binyamin Dissen 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?
>
Right.
> On Sun, 17 Mar 2013 09:30:34 -0400 Alex Kodat
> wro
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?
On Sun, 17 Mar 2013 09:30:34 -0400 Alex Kodat
wrote:
:>Seems like this might be an excuse to correct what I view as a
Seems like this might be an excuse to correct what I view as a historical
mistake in the Assembler, namely the precedence of native
instructions/extended mnemomics over macros. This precedence means that
every time IBM introduces a new instruction or extended mnemonic they
introduce a backward inc
Ref: Your note of Fri, 15 Mar 2013 12:31:01 -0700
There are currently something like 373 extended mnemonics defined
in the current HLASM operation code table, and I'd rather not add
too many more unless there's a very good reason for them. Some
"obvious" mnemonics have already had to be adjusted
On 3/16/2013 11:33 PM, Shane G wrote:
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 and truly scarpered. _everybody_ will have different
(lack of) standards for this ...
That is exactly what
> 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
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 hi
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 st
From: "Ed Jaffe"
To:
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 facilitate multiple-precision arithmetic.
(It's the reason th
Edward Jaffe wrote:
Recent System z machines have put much more emphasis on unsigned (aka
'logical') arithmetic. There is now logical load, logical add (with or
without carry), logical subtract (with or without borrow), logical
multiply, logical divide, etc. This technology advance makes sense. I
On 15 March 2013 14:30, Ed Jaffe 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 overflow (i.e., on 'carry
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 neede
From: "Ed Jaffe"
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 "ju
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
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 h
On Mar 15, 2013, at 11:43, 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
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.
-- gil
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 to choose between a set of
built-in assemble
What would you want to test for? All I can think of is: Zero result,
Not-Zero result, Overflow, Underflow. JZ, JNZ, JO, and ???
On Fri, Mar 15, 2013 at 12:27 PM, Ed Jaffe wrote:
> In the original S/360, nearly all instructions that manipulated binary
> integers treated them as signed quantities.
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 aft
34 matches
Mail list logo
