User forums > Using Code::Blocks
64-bit register values and SIMD
bootstrap:
One more question. Any way to view [and change] the xmm or ymm registers?
bootstrap:
Ehhhh, I hate to ask this, but perhaps I must.
What is the codeblock development process look like? I mean, how many people are involved, how huge or small is the project, and how practical is it for me to start fixing things I want fixed? I really, really, really don't want to do this, but at some point adding code to my programs to see 64-bit register contents, to change register contents at breakpoints, to view and change ymm registers when they exist... and other conveniences might become more cumulattive hassle and effort than fixing codeblocks.
On the plus side, I figure I have the required skill. I've written complete IDEs before (editor, compiler, debugger, interactive graphicial GuiDesigner, etc), so more or less I've "been there, done that".
On the negative side, while I'm quick to invent and design, I'm much slower to interpret and learn from the work of others. Which is probably why I tend to hate that kind of work. OTOH, the fixes I have in mind are rather tiny in scope, so unless I'm required to add the fixes for every possible supported debugger or something similar, the fixes should be extremely localized. Also on the negative side, I'm slow to learn new tools, so learning lots of new tools is necessary in practice, I should forget-about-it.
I guess there are other general practice issues that somebody should warn me about in advance. I am super busy with my own projects, and can't justify working on codeblocks if I can't dive in and get results pretty quick. And that depends to a great degree on what general practices the current developers may have.
Any advice along these lines?
MortenMacFly:
--- Quote from: bootstrap on March 03, 2012, 11:28:26 am ---I mean, how many people are involved, how huge or small is the project, and how practical is it for me to start fixing things I want fixed?
--- End quote ---
http://developer.berlios.de/project/memberlist.php?group_id=5358
http://developer.berlios.de/patch/?group_id=5358
--- Quote from: bootstrap on March 03, 2012, 11:28:26 am ---On the plus side, I figure I have the required skill. I've written complete IDEs before (editor, compiler, debugger, interactive graphicial GuiDesigner, etc), so more or less I've "been there, done that".
--- End quote ---
Good to know. But in fact it shouldn't be too hard. Just make sure hat if what you want t do is related to the debugger, use the debugger branch and sync' yourself with oBFusCATed - he is the maintainer of that branch.
oBFusCATed:
This should be relatively easy thing to change, but it requires the change in the API.
cbCPURegistersDlg::SetRegisterValue supports only long int values, but probably the parameter's type should be wxString.
Also for the GUI I was thinking of using the wxGrid class instead of wxListCtrl, so one can edit the values of the registers.
bootstrap:
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version