Author Topic: 64-bit register values and SIMD  (Read 11377 times)

Offline bootstrap

  • Multiple posting newcomer
  • *
  • Posts: 64
Re: 64-bit register values and SIMD
« Reply #15 on: February 27, 2012, 01:05:58 pm »
One more question.  Any way to view [and change] the xmm or ymm registers?
« Last Edit: March 03, 2012, 11:17:45 am by bootstrap »

Offline bootstrap

  • Multiple posting newcomer
  • *
  • Posts: 64
Re: 64-bit register values and SIMD
« Reply #16 on: March 03, 2012, 11:28:26 am »
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?

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9496
Re: 64-bit register values and SIMD
« Reply #17 on: March 03, 2012, 12:44:30 pm »
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?
http://developer.berlios.de/project/memberlist.php?group_id=5358
http://developer.berlios.de/patch/?group_id=5358

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".
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.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12001
    • Travis build status
Re: 64-bit register values and SIMD
« Reply #18 on: March 03, 2012, 01:29:59 pm »
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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline bootstrap

  • Multiple posting newcomer
  • *
  • Posts: 64
Re: 64-bit register values and SIMD
« Reply #19 on: March 04, 2012, 04:42:59 pm »
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.
« Last Edit: March 04, 2012, 04:55:34 pm by bootstrap »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12001
    • Travis build status
Re: 64-bit register values and SIMD
« Reply #20 on: March 04, 2012, 05:23:14 pm »
1. Please do not add another dialog, the cpu registers dialog is just fine. Also keep in mind that the idea of the new API is to provide an abstraction, so it is possible to write different debugger plugins wrapping different debuggers, platforms, landuages.
2. The easiest thing to do is:
 - treat the value column of the registers as string
 - provide context menu with the following options: Format, Set, Copy Value
 - all this options will call into the debugger, so it can do its specific processing
3. The complexity depends on the goals you specify for yourself. It can take from 2-3 hours to months :)

p.s. please don't write such long posts
p.p.s. I don't know where do you work or live, but reading and understanding code written by others is more important than being the fastest developer on earth. So you have a chance to improve your skills in this area :)
p.p.p.s. I guess, I can spend some time to implement this simple scheme
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline bootstrap

  • Multiple posting newcomer
  • *
  • Posts: 64
Re: 64-bit register values and SIMD
« Reply #21 on: June 02, 2012, 06:55:51 am »
p.p.p.s. I guess, I can spend some time to implement this simple scheme.

Did anything ever come of this?  If so, I'll install the latest nightly build.

Also, are you planning a 12.05 or 12.06 release?  I was guessing the 10.05 release was timed to follow the ubuntu 10.04 LTS release, which makes now a good time for a new general/binary release since ubuntu 12.04 LTS was released 1 month ago.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12001
    • Travis build status
Re: 64-bit register values and SIMD
« Reply #22 on: June 02, 2012, 11:55:46 am »
Did anything ever come of this?  If so, I'll install the latest nightly build.
No, unfortunately

Also, are you planning a 12.05 or 12.06 release?  I was guessing the 10.05 release was timed to follow the ubuntu 10.04 LTS release, which makes now a good time for a new general/binary release since ubuntu 12.04 LTS was released 1 month ago.
No, 12.05 went away. 12.06 is too close it time. Also there is no point in timing a release after a major distro release, if there was a timing it would have been 10.03 or 10.2.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]