So, no need for any macro at all to generate the byte bit reversal TRT
table!  I must have skipped over or forgotten the 2003 posting.

This is just totally awesome, especially the redundant unary "+"'s to
force decent alignment for readability.  Had to actually run it with
PRINT DATA to convince myself it really worked, then study it more
closely.  Once you understand why it is syntactically correct and what
it is doing it seems obvious, but at first sight it is certainly
intimidating. Obviously usage in a production application should have
some explanatory comments so future maintainers don't panic at their
first exposure!
        Joel C Ewing

On 07/25/2013 09:13 AM, Victor Gil wrote:
> Here's a single DC instruction I've posted May 2003 [search for "what's your 
> most difficult assembler concept"]
> 
> BYTE_FLIP DS 0CL256
> T    DC 256AL1((((*-T)/001)-((*-T)/002)*2)*X'80'++++++++++++++++++++++++
>                (((*-T)/002)-((*-T)/004)*2)*X'40'++++++++++++++++++++++++
>                (((*-T)/004)-((*-T)/008)*2)*X'20'++++++++++++++++++++++++
>                (((*-T)/008)-((*-T)/016)*2)*X'10'++++++++++++++++++++++++
>                (((*-T)/016)-((*-T)/032)*2)*X'08'++++++++++++++++++++++++
>                (((*-T)/032)-((*-T)/064)*2)*X'04'++++++++++++++++++++++++
>                (((*-T)/064)-((*-T)/128)*2)*X'02'++++++++++++++++++++++++
>                (((*-T)/128)-((*-T)/256)*2)*X'01')                      
> 
> HTH,
> -Victor-
> 
> -----------------------------------------------------------------------
> 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
> 
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
> 


-- 
Joel C. Ewing,    Bentonville, AR       [email protected] 

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to