On 2021-11-14 03:10, Phil Smith III wrote:
Unoptimised code typically has redundant instructions.
For example, a store instruction to finish an assignment
operation might be followed by a load from the same place
in a following statement.
That I could believe--the unoptimized code is dealing
On 2021-11-13 01:04, Peter Relson wrote:
When it needs zero, it merely copies it into anther
register that it has allocated?
Yes, but why not just store the register that they know already
contains
zero?
Because they do not necessarily "know" that when the code is generated.
It
might
On 2021-11-13 02:32, Phil Smith III wrote:
Thanks to all for the replies. I had clearly forgotten what MVHI did
(OK, I
probably never knew-too many new instructions!).
As I said, it's not a problem, but I'm a bit bothered by your comment,
Peter:
So this is not a curious "optimization". It is
On 2021-11-12 13:50, Seymour J Metz wrote:
When it needs zero, it merely copies it into anther
register that it has allocated?
Yes, but why not just store the register that they know a;ready
contains zero?
It's the code BEFORE optimisation.
On 2021-03-12 00:41, Peter Relson wrote:
To add to what Charles M posted,
Don't forget that LA in AMODE 31 always zeroes bit 32, and LA in AMODE
24
zeroes bits 32-39 of the 64-bit GR.
That's another way that they are not functionally equivalent, if that
difference matters to you.
A good rule
On 2021-03-12 00:38, Paul Gilmartin wrote:
On 2021-03-10, at 22:10:14, robi...@dodo.com.au wrote:
...
You can use LA to subtract 1 if you have a negative value
in a base register, subject to the same limit.
Why would you do that, when BCTR R,0 will do it for free
with even zero as the
On 2021-03-11 15:56, Paul Gilmartin wrote:
On 2021-03-10, at 18:21:11, Robin Vowels wrote:
From: "Schmitt, Michael"
Sent: Thursday, March 11, 2021 10:26 AM
I was taught long ago to add 1 to a register using LA r#,1(,r#)
and to subtract 1 using BCTR r#,0.
Is the fastest way now to use AHI
On 2020-10-23 23:06, Seymour J Metz wrote:
MVCIN is not a BIF in HLASM.
MVCIN is an instruction.
Don't confuse what is available at run
time with what is available at assembly time.
Is there an RFE for a REVERSE BIF in HLASM? Is there a PL/I compile
time REVERSE function?
Have you tried MVCIN ?
Em qui, 22 de out de 2020 18:08, Steve Smith
escreveu:
Submitted for your consideration...
MACRO
#REVSTR
SETC DEQUOTE('')
SETA DCLEN('')
.*
SETA
.LOOPAIF ( LT 1).DONE
SETC ''.''(,1)
SETA
AGO .LOOP
.*
Tony,
I have a copy of the Sysem z assembler text. It's 3.5mb.
My I send it to you direct?
On 2020-08-13 22:24, Tony Thigpen wrote:
During a PC crash, I have lost a bunch of softcopy manuals including
my copy of John's book and the downloadable material.
It appears that Marist has re-done
On 2020-08-10 02:13, Seymour J Metz wrote:
I'm fully conversant with UNPK,
Obviously you are not, or you would not have said that
the ASCII bit "only affects the handling of the sign nybble".
including the fact that the zone it
sets depends on the value of the ASCII bit. How is that relevant
On 2020-08-09 15:05, Seymour J Metz wrote:
How is the ASCII bit relevant to teletypes? It only affects the
handling of the sign nybble.
You might want to check out the UNPK instruction.
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From:
Interesting are the two paragraphs on page 302, bottom RHS.
Case says that nobody used the ASCII capability of the S/360.
Padegs says that "none of our operating systems were [sic] programmed
to turn in the [ASCII] bit".
So, no-one was able to use the ASCII facility.
On 2020-08-08 12:19, Jim
On 2020-06-05 11:20, Gerhard adam wrote:
There is no such thing as a sign before the value is packed or
converted to binary.
Since all numbers have a zone field of X’F’ there can be no discussion
about a sign since it is not part of the number
A zoned number has the sign in the more-signficant
On 2020-06-05 11:41, Gerhard adam wrote:
The sign is only going to be relevant if that is true. If there is no
sign then there is nothing to discuss.
According to the OP, there is a sign.
The packed form of the number has the sign in the least-significant
byte.
On Thu, Jun 4, 2020 at
On 2020-06-05 11:50, Seymour J Metz wrote:
There is no "S/360 normal cycle time";
I quoted the time for the model 50.
each model has its own
processor and storage timings,
Obviously, as you already quoted .75 uS.
with a few duplications, e.g., 65 and
67. The core storage on the 360/65
On 2020-06-05 11:20, Gerhard adam wrote:
There is no such thing as a sign before the value is packed or
converted to binary.
Since all numbers have a zone field of X’F’ there can be no discussion
about a sign since it is not part of the number
In EBCDIC form, i.e. unpacked, the sign is in the
On 2020-06-05 07:35, Seymour J Metz wrote:
Yeah, 8 microsecond instead of .75 microsecond.
The S/360 normal cycle time was 2 microseconds.
--
Shmuel (Seymour J.) Metz
From: robi...@dodo.com.au [robi...@dodo.com.au]
Sent: Thursday, June 4, 2020
On 2020-06-05 10:04, Seymour J Metz wrote:
Clock cycle isn't everything.
Clock cycle WAS everything then.
Clock cycle of Pilot ACE was around 4 times faster than
other machines of the 1950s, and hence a similar factor
faster.
"An addition could take anywhere from 64
microseconds to 1024
On 2020-06-05 08:24, Seymour J Metz wrote:
Thanks.
My understanding is that delay lines using a solid medium were more
reliable than Williams Tubes,
That's right.
so using them on slow machines seems
reasonable..
Pilot ACE was the fastest machine in the world in 1951.
DEUCE ran at the
On 2020-06-05 03:45, Seymour J Metz wrote:
I remember $.25/bit, but don't recall what year that was; too low for
1960, too high for 1969.
Don't forget that there were two types of core memory for
the S360 --
LCS used a product from India, with a much slower cycle time
compared to IBM's normal
On 2020-06-05 04:59, Seymour J Metz wrote:
I see an error in that chart: the 370/135 did not use core storage.
From the announcement letter: "The Model 135 uses the same innovative
monolithic circuit memory introduced with System/370 Model 145"
The 1957 and 1959 prices were not very helpful;
On 2020-06-04 11:43, Dan Greiner wrote:
In an interview in the "Communications of the ACM" (volume 30, number
4, April 1987), two of the original instruction-set architects —
Andris Padegs and Richard Case — weighed in on EDIT and EDIT AND MARK.
The interviewer, Alfred Spector, asked: "Did you
On 2020-05-01 12:14, jba...@ngssallc.com wrote:
I must really be getting old, because I actually remember the origin of
the
convention.
The convention of "*-*" in a length field was based upon an
interpretation
of the expression "{address-of-last-byte}-{address-of-first-byte}"
which
On 2020-04-30 18:15, Martin Ward wrote:
On 30/04/2020 03:48, robi...@dodo.com.au wrote:
What's wrong with a comment?
It *is* a comment (in the broader sense).
No it isn't. *-* doesn't explain anything.
If it did, people wouldn't be asking what on earth is it.
A comment that explains
On 2020-04-30 07:08, Kerry Liles wrote:
I always thought that some programmers did that as an "eye catcher"
to indicate that the value might nominally be zero but it will be
dynamically modified elsewhere...
(perhaps by an EX or worse - direct smashing)
A naked zero is not remarkable but *-*
On 2020-04-21 11:44, Paul Gilmartin wrote:
On 2020-04-20, at 18:31:19, robi...@dodo.com.au wrote:
On 2020-04-21 02:29, Ed Jaffe wrote:
On 4/19/2020 11:24 PM, Windt, W.K.F. van der (Fred) wrote:
DCCL8''
For such a case, I will always code:
DC CL8' '
Why not just apply the bug fix?
On 2020-04-21 02:29, Ed Jaffe wrote:
On 4/19/2020 11:24 PM, Windt, W.K.F. van der (Fred) wrote:
DCCL8''
For such a case, I will always code:
DC CL8' '
Why not just apply the bug fix?
On 2019-06-26 11:47, Mike La Martina wrote:
Floating point is stored in double words.
Floating-point can also be stored in a word (i.e., single precision).
Most of the time the nominal
value is 0, which looks the same in hex and Floating Point.
The FD notation seems weird to me. But it
On 2019-06-20 23:00, John McKown wrote:
I am continuing my "education" in the newer instructions. I think that
I
understand what Branch Indirect on Condition (BIC) does. Instead of
branching to the address in the instruction, it fetches the 8 bytes at
that
address and uses that as the branch
BALR should also lead the OP to other similar instructions to do what
he wants.
- Original Message -
From: "IBM Mainframe Assembler List" @listserv.uga.edu>
To:
Cc:
Sent:Thu, 6 Dec 2018 17:50:26 -0700
On 2018-12-06, at 16:07:36, Robin Vowels wrote:
> BALR
>
What AMODE?
The name has been PL/I after some earlier names, not PL/1
- Original Message -
From: "IBM Mainframe Assembler List" @listserv.uga.edu>
To:
Cc:
Sent:Fri, 29 Jun 2018 21:27:12 +
Subject:Re: An idea I got when researching a bug - warnings when a
specific register is changed
The name
SPM will set the condition code.
BALR with second operand 0 will give you the condition code.
- Original Message -
From: "IBM Mainframe Assembler List"
Sent:Sat, 5 May 2018 06:22:32 -0400
In 20+ years of heavy assembler coding, I never needed to store and
restore the condition code,
Doesn't the operand "Byte" need to be a register number,
not a DS statement?
From: IBM Mainframe Assembler List
[mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU [1]] On Behalf Of Ed Jaffe
Sent: Sunday, April 22, 2018 6:59 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU [2]
Subject: Dependent USING Does Not Work
- Original Message -
From: "IBM Mainframe Assembler List"
Sent:Mon, 16 Apr 2018 09:06:37 -0400
On Sat, 14 Apr 2018 17:44:37 +1000, robi...@dodo.com.au wrote:
>>Since the object is to convert four decimal digits (range 0-9)
>>to EBCDIC, OC is
Since the object is to convert four decimal digits (range 0-9)
to EBCDIC, OC is sufficient.
- Original Message -
From: "IBM Mainframe Assembler List"
To:
Cc:
Sent:Sat, 14 Apr 2018 08:52:19 +0200
>> OC
Use a TR as well. Works wonders.
- Original Message -
From: "IBM Mainframe Assembler List"
To:
Cc:
Sent:Wed, 14 Mar 2018 21:06:36 -0600
Subject:Re: Two string instruction questions
On 2018-03-14, at 20:32:18, Robin
From: "IBM Mainframe Assembler List"
To:
Cc:
Sent:Fri, 2 Feb 2018 00:49:57 -0600
Subject:Re: Pascal (was : comparison C vs HLASM)
> On Feb 1, 2018, at 9:13 PM, Robin Vowels
wrote:
>
>> From: "Paul
Monetary fields tend to have the finny characters in known positions,
commas (or periods)every third position. The decimal point (period or
comma) also is in a fixed position.All these are in fixed positions
relative to the least significant digit of the amount.
- Original Message -
From:
Using TR in a different way omits the commas and decimal point, sign,
and any other funny characters.
To do this, you swap the roles of the translate table and the string
being translated.
- Original Message -
From: "IBM Mainframe Assembler List"
To:
Cc:
Sent:Mon, 17 Oct 2016 16:24:18
Won't a TR followed by a PACK do this?
- Original Message -
From: "IBM Mainframe Assembler List"
To:
Cc:
Sent:Mon, 17 Oct 2016 15:04:52 -0400
Subject:Re: converting character to packed
since it was my original question and thanks for all of the
suggestions, the data input was manual
42 matches
Mail list logo