Is your feature request related to a problem? Please describe.
Developers of sophisticated programs that use MAP to access code in various 32-bit locations have difficulty using 16-bit debugger breakpoints, for two reasons: 1) it is an extra step to calculate the 16-bit PC address for a line of code based on the output of MAP-naive assembler/compiler tooling, and 2) the 16-bit PC address could be aliased to a different location per runtime MAP setting. This is difficult both for figuring the breakpoint address manually, and for hypothetical debugging IDEs.
Describe the solution you'd like
A new debugger instruction for setting a PC breakpoint takes a 32-bit instruction address, and trips it whenever MAP + 16-bit PC evaluates to the 32-bit address. This is probably a new breakpoint type, to preserve the current behavior that breaks on any given 16-bit PC regardless of MAP.
Describe alternatives you've considered
Alternatively, an alternate breakpoint type can remember a MAP + 16-bit PC, and trigger on that configuration specifically. This might make FPGA implementation easier, at the expense of user/tool complexity. It also takes away the ability to trip on a 32-bit address regardless of how it is MAP'd, though this might not be a big loss in practice. I'm mostly concerned about developer ergonomics.
Alternatively, do nothing. Collisions are unlikely, and unnecessary breaks aren't particularly hazardous. Live with the difficulty of figuring 16-bit PCs in programs that use MAP.
Additional context
Holistic thinking about assemblers, compilers, and debugger IDEs is warranted, so we build the right feature. The ideal design probably involves tools that haven't been built yet, e.g. a MAP-aware compiler, or a meta tool suite on top of existing tools for tracking memory runtime configurations through sources.
Is your feature request related to a problem? Please describe.
Developers of sophisticated programs that use MAP to access code in various 32-bit locations have difficulty using 16-bit debugger breakpoints, for two reasons: 1) it is an extra step to calculate the 16-bit PC address for a line of code based on the output of MAP-naive assembler/compiler tooling, and 2) the 16-bit PC address could be aliased to a different location per runtime MAP setting. This is difficult both for figuring the breakpoint address manually, and for hypothetical debugging IDEs.
Describe the solution you'd like
A new debugger instruction for setting a PC breakpoint takes a 32-bit instruction address, and trips it whenever MAP + 16-bit PC evaluates to the 32-bit address. This is probably a new breakpoint type, to preserve the current behavior that breaks on any given 16-bit PC regardless of MAP.
Describe alternatives you've considered
Alternatively, an alternate breakpoint type can remember a MAP + 16-bit PC, and trigger on that configuration specifically. This might make FPGA implementation easier, at the expense of user/tool complexity. It also takes away the ability to trip on a 32-bit address regardless of how it is MAP'd, though this might not be a big loss in practice. I'm mostly concerned about developer ergonomics.
Alternatively, do nothing. Collisions are unlikely, and unnecessary breaks aren't particularly hazardous. Live with the difficulty of figuring 16-bit PCs in programs that use MAP.
Additional context
Holistic thinking about assemblers, compilers, and debugger IDEs is warranted, so we build the right feature. The ideal design probably involves tools that haven't been built yet, e.g. a MAP-aware compiler, or a meta tool suite on top of existing tools for tracking memory runtime configurations through sources.