On 10/4/18 3:14 PM, Max Filippov wrote: > I thought about it some more and it looks like this is not going to work > in general case in the presence of TB linking: a block with a big (and thus > not precise) LEND distance may be linked to a block with a small (and > thus precise) LEND distance. Then LEND may change so that next time > it still goes to the first TB. In that case it shouldn't go from the first TB > to the second, but with this scheme it will.
Indeed. Perhaps think of ways in which LBEG and LEND can be represented relative to each other and PC and store than in the 32-bits you have available in the CS_BASE field. Think first about how, if PC >= LEND or LEND - PC > PAGE_SIZE, that all of the loop stuff is irrelevant because we won't hit LEND within this TB. Think second about how to represent the common case -- how LOOP sets LBEG and LEND together. That is, LEND - LBEG <= 256. So, usually, we can also have an exact representation of LBEG and have a direct link rather than an indirect link. But I presume that one can play games with special registers to create ranges that LOOP won't. So we need some setting that will indicate that. Consider CS_BASE fields: [12: 0] EDIF = LEND - PC, if PC < LEND && LEND - PC < 2*PAGE_SIZE, or 0. [20:13] BDIF = LEND - LBEG, if LEND - LBEG < 256, or 0. So you can tell if advancing PC within a TB will exactly match LEND. You can tell what LBEG should be, except if BDIF == 0. In that, presumably rare case, you load LBEG at runtime as you did in this patch. Note that if CS_BASE == 0, and thus EDIF == 0, looping is disabled for the TB. I'll note that this also makes XTENSA_TBFLAG_EXCM redundant. Simply skip setting CS_BASE to a non-zero value instead. r~
