On Mon, 31 Jan 2022 at 15:55, Dave Clark <dlcl...@winsupplyinc.com> wrote:
> Good deal. I replaced the following 104 bytes of machine code...
...
> ...with the following 38 bytes of machine code. Thanks.
Here's a different approach, though if you are primarily looking to
economize on code bytes, it may not be for you. It uses a 256-byte table to
contain the possible output values, and just translates the input to output
directly. (I'm assuming that the bits to the right of the top four may not
be zero.)
SR R0,R0 Test char not in table (for older machines)
LA R1,TABLE1 -> 256-byte table
LA R3,RECBUF+108 -> Input byte
LA R6,CWORK -> One output byte
LHI R7,1 Length of input in bytes
TROO TROO R6,R3,B’0001’ Translate with no test
BC 3,TROO Unlikely, but be safe
TABLE1 DS 0D Critical alignment! Input values
DC C'1111111111111111' 00-0F
DC C'1111111111111111' 10-1F
DC C'1111111111111111' 20-2F
DC C'1111111111111111' 30-3F
DC C'2222222222222222' 40-4F
DC C'2222222222222222' 50-5F
DC C'2222222222222222' 60-6F
DC C'2222222222222222' 70-7F
DC C'3333333333333333' 80-8F
DC C'3333333333333333' 90-9F
DC C'3333333333333333' A0-AF
DC C'3333333333333333' B0-BF
DC C'4444444444444444' C0-CF
DC C'4444444444444444' D0-DF
DC C'4444444444444444' E0-EF
DC C'4444444444444444' F0-FF
The above handles only the first of your two sets of two bits, and a
different table is needed to deal with the second. But it can all be done
in a single translate with the right table:
SR R0,R0 Test char not in table (for older machines)
LA R1,TABLE2 -> 512-byte table
LA R3,RECBUF+108 -> Input byte
LA R6,CWORK -> Two output bytes
LHI R7,1 Length of input in bytes
TROT TROT R6,R3,B’0001’ Translate with no test
BC 3,TROT Unlikely, but be safe
TABLE2 DS 0D Critical alignment! Input values
DC C'11111111111111111111111111111111' 00-0F
DC C'12121212121212121212121212121212' 10-1F
DC C'13131313131313131313131313131313' 20-2F
DC C'14141414141414141414141414141414' 30-3F
DC C'21212121212121212121212121212121' 40-4F
DC C'22222222222222222222222222222222' 50-5F
DC C'23232323232323232323232323232323' 60-6F
DC C'24242424242424242424242424242424' 70-7F
DC C'31313131313131313131313131313131' 80-8F
DC C'32323232323232323232323232323232' 90-9F
DC C'33333333333333333333333333333333' A0-AF
DC C'34343434343434343434343434343434' B0-BF
DC C'41414141414141414141414141414141' C0-CF
DC C'42424242424242424242424242424242' D0-DF
DC C'43434343434343434343434343434343' E0-EF
DC C'44444444444444444444444444444444' F0-FF
This isn't a complete drop-in for your code because it produces the two
output value in adjacent bytes at CWORK, but perhaps you can accept that,
or if not, you can copy the second byte to the right place. lease excuse
typos; I haven't actually built or tested this. One could write a simple
macro to generate the table from the bit field sizes and range, and it
could handle any number of bytes with the same bit layout within each byte.
Of course I wouldn't seriously recommend this approach for dealing with one
byte, but it does show how powerful TROT in particular can be. I've been
using it to produce printable hex fields for a few years, and it sure beats
an UNPK loop. I'm sure there are other innovative uses for it.
Tony H.
