I was thinking something more generic. The table description and layout is outside the code. The code would be a generic branch and return routine.
How the table is loaded is also not part of the code. It could be done at assemble time or at run time by reading a file. Correctness of data is the responsibility of caller, not the routine. The caller would be responsible to pad both the table and the search argument in the same way. Basically, a caller loads the 4 registers, branches to the binary search, and upon return R15 has the address of the entry or 0 if not found. Subroutine can modify R0, R1 and R15. If we need to, we can make R4-R7 'modifiable'. All entries will be fixed length. Can't really have variable length and use a binary search. :-) Tony Thigpen -----Original Message ----- From: John Gilmore Sent: 10/24/2013 12:26 PM
Tony, The code you want must address a number of additional issues. Are the elements to be assembled into the table all of the same length? If not, they must be padded with nuls, x'00', and not blanks, x'40'|x'20', at table-assembly time to make them so. Is the search argument shorter than the [padded out] table elements? If so, it must be padded out with nuls at execution/search time to make its length equal to that of the [padded out] table elements. Would it perhaps be better---I think it would---to make the table a self-defining one that contains the information required to search it? A routine that can search any such table given invariant DSECTs for it is a good notion. Should the table have an eyecatcher? (I think it should.) How should the middling subscript/element address be calculated? (Hint. There are two different, correct ways to do this, which yield slightly different decision trees. Moreover, both are notoriously FIXEDOVERFLOW prone.) Etc., etc. It will be interesting to see what if anything people post for our delectation. John Gilmore, Ashland, MA 01721 - USA
