The overhead of a macro generated table versus static DC-generated table
would only be an issue if the code is reassembled on a very frequent
basis. Even if that is the case, that still doesn't rule out using an
Assembler macro to generate the table for the first assembly, then using
cut & paste to put the generated DC's into the code and comment out the
macro invocation. That way you can even keep the generation macro in
the code as "documentation" and not have to track or document a separate
program.
I had to consult the Assembler Reference to be sure I knew what I was
doing, but using the Arithmetic AND one can create a simpler version of
the generation macro that eliminates the innermost bit loop. I tested
the version below with z390:
MACRO
.* GENERATE TRT TABLE, 16 BYTES PER DC, FOR REVERSING BITS IN BYTE
&LABEL REVTBL
LCLA &N,&R,SMAX
LCLC &X,&SEP
&LABEL DS 0D
&N SETA 0 BYTE OFFSET IN TABLE
.TLOOP ANOP
&SMAX SETA &N+16 LIMIT FOR NEXT DC STATEMENT GEN
&X SETC '' CUMULATIVE AL1 CONSTANTS NXT DC
&SEP SETC '' NO COMMA NEEDED FOR 1ST AL1 IN DC
.SLOOP ANOP
.* COMPUTE REVERSED BITS FOR &N
&R SETA ((&N AND 128)/128)+((&N AND 64)/32)+((&N AND 32)/8)
&R SETA &R+((&N AND 16)/2)+((&N AND 8)*2)+((&N AND 4)*8)
&R SETA &R+((&N AND 2)*32)+((&N AND 1)*128)
&X SETC '&X.&SEP.&R' ADD NEXT AL1 CONSTANT
&SEP SETC ',' NEXT TIME WILL NEED COMMA
&N SETA &N+1 ADVANCE NXT TABLE BYTE
AIF (&N LT &SMAX).SLOOP IF MORE FOR CURRENT DC
DC AL1(&X.)
AIF (&N LT 256).TLOOP IF MORE DC'S LEFT
MEND
The first and last 16 generated table bytes from the above macro are:
DC AL1(0,128,64,192,32,160,96,224,16,144,80,208,48,176,112,240)
...
DC AL1(15,143,79,207,47,175,111,239,31,159,95,223,63,191,127,255)
which are consistent with the original macro.
Joel C. Ewing
On 07/24/2013 12:54 PM, Kenneth Wilkerson wrote:
> The macro at the end of my reply will generate a reverse translate table. I
> tested it enough to see that it looked right but it has nothing to do with
> my original point. I've found this discussion interesting and it has given
> me reason to play with something other than the complex process I'm working
> on now. My original point, as was taken by Charles, was that I prefer
> automatic processes to generate anything but the simplest translate tables.
> I prefer to do it in a program and copy it from a dump into a program
> because the table is static. I don't need to generate it every time I
> assemble.
>
> In regards to TROO, the original problem was stated as translating a 64 bit
> register. A STG, TR for 8 bytes, followed by a LRVG will more than suffice.
> Though, I find your argument about the use of a TRTRE to simulate a FROGR
> interesting. It brings the whole bit reversal into perspective. I'm not a
> big fan of translate instructions (I use them often enough), particularly
> those that require facilities and facility enhancements, unless you're
> translating "long" strings and are willing to test the facility bits. I'm
> sure that the translation and parsing facilities exist on most customer's
> boxes by now but I emphasize "most". When I awakened this morning, I wrote
> an algorithm to do a load reverse bytes and bits using FLOGR to drive the
> process. I'm going to give the idea of a FROGR simulation more thought and
> continue this exercise later.
>
> MACRO
> &LABEL REVTABLE ,
> * Construct reverse bits translate table
> LCLA &I,&J,&K,&L,&M,&N,&O
> LCLC &X
> &LABEL DS 0D LIKE EM DOUBLE WORD ALIGNED
> &I SETA 0 STARTING VALUE
> .TABLOOP ANOP LOOP UNTIL TABLE IS DONE
> &K SETA 1 NEED SIXTEEN ENTRIES PER LINE
> &X SETC 'AL1('
> AGO .X16LP
> .X16NXT ANOP
> &X SETC '&X'.'&J'.','
> .X16LP ANOP 16 ENTRY LOOP
> &J SETA 0 STARTING RESULT
> &L SETA 1 STARTING ADDEND
> &M SETA 1 8 BITS PER BYTE
> &N SETA 128 STARTING COMPARAND X'80'
> &O SETA &I COPY CURRENT BYTE TO REVERSE
> .BYTELP ANOP
> AIF (&O LT &N).BYTEFT LESS THAN CURRENT - 0
> &O SETA &O-&N
> &J SETA &J+&L
> .BYTEFT ANOP
> &L SETA &L*2 NEXT ADDEND
> &N SETA &N/2 NEXT COMPARAND
> &M SETA &M+1 NEED EIGHT BITS
> AIF (&M LE 8).BYTELP
> &I SETA &I+1
> &K SETA &K+1
> AIF (&K LE 16).X16NXT
> &X SETC '&X'.'&J'.')'
> DC &X
> AIF (&I LT 256).TABLOOP
> MEND
>
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John Gilmore
> Sent: Wednesday, July 24, 2013 10:29 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Is there a "reverse bits" hardware instruction?
>
> The construction of arbitrary translation tables can be error-prone, and
> when it is it is better done procedurally. I use the HLASM macro language,
> which is entirely adequate to such tasks; mais à chacun son goût.
>
> Here, however, we have for a TROO only the 256 permutations taken two at a
> time of the sixteen hexadecimal digits, viz.,
>
> 0==>0, 1==>8, 2==>4, 3==>c,
> 4==>2, 5==>a, 6==>6, 7==>e,
> 8==>1, 9==>9, a==>5, b==>d,
> c==>3, d==>b, e==>7, f==>f
>
> and they can be enumerated readily, by program or manually (and certainly
> without resort to cut-and-paste from a dump).
>
> Symmetries can also be exploited, and the whole thing can be arithmetized,
> but to do either would put mathematics dropouts at a disadvantage.
>
> The problem CAN be addressed with left circular shifts/left rotations, but
> they must be nested (and iterated for long bit strings). The TROO turns out
> to be faster, particularly for those long bit strings.
>
> The problem of bit-string reversal has its own interest, but if its purpose
> is in effect to simulate a FROGR using a FLOGR, then other approaches are
> possible.
>
> Specifically, a TRTRE, Translate and Test Reverse Extended, can be used. It
> proceeds from right to left, high to low storage address, in a byte string
> only until it finds a non-zero value in its table that corresponds to the
> current byte's rank.
>
> Permutations taken two at a time of the hexadecimal digit-codes
>
> 0000==>0000, 0
> 0001==>0001, 1
> 0010==>0010, 2
> 0011==>0001, 1
> 0100==>0011, 3
> 0101==>0001, 1
> 0110==>0010, 2
> 0111==>0001, 1
> 1000==>0100, 4
> 1001==>0001, 1
> 1010==>0010, 2
> 1011==>0001, 1
> 1100==>0011, 3
> 1101==>0001, 1
> 1110==>0010, 2
> 1111==>0001, 1
>
> in which zero indicates the absence of a one bit and a non-zero value
> indicates both the presence of a one bit and its one-origin offset from the
> rightmost bit position. The permutations/code points
>
> x'N0', N = 1, 2, . . . , f
>
> need 'special' treatment, 8 must be added to the values shown above for
> them.
>
> Unsurprisingly, this turns out to be faster than reversal followed by FLOG.
>
> John Gilmore, Ashland, MA 01721 - USA
>
...
--
Joel C. Ewing, Bentonville, AR jcew...@acm.org
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
