Jim Mulder wrote: <begin extract> AMODE does not affect performance. Can you explain which instructions you think are faster than some functional equivalent, and why you think they are faster? </end extract>
and it may be that what we have here is a misunderstanding of my language. Let me begin with a little history. On System/360 models above the model 30, L was faster than LH because they had [at least] four-byte fetch widths and had to 'throw away' half of what they fetched for LH. In my experience, and I have made many measurements, the same principle continues to apply mutatis mutandis today. I, for example, have a pair of assembly-language glb-seeking binary search routines that search the same table of quadword elements. One of these routines is AMODE(31) and one AMODE(64). The table---The same assembled table is always used---contains 63 elements. The usual 127 searches are performed, each 256 times. In the upshot the AMODE(64) routine is measurably, 2.1201%, faster. I have performed similar tests using searches of ordered lists of 10(10)200 elements. They are more addressing-intensive, and the superiority of the AMODE(64) routine increases almost linearly with table size, from 2.0897% for a list of 10 elements to 2.3311% for a list of 200 elements. Now it may be that what you mean by "AMODE does not affect performance" is different from what I mean. If so, I should be pleased to have you clarify the ways in which our uses of this word are different. John Gilmore, Ashland, MA 01721 - USA ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
