Closed zocker-160 closed 5 months ago
I wonder how much overlap there is between this and #155.
I could solve this (and some of #155's cases) by adding types for <8 bit values, but to cover all cases really we need to either be able to define types on a bit boundary, or make it possible for each instance of a data type to have associated data - for example defining the data type of a particular byte to be split up as 1:3:2:2 bit words. This probably ties into if/how to do bitfields in the templates too.
Just thinking out loud.
EDIT: Also values that span byte boundaries too of course, because the world is crazy.
I think this is similar to #155, because displaying like I tried to show in the image above could also add the ability to edit it.
Being able to split it up into smaller bit words would be nice as well I think.
This has been waiting a while, but finally underway on the branch where I'm refactoring everything to support bit-aligned sizes/offsets!
I'm debating how this should look - do you think it should retain the hex/text columns on either side like the disassembly (pictured), or utilise the entire row for binary?
If you ask me, I think it should behave the same as any other data type. For example when I select an s8 it looks like this currently:
So when selecting type "bitarray" instead, I would expect [11111111]
on the left (instead of [-1]
and e.g. <bitarray8>
on the right (instead of <s8>
)
Merged to master along with a boatload of refactoring to support bit-precision offsets for the cursor position, selections, comments, data type definitions, etc.
It would be really useful to have bitarray as a data type available so that for example
0x8030
would show as[1000000000110000]