HDTenEightyP/NetNews huggingface dataset:
From: cbbrowne@csi.uottawa.ca (Christopher Browne)
Subject: Re: Promoting APL2
Organization: Dept. of Computer Science, University of Ottawa
Date: Sun, 16 Aug 92 03:05:09 GMT

In article <1176@kepler1.rentec.com> andrew@rentec.com (Andrew Mullhaupt) writes:
>In article <1992Aug13.171145.24691@csi.jpl.nasa.gov> sam@csi.jpl.nasa.gov (Sam Sirlin) writes:
>>
>>In article <168417F7D.JOHNSON2@vm.cc.purdue.edu>, JOHNSON@vm.cc.purdue.edu writes:
>>I don't know what would end up being most popular, but for me there
>>are a few neccessities:
>>
>>1. linear algebra - as much of eispack/linpack/lapack as you can get.
>>Perhaps you could link them in via some sort of quad na? I've
>>translated the qr and qz eigensystem paths into APL if you want them.
>>I have them in readable ASCII form.
>
>NO! NO! A thousand times NO!. These guys have a 3090, and they should use
>ESSL, which is provided by IBM. Although ESSL has some trivial flaws, it
>is probably the only commercial package which is as good or better than
>LINPACK/EISPACK/LAPACK. ESSL has the world's _best_ FFT's bar none. (what
>else would you expect from Winograd et. al.?) Last time I used it, IBM
>had gone to the trouble to write the required interface for all of ESSL
>routines to quad-NA. Use the IBM provided ESSL.

I think you exaggerate a few times (maybe 995 or 996 :-)).

They may be using a 3090, but can you ASSUME that they have ESSL?  I
don't know all of IBM's marketing/pricing policies, but it's possible
that ESSL would be an expensive addition to the system.  (And in-house
development of an alternative would ALSO be expensive.  There may be a
price tag of $20,000 for ESSL, and a hidden price tag of $75,000 for
the in-house work.  Under different circumstances, one or the other
may be more "acceptable.")

IF they have it, it sounds like it's a pretty good idea to make use of
it.  But, it's not a universal panacea to all of the worlds problems.

For instance, it might be nice to develop an environment that's not
going to restrict you to 3090s.  Using {LIN,EIS,LA}PACK would allow
porting to other systems just a little easier.  This may not be the
FIRST thing they want, but using ESSL will prevent any sort of
portability.  Life is similar for the Runge-Kutta code.

-- 
Christopher Browne
cbbrowne@csi.uottawa.ca
University of Ottawa
Master of System Science Program
Newsgroups: comp.lang.apl
From: hui@yrloc.ipsa.reuter.COM (Roger Hui)
Subject: Partitions, Part II (Was: Question about recursion in J)
Organization: Iverson Software Inc.
Date: Sat, 15 Aug 92 14:19:36 GMT

There is a multiply-recursive method of generating partitions which
may be easier to understand, viz.:
 
t=.i.0 0
t=.t, '$.=.1+(1<x.)*.x.<y.'
t=.t, '(((0<x.)*.x.<:y.),x.)$1>.y.*1=x.'
t=.t, '; k (>:@[,.+)&.>(<:x.) <@part2 y.->:x.*k=.i.<.y.%x.'
part2 =. '' : t " 0
 
t=.i.0 0
t=.t, 'p=.x. part2 y.'
t=.t, 'z=.$0'
t=.t, 'z=.z, *./ y. = +/"1 p'             NB. sum
t=.t, 'z=.z, x. = {:$p'                   NB. size
t=.t, 'z=.z, (/:p) -: i.#p'               NB. sorted
t=.t, 'z=.z, *./ p (/:@[ -: ])"1 i.x.'    NB. sorted within rows
assert =. '' : t
 
   3 part2 10                3 assert 10
1 1 8                     1 1 1 1
1 2 7                        3 assert 3
1 3 6                     1 1 1 1
1 4 5                        3 assert 1
2 2 6                     1 1 1 1
2 3 5                        0 assert 3
2 4 4                     1 1 1 1
3 3 4                        0 assert 0
                          1 1 1 1

------------------------------------
Roger Hui, Iverson Software Inc., 33 Major Street, Toronto, Ontario  M5S 2K9
Phone: (416) 925 6096;  Fax: (416) 488 7559
Newsgroups: comp.lang.apl
From: qmdbms@gsusgi2.gsu.edu (Brian Schott)
Subject: J5.1 question
Organization: Georgia State University
Date: Sat, 22 Aug 1992 18:38:51 GMT


On the Silicon graphics machine using J5.1, I am having a problem and
would like help. I have defined t below and put it into my profile.js
file.  It reads in fine.

t =. '(<''out''&,y.) 0!:2 <''sgi''&,y.' ; '(<''out''&,y.) 0!:2 <''sgipend'''
 
If I "open" t with ">" it looks as follows.  
   >t
(<'out'&,y.) 0!:2 <'sgi'&,y.
(<'out'&,y.) 0!:2 <'sgipend'

If I run t as follows, the session stops in the middle, hung up.
t : '' 'logic'

But if I do the same thing as t does, but manually, as I show next, the
session runs to completion and all is well. 
(<'outlogic') 0!:2 <'sgilogic'
(<'outlogic') 0!:2 <'sgipend'


Does anyone see a mistake?  To be more specific when the session hangs
up, it hangs up after completing the first line in t, somewhere deep
into the second line of t.  Furthermore the output from the first line
of t is short and sweet, but the output of the second line should be 
380 lines, but none shows in the file 'outlogic'. 

-- 
Brian Schott/Decision Sciences Dept.             qmdbms@gsusgi2.gsu.edu
College of Business Administration                         404-651-4070
Georgia State University                  interests: approx. reasoning,
Atlanta, Georgia USA 30303-3083     (B=)       decision support systems
Newsgroups: comp.lang.apl
From: Richard J. Gaylord <gaylord@ux1.cso.uiuc.edu>
Subject: want to purchase APL books
X-Xxdate: Thu, 20 Aug 92 08:18:40 GMT
X-Useragent: Nuntius v1.1.1d8
Organization: University of Illinois
Date: Thu, 20 Aug 1992 13:17:58 GMT
X-Xxmessage-Id: <A6B905E067019B13@mm-mac19.mse.uiuc.edu>

some time ago there was an announcement about APL books being for sale. i
ordered a number of the books but apparently it was never processed.
could someone plsease tell me how to contact the person(s) selling the
APL books?

thanks.
From: NEWS@UCF1VM.BITNET
Newsgroups: comp.lang.asm370
Subject: Re: ICM vs. L and LTR
Date: 12 Aug 92 19:06:10 GMT
Reply-To: IBM 370 Assembly Programming Discussion List <ASM370%UGA.BITNET@cmsa.Berkeley.EDU>
Distribution: inet
Organization: The Internet

dwayne@dwayneb.b17d.ingr.com (Dwayne A. Blumenberg) writes:

>I've noticed lately that some recent IBM code uses
>the sequence:

>    L     Rx,AREA
>    LTR   Rx,Rx
>    BNZ   SOMEWHERE

>and I was wondering if

>    ICM   Rx,15,AREA
>    BNZ   SOMEWHERE

>would be faster?  It looks to me like the two code segments
>would produce identical results (ignoring for the moment that
>the LOAD instruction could take an index register, and that
>ICM wasn't available on the 360, and that LOAD on a 360 could
>cause a specification exception).

Sounds right.

>I'm sure that LTR is very fast, but is L + LTR faster than
>ICM?  What, if any, advantages does the L + LTR sequence offer
>above ICM?

In a pipelined implementation, unless ICM 15 is implemented to be equivalent to
L/LTR (which would require decoding ICM 15 differently than the general case of
ICM by skipping masking of the loaded result before a compare), which I find
unlikely, it would seem reasonable that the L/LTR would execute faster because
the LTR would execute immediately after the result of the L is available (via
bypass circuitry).  In defense of ICM 15: it does save two bytes :-).

In support of my interpretation... there was a thread recently in comp.arch on
claims that use of RISC-y ISA subsets on CISC processors can trade somewhat
increased code space for much higher performance.

--
John R. Grout
University of Illinois, Urbana-Champaign
Center for Supercomputing Research and Development

    INTERNET: j-grout@uiuc.edu
From: ag129@cl.cam.ac.UK (Alasdair Grant)
Newsgroups: comp.lang.asm370
Subject: Re: ICM vs. L and LTR
Date: 13 Aug 92 11:25:18 GMT
Reply-To: IBM 370 Assembly Programming Discussion List <ASM370%UGA.BITNET@cmsa.Berkeley.EDU>
Distribution: inet
Organization: The Internet

I tested this on a 3084Q once: an empty BCT loop takes 100ns, ICM 15,15,0
takes 100ns, and L 15,0; LTR 15,15 takes 74ns. I didn't try to test any
of the subtle pipelining effects so these figures should be taken with a
pinch of salt.
From: ag129@cl.cam.ac.uk (Alasdair Grant)
Newsgroups: comp.lang.asm370
Subject: Re: ICM vs. L and LTR
Date: 13 Aug 92 11:25:18 GMT
Reply-To: ag129@cl.cam.ac.uk (Alasdair Grant)
Organization: U of Cambridge Comp Lab, UK


I tested this on a 3084Q once: an empty BCT loop takes 100ns, ICM 15,15,0
takes 100ns, and L 15,0; LTR 15,15 takes 74ns. I didn't try to test any
of the subtle pipelining effects so these figures should be taken with a
pinch of salt.
From: POSTMASTER@UGA.BITNET (Undetermined origin c/o Postmaster)
Newsgroups: comp.lang.asm370
Subject: (none)
Date: 23 Aug 92 07:01:09 GMT
Reply-To: IBM 370 Assembly Programming Discussion List <ASM370%UGA.BITNET@cmsa.Berkeley.EDU>
Distribution: inet
Organization: The Internet
X-Unparsable-Date: Sun, 23 Aug 1992 02:59:15 LCL

In article <9208150755.AA07894@nettlerash.berkeley.edu> you write:
>
>That's not a valid conclusion.  You can't add execution times of
>instructions to get the execution time of the combination, exactly for
>the reason you mention.

Point taken.

Missed you in Atlanta, BTW.

- Dave
  dandrews@bilver.oau.org
From: PROHVK32@TREARN.BITNET (Cem Turgay)
Newsgroups: comp.lang.asm370
Subject: VSAM question
Date: 13 Aug 92 18:36:43 GMT
Reply-To: IBM 370 Assembly Programming Discussion List <ASM370%UGA.BITNET@cmsa.Berkeley.EDU>
Distribution: inet
Organization: The Internet
X-Unparsable-Date: Tue, 28 Jul 1992 13:22:29 TUR

Hello,

I didn't get response from VSAM-L and I decided to ask my problem here

I wrote some application in assembly for VSAM. These are working well,
but I don't want to close some data-set for later use. The VSAM
data-sets seems don't like stay opened ! When the application return
to CMS, the CMS (or VSAM routines ?) try to close my data-sets,
allways I got, 4226I AUTOMATIC CLOSE COULD NOT BE STARTED FILE=N/A R=2
message and I find my data-set was closed later.
If I close them before return, everything is going well...

But, how can I leave data-set opened, when I return the CMS ?
I don't want to open & close for every assemble call ! Is there a way
to leave them opened for later use. (may exit routines ?)

I'm running on IBM3090 150E, VM/XA CMS (370 emulation) and
VSAM release 2. I use OSVSAM macros.

Thanks,

  Cem Turgay   (PROHVK38@TREARN, PROHVK32@TREARN)
Newsgroups: comp.lang.asm370
From: hard@rock.concert.net (Kevin  Hardman -- Personal Account)
Subject: Re: ICM vs. L and LTR
Organization: CONCERT-CONNECT -- Public Access UNIX
Date: Thu, 13 Aug 1992 04:28:52 GMT

>>    L     Rx,AREA
>>    LTR   Rx,Rx
>>    BNZ   SOMEWHERE
>>and I was wondering if
>>    ICM   Rx,15,AREA
>>    BNZ   SOMEWHERE
>
>>would be faster?  It looks to me like the two code segments

Sorry, I can't supply references, but I read an article recently that
discussed the very issue and several related myths.  According to the
article the L, LTR was actually faster in older (much older) machines,
but in since like the 370/168 the ICM is actually faster.  If it's really
important I could see if I could dig up the article.


--Kevin

+=====================================+=====================================+
| B. Kevin Hardman                    | Internet: hard@rock.concert.net     |
+-------------------------------------+-------------------------------------+
| No Affiliations, No Disclaimers, No Apologies                             |
From: NEWS@UCF1VM.BITNET
Newsgroups: comp.lang.asm370
Subject: L/LTR vs ICM
Date: 18 Aug 92 17:45:06 GMT
Reply-To: IBM 370 Assembly Programming Discussion List <ASM370%UGA.BITNET@cmsa.Berkeley.EDU>
Distribution: inet
Organization: The Internet

This is posted for Robert Bernecky (rbe@yrloc.ipsa.reuter.com), who
wrote the following:

a. In any of the S/370s I have used (any of them up to the 3084),
   ICM timed slower than L/LTR, EVEN WHEN there was no other instruction
   between the L and the LTR.

   This is similar to MCVL/CLCL vs MVC/CLC loops (when you didn't need
   the overlap case, which we often did in APL), where the page or so
   of code to setup the MVC/CLC loop and the final/first EX Rx,doclc
   usually ran about TWICE as fast as the single MCVL/CLCL instruction.

   It made a RISC convert outa me, it did, it did...

b. I suspect that if you could schedule the L/LTR properly by moving
   the L earlier (or the LTR later) in the instruction stream, they
   would run even faster than ICM.

c. ICM can't be indexed, which makes it even lousier than L/LTR.
   I would have preferred LC (Load Character) and IB (Insert Bits).
   See B5500 book. Sigh.
Newsgroups: comp.lang.asm370
From: dandrews@bilver.uucp (Dave Andrews)
Subject: Re: ICM vs. L and LTR
Organization: W. J. Vermillion - Winter Park, FL
Date: Thu, 13 Aug 1992 15:30:01 GMT

In article <1992Aug12.163757.759@infonode.ingr.com> dwayne@dwayneb.b17d.ingr.com (Dwayne A. Blumenberg) writes:
>I've noticed lately that some recent IBM code uses
>the sequence:
>
>    L     Rx,AREA
>    LTR   Rx,Rx
>    BNZ   SOMEWHERE
>
>and I was wondering if
>
>    ICM   Rx,15,AREA
>    BNZ   SOMEWHERE
>
>would be faster?

A paper in the CME Newsletter #88 entitled "Measuring 370 Instructions"
(by Ed Stewart) talks about the author's effort to measure how fast
individual instructions are on a 3081K CPU.  Pipelining and alignment
and god knows what else all affect instruction execution rates, so
IBM doesn't quote these much anymore.

Anyway, he clocked the following instructions at the indicated MIPS:

   ICM   0,15,W1             10.4287
   L     0,W1                41.8938
   LTR   0,1                 41.7416

So it appears that -- at least on a 3081K -- the L/LTR sequence is
roughly twice as fast as the ICM.

>-- 
>Dwayne A. Blumenberg            | Internet:  dwayne@dwayneb.b30.ingr.com
>IBM Systems Programmer          | UUCP:      ...uunet!ingr!b30!dwayneb!dwayne
>Intergraph Corp., M.S. GD3002   | Voice:     (205) 730-3795
>Huntsville, AL  35894-0001      | FAX:       (205) 730-3300

- David Andrews
  dandrews@bilver.oau.org
From: NEWS@UCF1VM.BITNET
Newsgroups: comp.lang.asm370
Subject: Re: ICM vs. L and LTR
Date: 13 Aug 92 15:30:01 GMT
Reply-To: IBM 370 Assembly Programming Discussion List <ASM370%UGA.BITNET@cmsa.Berkeley.EDU>
Distribution: inet
Organization: The Internet

In article <1992Aug12.163757.759@infonode.ingr.com> dwayne@dwayneb.b17d.ingr.com
 (Dwayne A. Blumenberg) writes:
>I've noticed lately that some recent IBM code uses
>the sequence:
>
>    L     Rx,AREA
>    LTR   Rx,Rx
>    BNZ   SOMEWHERE
>
>and I was wondering if
>
>    ICM   Rx,15,AREA
>    BNZ   SOMEWHERE
>
>would be faster?

A paper in the CME Newsletter #88 entitled "Measuring 370 Instructions"
(by Ed Stewart) talks about the author's effort to measure how fast
individual instructions are on a 3081K CPU.  Pipelining and alignment
and god knows what else all affect instruction execution rates, so
IBM doesn't quote these much anymore.

Anyway, he clocked the following instructions at the indicated MIPS:

   ICM   0,15,W1             10.4287
   L     0,W1                41.8938
   LTR   0,1                 41.7416

So it appears that -- at least on a 3081K -- the L/LTR sequence is
roughly twice as fast as the ICM.

>--
>Dwayne A. Blumenberg            | Internet:  dwayne@dwayneb.b30.ingr.com
>IBM Systems Programmer          | UUCP:      ...uunet!ingr!b30!dwayneb!dwayne
>Intergraph Corp., M.S. GD3002   | Voice:     (205) 730-3795
>Huntsville, AL  35894-0001      | FAX:       (205) 730-3300

- David Andrews
  dandrews@bilver.oau.org
Newsgroups: comp.lang.asm370
From: j-grout@uxa.cso.uiuc.edu (grout john robert)
Subject: L/LTR vs ICM
Reply-To: rbe@yrloc.ipsa.reuter.com
Organization: University of Illinois at Urbana
Date: Tue, 18 Aug 1992 17:45:06 GMT
Keywords: ICM L LTR

This is posted for Robert Bernecky (rbe@yrloc.ipsa.reuter.com), who
wrote the following:

a. In any of the S/370s I have used (any of them up to the 3084),
   ICM timed slower than L/LTR, EVEN WHEN there was no other instruction
   between the L and the LTR. 

   This is similar to MCVL/CLCL vs MVC/CLC loops (when you didn't need 
   the overlap case, which we often did in APL), where the page or so
   of code to setup the MVC/CLC loop and the final/first EX Rx,doclc
   usually ran about TWICE as fast as the single MCVL/CLCL instruction.

   It made a RISC convert outa me, it did, it did...

b. I suspect that if you could schedule the L/LTR properly by moving
   the L earlier (or the LTR later) in the instruction stream, they
   would run even faster than ICM. 

c. ICM can't be indexed, which makes it even lousier than L/LTR.
   I would have preferred LC (Load Character) and IB (Insert Bits).
   See B5500 book. Sigh.
From: grout@sp90.csrd.uiuc.edu (John R. Grout)
Newsgroups: comp.lang.asm370
Subject: Re: ICM vs. L and LTR
Date: 12 Aug 92 19:06:10 GMT
Reply-To: j-grout@uiuc.edu
Organization: UIUC Center for Supercomputing Research and Development

dwayne@dwayneb.b17d.ingr.com (Dwayne A. Blumenberg) writes:

>I've noticed lately that some recent IBM code uses
>the sequence:

>    L     Rx,AREA
>    LTR   Rx,Rx
>    BNZ   SOMEWHERE

>and I was wondering if

>    ICM   Rx,15,AREA
>    BNZ   SOMEWHERE

>would be faster?  It looks to me like the two code segments
>would produce identical results (ignoring for the moment that
>the LOAD instruction could take an index register, and that
>ICM wasn't available on the 360, and that LOAD on a 360 could
>cause a specification exception).

Sounds right.

>I'm sure that LTR is very fast, but is L + LTR faster than
>ICM?  What, if any, advantages does the L + LTR sequence offer
>above ICM?

In a pipelined implementation, unless ICM 15 is implemented to be equivalent to
L/LTR (which would require decoding ICM 15 differently than the general case of
ICM by skipping masking of the loaded result before a compare), which I find
unlikely, it would seem reasonable that the L/LTR would execute faster because
the LTR would execute immediately after the result of the L is available (via
bypass circuitry).  In defense of ICM 15: it does save two bytes :-).

In support of my interpretation... there was a thread recently in comp.arch on
claims that use of RISC-y ISA subsets on CISC processors can trade somewhat
increased code space for much higher performance.

--
John R. Grout
University of Illinois, Urbana-Champaign
Center for Supercomputing Research and Development

    INTERNET: j-grout@uiuc.edu
From: LDW@USCMVSA.BITNET (Leonard D Woren)
Newsgroups: comp.lang.asm370
Subject: Re: ICM vs. L and LTR
Date: 15 Aug 92 07:52:00 GMT
Reply-To: IBM 370 Assembly Programming Discussion List <ASM370%UGA.BITNET@cmsa.Berkeley.EDU>
Distribution: inet
Organization: The Internet

On Thu, 13 Aug 1992 15:30:01 GMT, NEWS@UCF1VM.BITNET said:
(Can't somebody fix the blasted gateway so that half the original
messages don't lose their headers?)

> (...)
> Pipelining and alignment
> and god knows what else all affect instruction execution rates,
>
> Anyway, he clocked the following instructions at the indicated MIPS:
>
>    ICM   0,15,W1             10.4287
>    L     0,W1                41.8938
>    LTR   0,1                 41.7416
>
> So it appears that -- at least on a 3081K -- the L/LTR sequence is
> roughly twice as fast as the ICM.

That's not a valid conclusion.  You can't add execution times of
instructions to get the execution time of the combination, exactly for
the reason you mention.  When we got a 3090-200 at my previous
employer, the first thing that I did was try to compare its speed to
our 3084Qx.  (Yep, that's a lower case x, which was halfway between a
3084Q and a 3084QX.)  I ran various tiny programs, like a BCTR loop to
clear a register, which I think ran at 40 MIPS.  I kept adding
instructions into the loop.  If I remember right, a loop consisting of
LR 1,2; BCTR 3,14 was the same speed as just the BCTR.  In fact, I
could add carefully chosen instructions without really affecting the
CPU time, so I got some wild MIPS results.  Most floating point
instructions also took zero time.  I had almost 10 instructions in the
loop and it still ran in about the same time as just the BCTR loop,
until I added a floating point multiply, at which point the CPU time
shot up.

So, the only correct way to determine whether L;LTR is faster than
ICM 15 is to time it on your machine.  But the CPU time used in this
discussion is probably much higher than any potential savings from
knowing the answer.

/Leonard
From: $LPAKHA@LUCCPUA.BITNET (Kee)
Newsgroups: comp.lang.asm370
Subject: subscribe
Date: 20 Aug 92 18:27:00 GMT
Reply-To: IBM 370 Assembly Programming Discussion List <ASM370%UGA.BITNET@cmsa.Berkeley.EDU>
Distribution: inet
Organization: The Internet

SUBSCRIBE or add me to the list
Newsgroups: comp.lang.asm370
From: dwayne@dwayneb.b17d.ingr.com (Dwayne A. Blumenberg)
Subject: ICM vs. L and LTR
Organization: Intergraph Corporation, Huntsville, AL.
Date: Wed, 12 Aug 1992 16:37:57 GMT

I've noticed lately that some recent IBM code uses
the sequence:

    L     Rx,AREA
    LTR   Rx,Rx
    BNZ   SOMEWHERE

and I was wondering if

    ICM   Rx,15,AREA
    BNZ   SOMEWHERE

would be faster?  It looks to me like the two code segments
would produce identical results (ignoring for the moment that
the LOAD instruction could take an index register, and that
ICM wasn't available on the 360, and that LOAD on a 360 could
cause a specification exception).

I'm sure that LTR is very fast, but is L + LTR faster than
ICM?  What, if any, advantages does the L + LTR sequence offer
above ICM?

Thanks.
-- 
Dwayne A. Blumenberg            | Internet:  dwayne@dwayneb.b30.ingr.com
IBM Systems Programmer          | UUCP:      ...uunet!ingr!b30!dwayneb!dwayne
Intergraph Corp., M.S. GD3002   | Voice:     (205) 730-3795
Huntsville, AL  35894-0001      | FAX:       (205) 730-3300
From: hard@rock.UUCP (Kevin Hardman -- Personal Account)
Newsgroups: comp.lang.asm370
Subject: Re: ICM vs. L and LTR
Date: 13 Aug 92 04:28:52 GMT
Reply-To: IBM 370 Assembly Programming Discussion List <ASM370%UGA.BITNET@cmsa.Berkeley.EDU>
Distribution: inet
Organization: The Internet

>>    L     Rx,AREA
>>    LTR   Rx,Rx
>>    BNZ   SOMEWHERE
>>and I was wondering if
>>    ICM   Rx,15,AREA
>>    BNZ   SOMEWHERE
>
>>would be faster?  It looks to me like the two code segments

Sorry, I can't supply references, but I read an article recently that
discussed the very issue and several related myths.  According to the
article the L, LTR was actually faster in older (much older) machines,
but in since like the 370/168 the ICM is actually faster.  If it's really
important I could see if I could dig up the article.


--Kevin

+=====================================+=====================================+
| B. Kevin Hardman                    | Internet: hard@rock.concert.net     |
+-------------------------------------+-------------------------------------+
| No Affiliations, No Disclaimers, No Apologies                             |
From: dwayne@dwayneb.UUCP ("Dwayne A. Blumenberg")
Newsgroups: comp.lang.asm370
Subject: ICM vs. L and LTR
Date: 12 Aug 92 16:37:57 GMT
Reply-To: IBM 370 Assembly Programming Discussion List <ASM370%UGA.BITNET@cmsa.Berkeley.EDU>
Distribution: inet
Organization: The Internet

I've noticed lately that some recent IBM code uses
the sequence:

    L     Rx,AREA
    LTR   Rx,Rx
    BNZ   SOMEWHERE

and I was wondering if

    ICM   Rx,15,AREA
    BNZ   SOMEWHERE

would be faster?  It looks to me like the two code segments
would produce identical results (ignoring for the moment that
the LOAD instruction could take an index register, and that
ICM wasn't available on the 360, and that LOAD on a 360 could
cause a specification exception).

I'm sure that LTR is very fast, but is L + LTR faster than
ICM?  What, if any, advantages does the L + LTR sequence offer
above ICM?

Thanks.
--
Dwayne A. Blumenberg            | Internet:  dwayne@dwayneb.b30.ingr.com
IBM Systems Programmer          | UUCP:      ...uunet!ingr!b30!dwayneb!dwayne
Intergraph Corp., M.S. GD3002   | Voice:     (205) 730-3795
Huntsville, AL  35894-0001      | FAX:       (205) 730-3300
Newsgroups: comp.lang.modula3