Thanks for both replies.
I have a couple suggestions and more questions.
suggestion
Probably a significant percentage of programmers don't [purposely] program with xmm or ymm registers. I assume most 32-bit mode programs don't pass arguments back and forth in xmm or ymm registers, so debugging most programs rarely involves the xmm or ymm registers. So I suggest there be two separate register dialogs, one like the current register dialog, and another for xmm and ymm registers.
To be maximally helpful, the xmm and ymm register dialog needs to be much more complex than the regular register dialog. Each ymm register can hold 32 s08/u08 variables, 16 s16/u16/f16 variables, 8 s32/u32/f32 variables, or 4 s64/u64/f64 variables. That's 11 possibilities for each freaking register!
While it would be quite helpful sometimes, I don't think it is especially practical to display every register in all 11 ways --- much less let any of the 11 forms be edited to a new value (what if they edit two or three of them - which do we accept?).
I also think it is overkill to put 11 radio-buttons next to each register so each register can be displayed in the appropriate format. That's just too complicated, especially since the appropriate display format changes from instruction to instruction during single-step.
So I guess a single set of 11 radio-buttons is best, that acts upon the format and display of every register. At least it isn't too difficult to toggle back and forth and watch the contents to understand what's happening. The biggest practical implementation problem here is that the number of active input fields needs to dynamically change between 32, 16, 8 and 4 per-register depending on the setting of those 11 radio buttons.
One simplification might be to only support 4 or 8 entries for each ymm register. If someone needs to display 32 s08/u08 values, let them distinguish [and edit] 2-character subsets of the 32-bit 8-hex-digit hexadecimal displays.
Actually, the more I discuss this, the more obvious it seems that this xmm/ymm register dialog will be just too huge to dock in the IDE. For practical purposes, it needs to be a separate floating dialog. As such, it might as well contain 32 input/display widgets for each ymm register, and simply shrink-to-hide display/input fields that are irrelevant for the current radio-button selected format (s08/u08/s16/u16/f16/s32/u32/f32/s64/u64/f64).
I don't have any experience with wx widgets, so I have no idea how difficult it might be to create and operate such a dialog, with an array of 16 lines of 32 display/input fields that needs to resize each field whenever a new radio-button is selected. But this seems the best approach off the top of my head.
One advantage of having only one set of radio buttons is... there is never any question how to interpret the input in any field. Without having the radio buttons set in a specific state, the input "123" could be interpreted as any of these types: s08, u08, s16, u16, f16, s32, u32, f32, s64, 64, f64... or even a series of 8/16/32-bit characters!!! Hopefully we can at least assume the input "123" is decimal and not hexadecimal for the lack of a leading "0x". But is that assumption even reasonable if the display fields are current set to display in hexadecimal?
Any comments about how big a hassle such a dialog would be with wx widgets? Off hand the wxGrid sounds more appropriate for this kind of situation (just based on the name, and nothing else).
And frankly, maybe even the regular register dialog should work in a similar manner. Not sure. At some point the complexity just becomes "too much" to support. So maybe we should assume the regular registers only contain one value each (s64, u64, f64). But the xmm/ymm registers have specific instructions to operate upon that whole range of types, so display and input in those many forms is appropriate in my opinion.
-----
As to the process, can someone list all the steps that I'd need to take to add a feature like this. That will help me decide whether I can afford to take the time to dive in and get started. Remember, I'm very fast and able at doing self-contained projects, even huge, complex, self-contained projects... BUT... I'm very slow to learn new tools. Which is why, when I created my IDE/debugger application, I wrote everything from scratch. No "dgb" to learn, no compiler to learn, no GUI-system to learn, nothing but my own compiler/editor/debugger/GUI-system to understand. Which means, never any confusion about "how such-and-such works, or is implemented". So please, give me a fully honest and realistic statement of steps and tools that I will face to start adding features to codeblocks. Then I'll decide.
And "yes", as far as I can tell, the debugger is the part that needs the most work.
